In regular mode it seems there's a problem with the system not setting the file pointer to the end when OpenOptions::append is used: https://i.imgur.com/vvbEnWh.png
AFAICT it is supported since NT 3.1, though, and it worked fine on all NT-based systems I've tested so far, so my guess would be a ReactOS API bug.
The commit adding the 9x/Me fallback implementation:
There is a WoW (windows on windows) subsystem which permitted you to either run 16-bit binaries on your 32-bit system, or 32-bit binaries on your 64-bit system; but there's no 16-on-64 or 16-on-32-on-64.
If you have a 64-bit version of Windows the compatibility layer lives at `%SYSTEMROOT%\SysWoW64`.
Turned out, it ran great on Wine. Actually, the performance even improved because the hardware was so much newer.
Oh my god, I always wondered why the WOW6432NODE registry key was named that but was never bothered enough to look it up. Thank you for triggering the random insight.
Still a very awesome project!
(I'm the original author)
It depends on two things:
- is the supported API surface big enough?
- is there an msvc runtime that can be linked with a somewhat modern linker (so that rust/llvm don't get angry) but that still works under Win32s. I'm not sure that exists, though :c
I hope you don't need to go all the way to /NODEFAULTLIB though, that kind of configuration is a big headache to build on.
Is there a .lib file for "msvcrt.dll" that will work with /NODEFAULTLIB? If so, I wonder if there is a Win32s compatible binary for that.
Not really, I've done just that (though in the end I didn't need full /NODEFAULTLIB):
With older msvcrt libraries you only need to link `libcmt.lib`/`msvcrt.lib`, that's it. Visual C++ 4.0 is apparently the last version to support Win32s, so if you can make it link to its libraries you might have a chance!
I wonder if it has been tested on Win32s or HXDOS. HXDOS is very friendly about that kinds of program it accepts, for example, the console version of 7-zip will run fine on HXDOS.