Community Forums - Unsupported Builds

There has been a Wine for Windows wiki article for a long time now. But it mostly has remained as a statement to how much work would still be needed to port Wine to Windows.

Now that 64-bit editions of Windows have killed running Win16 API directly on Windows, it seems like there might be people interested in paying $60 to recover their access to older applications. Not did dropping Win16 API impact applications written for Windows 3.x but also several Windows 95/98 applications as well. The reason why is because of the popular use of a Win16 installer stub to notify Windows 3.x users that the application can't be installed. So while the Windows 95/98 application itself was technically Win32, the installer still depends on a Win16 API being available.

From a user point of view this is certainly interesting, and it has crossed my mind as well 😊 .

But to reinforce the stereotype that engineers are hopelessly pessimistic: I don't think this is possible because it needs support for 16 bit protected mode segments by the Windows kernel. Support for this has been removed from 64 bit Windows kernels. Linux retains this feature, which is why Win16 apps work on 64 bit Linux. However, maintaining this has been difficult and it was even temporarily removed a while ago: https://lkml.org/lkml/2014/4/11/542 . After user protest the feature has been re-enabled after a potential security flaw has been fixed.

Note that 16 bit protected segments are a separate issue of vm86, which was needed for DOS apps in Wine and dosemu, and which has been killed by amd64 CPUs on the hardware side.

Stefan Dösinger wrote:

But to reinforce the stereotype that engineers are hopelessly
pessimistic: I don't think this is possible because it needs support
for 16 bit protected mode segments by the Windows kernel. Support
for this has been removed from 64 bit Windows kernels.

But DOSBOX still retains the ability to run 16 bit protected mode apps on a 64 bit Windows kernel. So maybe it is possible for there to be a CrossOver for a modified version of DOSBOX? If it is strictly a Win16 application, it would run completely inside DOSBOX on the CrossOver Win16 runtime. However, if the Win16 application attempts to execute something that the WinPE header indicates is a Win32 app, the modified version of DOSBOX could then be signalled to launch the Win32 application external to DOSBOX. This way either a pure Win16 app or a Win16 stub to Win32 app could both be run.

DOSBOX could be configured to supply up to 63MB of high memory and Crossover for DOSBOX compiled with DOS32a so it can access it. Hopefully this would reduce the amount of what would need to be stripped out to fit within the memory restriction. Maybe even permit enough of the Win32 API to be supported to allow win32s application to run?

Also, as an added benefit, since DOSBOX has been ported to Javascript, it might be possible to provide a demo of Crossover for DOSBOX directly in browser! :P

Imagine all the joy that Codeweavers will miss out on getting to use DJGPP if you don't make this product?!

How much more insane can it be than Wine for Android?

DOSBOX is an emulator. The Win64 kernel never sees anything related to 16 bit real or protected mode. It only sees a Win32 or Win64 black box that does some internal business it doesn't care about.

Wrt running Wine inside DOSBOX: The lower layers of Wine (ntdll, kernel32, ws2_32, ...) require a POSIX compatible operating system to work on, which unfortunately neither (Free-)DOS nor any DOS extenders are. The most realistic case of running Wine inside DOSBOX is installing Linux inside DOSBOX (or qemu, or any other PC emulator) and running Wine inside it. Other low level parts like user32, gdi32 and opengl32 etc are built on top of X11 or Quartz.

The higher layers of Wine like d3d, ole, mshtml, etc are built on top of the Win32 API that the lower layers provide. Those libraries generally work on a native Windows just like they do on Wine. That's why running (parts of) Wine on Windows is much less work than running Wine on a non-Windows, non-POSIX OS. E.g. some games on gog.com use Wine's d3d and ddraw implementations to work on modern Windows systems. (I saw the files shipped in Planescape Torment, but I haven't verified if they're actually used).

Ben Galliart wrote:

How much more insane can it be than Wine for Android?

Because it is a Linux system Android does support POSIX 😊 . It has its quirks, like a non-X11 windowing system, a different libc implementation with bugs, etc etc etc, but it's still a Unix system and not DOS.