Hi, I decided to start learning assembly a while ago, and so I started with 16-bit assembly, using FASMW. HOwever, I recently got a really new computer running Windows 7 64-bit, and now none of the compiled .COM files that the program assembles work anymore. they give an error message saying that the .COM is not compatible with 64-bit windows. 32-bit assemblies still work, however i'd rather start with 16 and work my way up... Is it possible to run a 16-bit program on windows 7? or is there a specific way to compile them? or should i give up and skip to 32-bit instead?
+4
A:
The reason you can't use 16-bit assembly is because the 16-bit subsystem has been removed from all 64-bit versions of Windows.
The only way to remedy this is to install something like DOSBox, or a virtual machine package such as VirtualBox and then install FreeDOS into that. That way, you get true DOS anyway. (NTVDM is not true DOS)
Personally, would I encourage writing 16-bit assembly for DOS? No. I'd use 32- or even 64-bit assembly - the reason being there are a different set of function calls for different operating systems (called the ABI). So, the ABI for 64-bit linux apps is different to 32-bit ones. Not sure if that's the case with Windows. However, I guarantee that the meaning of interrupts is probably different.
Also, you've got all sorts of things to consider with 16-bit assembly, like the memory-model in use. I might be wrong, but I believe DOS gives you 64K memory to play with "and that's it". Everything, your entire heap and stack along with code must fit into this space, as I understand it, which makes you wonder how anything ever worked, really.
Ninefingers
2010-09-01 17:55:07
To your pondering about 64K memory being sufficient, you should check out the demoscene -> http://www.demoscene.info/
Esko
2010-09-01 18:03:10
Inaccurate (but not your fault). It has been removed since it won't work properly under Long Mode. http://en.wikipedia.org/wiki/Long_mode
Ignacio Vazquez-Abrams
2010-09-01 18:04:04
Interesting, I didn't realise that was the reason for its removal, I just knew it had been binned by Microsoft. Not a bad move as far as I'm concerned, we really shouldn't be using WOW64 any more either.
Ninefingers
2010-09-01 18:07:52
So will things like DOS-based cross-compilers no longer work? Sounds like a good reason not to go to 64-bit. I wonder why Microsoft didn't provide an emulation layer for DOS stuff? Even doing per-instruction emulation, it would still let DOS software run faster on a new machine than it would have run on the machines for which it was written.
supercat
2010-09-01 19:26:44
+3
A:
My advice would be to just write 32-bit code. While it might initially seem like it would make sense to learn how to write 16-bit code, then "graduate" to 32-bit code, I'd say in reality rather the opposite is true: writing 32-bit code is actually easier because quite a few arbitrary architectural constraints (e.g., on what you can use as a base register) are basically gone in 32-bit code.
For that matter, I'd consider it open to substantial question whether there's ever a real reason to write 16-bit x86 code at all. For most practical purposes, it's a dead platform -- for desktop machines it's seriously obsolete, and for embedded machines, you're more likely to see things like ARMs or Microchip PICs. Unless you have a specific target in mind and know for sure that it's going to be a 16-bit x86, I'd probably forget that it existed, just like most of the rest of the world has.
Jerry Coffin
2010-09-01 18:00:28
+1, I was going to mention embedded but I don't know enough about it from the assembly standpoint. Well said r.e. learning curve too.
Ninefingers
2010-09-01 18:06:05