Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

16-bit assembly incompatibility with 64-bit windows 7

I recently discovered that 64-bit window won't run 16-bit applications (.com in this case), because 64-bit windows doesn't have a 16-bit subsystem (or so the internet says). I came across this when trying to execute an .bat file that called for EDIT.

I've got quite some experience with x86 assembly, but never wrote programmes to run under windows (or any other OS for that matter). Due to the backwards compatibility of the x86 family, I never really paid to much attention to how much bit my program was. As long as it didn't use instructions that weren't introduced tot the CPU the program had to run on, it was fine.

My question is: What exactly makes a code 16, 32 or 64 bit, what triggers the incompatibility problems 16-bit applications apparently have?

Is it possible to disassembly small 16-bit applications and change a bit to get it working, or is that really ill-advised?

Update: I am not looking for a way to run these kind of applications as it is, i.e. via emulators or other programmes, that I can work out for myself. I merely want to understand the underlying mechanics that make windows accept or refuse a program.

like image 620
Erik Avatar asked Feb 15 '23 03:02

Erik


1 Answers

To run a “16-bit Application”, which in this case means a DOS application, Windows® needs to set up a task in VM86 mode. The problem is that this works when the CPU is in 32-bit VPAM (Virtual Protected Address Mode), which is what an i386 OS uses, but not when the CPU is in the so-called “Long Mode” that AMD introduced. The amd64 CPU “Long Mode” only supports running 32-bit and 64-bit tasks.

So, a 64-bit OS kernel has no option to run 16-bit tasks directly on the CPU, you always must use some kind of emulation. If you find an OS that can do it, it either has that emulation built in, or is running in 32-bit mode instead of 64-bit mode, or is running in both 32-bit and 64-bit mode and switching happily between them in some kind of evil, twisted hack I've read about somewhere.

From experience, using DOSBOX is your best bet.

Edit: how does Windows® detect that it cannot run your code?

This largely depends on the program type detected. There are batch files (BAT, CMD) which it knows to handle, PIF files (I think they still didn't kill them off), and finally, COM and EXE executables. The COM case is easy: 65280-byte-max. 16-bit MS-DOS® program, out. EXE files, on the other hand, have certain file headers: one for the 16-bit DOS (or Win3.x) part (keyword: MZ), one for the 32-bit/64-bit part (LE, LX, PE (at the least), a.out and COFF are keywords here, some of which are used for OS/2 compatibility or by it only, some by various NT variants).

like image 116
mirabilos Avatar answered Feb 24 '23 11:02

mirabilos