Lightweight VM/emulator for DOS16 tools in Win64?
category: code [glöplog]
Simple problem: Your favorite command line tool is for DOS and you're now running Win64. What I would want is a lightweight DOS16 emulator that you can execute the tool with, hopefully by just placing the command before the tool command in the bat file or whatever.
Before: tool.exe sumethin.asm
After: dosemu tool.exe sumethin.asm
Is there such a thing?
DOSBOX is fat and optimized for games (graphics, sound, its own console etc.) I just want the thing to emulate basic file and console IO transparently and be fast.
Before: tool.exe sumethin.asm
After: dosemu tool.exe sumethin.asm
Is there such a thing?
DOSBOX is fat and optimized for games (graphics, sound, its own console etc.) I just want the thing to emulate basic file and console IO transparently and be fast.
why not use dosbox with command line options to run the tool?
something like..
dosbox "c:\oldtools\tool.exe sumethin.asm" -exit -noautoexec -noconsole
something like..
dosbox "c:\oldtools\tool.exe sumethin.asm" -exit -noautoexec -noconsole
-noconsole actually doesn't refer to the DOSBox main window, but to its status window. -noconsole means the status console window is hidden. So you still get the DOSBox screen window popping up, and no console output to your own console.
Also, the file IO isn't transparent. Maybe you can solve it with mount points and stuff, but...
And also, it seems impossible to actually pass parameters to the command from the command line.
In short, too many things are wrong with DOSBox for my use. Maybe a special build of it...
Also, the file IO isn't transparent. Maybe you can solve it with mount points and stuff, but...
And also, it seems impossible to actually pass parameters to the command from the command line.
In short, too many things are wrong with DOSBox for my use. Maybe a special build of it...
Out of curiosity, what do you need this for? There might be a more modern tool that would fill your needs.
This was for a 68k assembler, but might be of general interest. Crisis adverted in this case. What I really wanted to use was the new ASMotor but I couldn't get it to work. (The problem was simply that I had the command arguments in the wrong order. Classic.) Soon I'll need a Z80 assembler, though.
And before anyone suggests it, I do not like WLA DX (not at all) or gcc (for pure asm stuff). I simply don't.
And before anyone suggests it, I do not like WLA DX (not at all) or gcc (for pure asm stuff). I simply don't.
I once wrote a Z80 macro assembler and linker. I wouldn't recommend it, though, it specifically used a weird syntax that matched an old DOS Z80 assembler from the early 80s that the company I was working for still used for some projects (the old DOS assembler had some very weird quirks and problems under XP, hence the rewrite).
xeron: Out of curiosity, which syntax?
It was a really old DOS based assembler from IAR. Who appear to still be around. So good for them.
Yeah but I'm curious about the specifics of the syntax. Maybe I just shouldn't care. :p
Quote:
This was for a 68k assembler [...] Soon I'll need a Z80 assembler, though.
Except for x86 I tend to use gas if it supports my target CPU. Contrary to what some people believe it is not "hard to use" or "suitable as backend for gcc only".
I'm not a x86 guy, and I guess it's all about what you're used to, but I don't like the syntax for some thing in AT&T (gas) syntax. link me beautiful
Intel style: sub eax,[ebx+ecx*4h-20h]
AT&T: subl -0x20(%ebx,%ecx,0x4),%eax
The difference between the two is that the first syntax actually tells you exactly what the instruction does without special knowledge about this particular instruction. Although you could just as well blame Intel for their hellish addressing modes, the second syntax feels very shoehorned into a generic syntax.
Same with having to prefix literals and register names. These are things that are made so that a C programmer should be able read the assembly output regardless of platform. I'm sure it's good from that point of view, but if you're actually writing code in that syntax, those extra chars are just annoying.
Also, what does gas have in terms of macro capabilities? The C preprocessor?
I'm guessing it makes sense to use gas for programming in an OS environment, but for pure asm type platforms it violates some sort of feeling of cleanliness for me, even if this is purely mental.
Intel style: sub eax,[ebx+ecx*4h-20h]
AT&T: subl -0x20(%ebx,%ecx,0x4),%eax
The difference between the two is that the first syntax actually tells you exactly what the instruction does without special knowledge about this particular instruction. Although you could just as well blame Intel for their hellish addressing modes, the second syntax feels very shoehorned into a generic syntax.
Same with having to prefix literals and register names. These are things that are made so that a C programmer should be able read the assembly output regardless of platform. I'm sure it's good from that point of view, but if you're actually writing code in that syntax, those extra chars are just annoying.
Also, what does gas have in terms of macro capabilities? The C preprocessor?
I'm guessing it makes sense to use gas for programming in an OS environment, but for pure asm type platforms it violates some sort of feeling of cleanliness for me, even if this is purely mental.
More recent gas versions do support intel syntax. You can switch it with a directive, so you can probably even emit that directive from an inline assembly block in gcc, but you have to remember to switch back to AT&T at the end of the block since gcc will emit AT&T code. But I have no idea how much it is similar to or differs from masm/nasm (which are both different, anyway). Mostly out of habit I use nasm for x86.
gas has a macro mechanism which in terms of functionality looks about the same what other assemblers provide: http://sourceware.org/binutils/docs-2.22/as/Macro.html#Macro
Additionally you can preprocess gas source using cpp. This is very useful to create header files that can be used both by assembly and C/C++ sources (e.g. for defining constants for register addresses). Some gas backends have a directive for register aliases. For those that don't you could try using the C preprocessor.
I don't think this has anything to do with the target type. Either the target is properly supported, or it isn't. In the case of ARM I think gas is your best option.
Let me extend that a bit. The output format matters too. If I attempted to do some Amiga hacking I'd probably give vasm a try because I expect it's less painful to get Amiga hunk executables out of vasm than out of a patched gas.
gas has a macro mechanism which in terms of functionality looks about the same what other assemblers provide: http://sourceware.org/binutils/docs-2.22/as/Macro.html#Macro
Additionally you can preprocess gas source using cpp. This is very useful to create header files that can be used both by assembly and C/C++ sources (e.g. for defining constants for register addresses). Some gas backends have a directive for register aliases. For those that don't you could try using the C preprocessor.
Quote:
I'm guessing it makes sense to use gas for programming in an OS environment, but for pure asm type platforms it violates some sort of feeling of cleanliness for me, even if this is purely mental.
I don't think this has anything to do with the target type. Either the target is properly supported, or it isn't. In the case of ARM I think gas is your best option.
Quote:
Except for x86 I tend to use gas if it supports my target CPU.
Let me extend that a bit. The output format matters too. If I attempted to do some Amiga hacking I'd probably give vasm a try because I expect it's less painful to get Amiga hunk executables out of vasm than out of a patched gas.
Quote:
And before anyone suggests it, I do not like WLA DX (not at all) or gcc (for pure asm stuff). I simply don't.
Oh, sorry. I completely overread this sentence. Will shut up about gas now.