Rather confusingly the death of the 32-bit version of Windows in practice just means they are dropping support for 16-bit DOS applications.
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[1] lives at `%SYSTEMROOT%\SysWoW64`.
People already do this. There is a very old strategy game (Stars!) that still (barely) has an active community. As it's a 16-bit windows app, the standard advice on how to run it on modern systems is to run it under wine in a VM.
I actually have already done this -- or, rather, helped someone else to do this. The individual in question was an academic with a license for a rather old version of a particular piece of domain-specific software, which would only run on Windows 95/98/ME. As he taught at a small school, his budget wasn't exactly infinite, so he kept an old Windows 98 machine around to run that software.
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.
Yeah they worded that confusingly. That said, I feel like the writing is probably on the wall for 32-bit. My guess is this might be the real reason why they pushed for making Visual Studio 64-bit.
This is a really interesting point. I can imagine that being able to use Rust for ReactOS (and wine!) would bring lots of interesting opportunities for developers and new contributors.
Hopefully we'll get support within Rust/Cargo for easily rebuilding the rust-std from source with custom features as part of compiling a project. Then this legacy system support could simply become part of the official Rust distribution.
This is already pretty easy with -Zbuild-std, but requires nightly unfortunately. You need to do this to get simd support in the standard lib in wasm for instance.
I think the rust-std code added for this project could already be pulled into rust, then. The target names should probably be something like i586-windows-msvc-old. (BTW, if LLVM supports building for plain i386 or i486, support for this should also be considered.)
- 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
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!
Win32s applications (like Win16 applications more generally) run in a shared address space with cooperative multitasking. They're basically async applications within an OS-provided runtime.
Vector graphics tool and manually changed the kerning on each letter to match the OG Visual Studio covers. The background effect is just the regular rust logo copied twice :)
Seeing that splash screen really tickled my brain. It’s likely rose tinted glasses, but I really miss the Visual C++ 6 on Win9x experience and all its associated aesthetic.
I wonder is there any option for async for NT-based legacy system like 2000 or XP? They have fibers and preliminary multicore support far as I remember. On other platforms slapping a simple single threaded runtime is probably fine.
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.
DOS with DPMI would be relatively easy. 16-bit support (real mode or protected mode on 80286) would require significant changes in LLVM, impacting frontend as well as backend code due to the requirement for separately defined _near, _far and _huge pointers and different "memory models".
