Apparently WIne doesn't support 16bit DOS apps. Anyone know how to Get MASM intel-style assembly working in wine?
+1
A:
Have you tried using NASM? It's free, open source, supports Intel-like syntax similar to MASM [which I admit, I've never used], and works on pretty much every x86 platform, including Windows, Linux, BSD, etc.
On your typical Linux distribution or BSD ports tree, it's probably already packaged and ready to go. (Provided you apt-get, pkgadd, or whatever.)
asveikau
2010-10-13 05:26:40
My main concern is that whatever I write MUST work in windows. If i write some basic programs, will they work in both linux AND windows? Or will i need to create to different versions for each platform? In my class at school we use 'int' DOS interrupts, etc. I guess it'd be better in the future to use NASM of GAS, but the class at school is with MASM :(
trusktr
2010-10-13 07:22:10
16-bit code won't work in win64 so there goes your must. Just use a DOS emulator such as DosBox or Bochs which are available for most platforms.
Igor Skochinsky
2010-10-13 15:45:01
If you want it to run under Windows and Linux, you will have to write different code for things like syscalls and the part that gets run when your binary loads. But if you a targeting a DOS COM file for a class, NASM will do fine for the assembly step. Running it will be a different story. Perhaps you should use DosBox.
asveikau
2010-10-13 16:54:32
Thanks guys. I've got it working in DosBox already.
trusktr
2010-10-14 15:32:20
+1
A:
The solution of your problem is probably there:
http://www.japheth.de/JWasm.html
It's a MASM syntax compatible open source assembler (close to 100%, including the most bizarre MASM addressing syntax cases, the structured programming pseudo-ops, macros and the like).
It can generate Intel OMF, MS Coff (32- and 64-bit), Elf (32-and 64-bit), Bin and DOS MZ.
And it exists as DOS, Windows and Linux binaries.
And it can even be built to OS/2, FreeBSD.
So you then have the maximum number of combinations of assembler and target binary, including those were everything happens under native Linux.
If you compile to 16-bit code, you'll have to execute it in a 16-bit environment, meaning one of the suggestions you already got.
But you might also be able to compile 16-bit syntax to 32-bit mode code, depending on what you are trying to do. So you might be able to execute 16-bit algorithms in 32-bit modes, executing natively in 32-bit environments, like the x86 architecture allows. The generated code will be larger, though, since the assembler will generate 16-bit escape codes ahead each 16-bit instruction, but this is OK if it's just a matter of testing the logic of your 16-bit code.
I hope this makes sense to you. If it didn't, ask for more...
filofel
2010-10-16 16:50:02
That's interesting! How exactly would I go about compiling 16bit DOS apps to 32bit binary code? The aps are very small so the increase in size will be ahrdly noticeable.
trusktr
2010-10-16 18:03:08
If you use 16-bit instructions in 32-bit modes (such as ops referencing AX rather than EAX, WORD rather than DWORD, etc...), the assembler autoùatically generates an escape byte ahead of each instruction referencing a 16-bit quantity to indicate 16-bitness (rather than the default 32-bit. This doesn't work universally, but it can allow you to validate a number of simple algorithms. The very same mechanism works the other way, in fact, When referencing 32-bit regs in 16-bit modes. Try this with MASM and use the option to list all the generated byte codes...
filofel
2010-10-17 20:15:41