All transitions from Windows to Unix code go through the NT syscall
interface. This is a major milestone that marks the completion of the
multi-year re-architecturing work to convert modules to PE format and
introduce a proper boundary between the Windows and Unix worlds.
All modules that call a Unix library contain WoW64 thunks to enable calling
the 64-bit Unix library from 32-bit PE code. This means that it is possible to
run 32-bit Windows applications on a purely 64-bit Unix installation. This is
called the new WoW64 mode, as opposed to the old WoW64 mode where 32-bit
applications run inside a 32-bit Unix process.
The new WoW64 mode is not yet enabled by default. It can be enabled by passing
the --enable-archs=i386,x86_64 option to configure. This is expected to work
for most applications, but there are still some limitations, in particular:
Lack of support for 16-bit code.
Reduced OpenGL performance and lack of ARB_buffer_storage extension
support.
The new WoW64 mode finally allows 32-bit applications to run on recent macOS
versions that removed support for 32-bit Unix processes.
I’m curious why 16-bit support is being dropped. Too much additional codebase complexity for such a small use case, or are there technical reasons it’s difficult to support in a 64-bit environment that somehow don’t exist in a 32-bit one? Or is it simply not implemented yet due to a lack of dev time/interest in the feature?
I know 16-bit programs are incredibly niche these days, but I’d be way more comfortable with enterprises running their ancient software in a secure, up-to-date WINE environment as opposed to an actual Windows 3.x one with its nonexistent security. Even in an isolated VM, that kind of setup is one misconfiguration away from disaster.
I think Wine has had WOW support for some time and it seems it will be the default at some time (arch moving to wow64).
Edit: What is WOW64
WoW64
All transitions from Windows to Unix code go through the NT syscall interface. This is a major milestone that marks the completion of the multi-year re-architecturing work to convert modules to PE format and introduce a proper boundary between the Windows and Unix worlds.
All modules that call a Unix library contain WoW64 thunks to enable calling the 64-bit Unix library from 32-bit PE code. This means that it is possible to run 32-bit Windows applications on a purely 64-bit Unix installation. This is called the new WoW64 mode, as opposed to the old WoW64 mode where 32-bit applications run inside a 32-bit Unix process.
The new WoW64 mode is not yet enabled by default. It can be enabled by passing the --enable-archs=i386,x86_64 option to configure. This is expected to work for most applications, but there are still some limitations, in particular:
Lack of support for 16-bit code. Reduced OpenGL performance and lack of ARB_buffer_storage extension support.
The new WoW64 mode finally allows 32-bit applications to run on recent macOS versions that removed support for 32-bit Unix processes.
I’m curious why 16-bit support is being dropped. Too much additional codebase complexity for such a small use case, or are there technical reasons it’s difficult to support in a 64-bit environment that somehow don’t exist in a 32-bit one? Or is it simply not implemented yet due to a lack of dev time/interest in the feature?
I know 16-bit programs are incredibly niche these days, but I’d be way more comfortable with enterprises running their ancient software in a secure, up-to-date WINE environment as opposed to an actual Windows 3.x one with its nonexistent security. Even in an isolated VM, that kind of setup is one misconfiguration away from disaster.
Thanks, TIL.
Cool, sounds promising!