I've been passively writing this (to be clear, an x86 and DOS emulator, not this project) for a while so it's awesome to see someone already write it.
My goal was to have a mechanism for bootstrapping a compiler, similar to the Stage0 [0] project, but with a lot more software already written for it and less focus on having it be verifiable. This was to eliminate one more external dependency for building my Linux distribution, which is already cross-compiled and double-compiled to verify that builds are reproducible, in order to ensure that a version can be maintained for a long time.
I once extracted data out of an old dos-software by controlling it with a script and walking through all possible outputs (this was for train schedules). This was surprisingly difficult. The biggest hurdle is getting the screen contents out of the emulator. Dosbox only gives you screenshots that are pixels. In the end I managed to do it by using dosemu2 inside tmux controlled by python.
I wonder whether this could´ve made that problem easier.
I've debated for awhile trying to write a "UEFI DOS" for awhile. Thus far I've always shied away because of the sheer immensity of just getting a UEFI dev env set up much less one that would support emulation/virtualization of DOS applications so they could pretend they are on original hardware.
All of that is not even considering the whole bytecode vs. native issue...
Suppose you have an ancient program written in MASM (Microsoft Assembler) and you want your Linux Makefile to be able to compile it (I mean run MASM from within the Makefile just as you would run gcc). Which emulator will get you there with the least amount of work?
I have literally used this emulator to run MASM in this way. I was traveling with an ARM Chromebook and wanted to mess with a retrocomputing project.
dosemu was out because my host wasn't x86. dosbox was out because I wanted to run a process with filesystem access, not a whole system. qemu's system emulation has the same problem as dosbox, and qemu's user-mode emulation runs Linux programs, not MS-DOS programs.
In DOSBox you can mount host directories to MS-DOS drives with the "mount" command (and of course you can use Linux bind mounts and mount namespaces along with it).
Agreed. I wanted to script stuff like linking together 200 .OBJs, and running tests' stderr through sed to make it comparable with a known-good log. A DJGPP install + ancient Python inside DOSBox would've also done the job. Or even period-accurate DOS tools, but that'd cross my "is this retrocomputing or masochism?" threshold for this project.
I've been trying dosemu2, it's pretty good. Dosemu2 very badly needs better documentation, at least if the dosemu2 github is the starting point. Very basic things are not mentioned in the first documents you look at, like "exitemu" to exit the emulator and Ctrl-Alt-Home to grab/ungrab the mouse. The man page is incorrect for executing single commands, you need to type this to capture the output from a single command:
dosemu -dumb -exec dir >foo
Or this if you want to see the output on the screen:
Does it provide a true share.exe capability? I remember this is not the case with dosbox, but I would like this feature for some network file locking routines.
If you read the code [0], the author is using the phrase "Linux text console" to mean the Unix tty interface (/dev/tty, ANSI escape sequences, TIOCGWINSZ ioctl, etc). So it probably is portable to other Unix-like systems such as *BSD, macOS, Cygwin, etc, without much effort.
My goal was to have a mechanism for bootstrapping a compiler, similar to the Stage0 [0] project, but with a lot more software already written for it and less focus on having it be verifiable. This was to eliminate one more external dependency for building my Linux distribution, which is already cross-compiled and double-compiled to verify that builds are reproducible, in order to ensure that a version can be maintained for a long time.
[0] https://savannah.nongnu.org/projects/stage0/