Home > Windows > Writing a Windows 3 emulator

Writing a Windows 3 emulator

Windows 40 Comments

We all know the feeling. You just want to use some of your favourite 16bit Windows applications, only to realise that since you moved to 64bit, Windows no longer runs them. This gets me every time, probably 4-5 times a day. Every time I’m like – there’s got to be a better way than firing up my old 386 laptop, or running an entire Windows 3.x VM just to get my daily fix of Skifree.

Right?

I jest, of course, but when Brad Robinson’s partner, Jen, wanted to play some old 16bit Windows games, he did actually want to create a less frustrating user experience. So, he decided to write a Windows 3 emulator.

The basic idea is to write a program that can read a 16-bit Windows executable file, run it on an emulated CPU and map any 16-bit API calls that it makes onto the x64 equivalents.

The emulator itself isn’t available just yet, but his series of articles on Medium detailing its development are fascinating reads.

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]

40 Comments

  1. 2016-11-14 12:48 am
    Wondercool

    … though it might be fun!

    I was in the same boat recently. I like to play a game called Stars! which is a Win95 game from about 1997.

    Couldn’t play it any more on my last 64-bit Windows machine reserved for Windows games.

    It plays on *every* Linux computer I have even if the CPU is 64-bit! Linux has better Win95 compatibility these days than Windows itself!

    Edit: OK I could be making a capital mistake: not sure how good Wine is for Win 3.x if at all possible!

    Edited 2016-11-14 00:53 UTC

    • 2016-11-14 1:17 am
      ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

      … though it might be fun!

      I was in the same boat recently. I like to play a game called Stars! which is a Win95 game from about 1997.

      Couldn’t play it any more on my last 64-bit Windows machine reserved for Windows games.

      It plays on *every* Linux computer I have even if the CPU is 64-bit! Linux has better Win95 compatibility these days than Windows itself!

      Edit: OK I could be making a capital mistake: not sure how good Wine is for Win 3.x if at all possible!

      It has had its regressions. For example, I’ve still got my PlayOnLinux set to Wine 1.2 for the copy of BrickLayer I like to play when most of my 32-bit games run on the system Wine.

      That aside, the big issue is that Wine doesn’t do the “emulated CPU” part… it relies on the Linux kernel’s support for running 16-bit code on 64-bit x86 with the help of the Wine loader, unlike 64-bit Windows kernels.

      If we’re ever going to see 16-bit classics show up on GOG.com, they’ll need a way to run them on their largest market by far (64-bit Windows).

      • 2016-11-14 8:24 am
        oiaohm

        Something that is here is not that wine 100 percent depends on the Linux kernel.

        https://wiki.winehq.org/ARM

        There is such thing as don’t reinvent the wheel. When on OS X and Linux for cpu emulation you can use qemu user-mode.

        Next wine does not run all 16 bit code by Linux kernel. 16 bit and 32 bit Dos application windows applications demand to run under wine on 64 bit Freebsd, OS X and Linux are run by dosbox emulator because 64 bit kernels does not have vm86 mode unless it custom patched. Please note if you do patch in vm86 mode switching to and from vm86 mode causes that much disruption on a 64 x86 system its not worth it.

        http://v86-64.sourceforge.net/

        If you want to see how bad get that patch and run it.

        There are a lot of early win 3.11 and 95 applications with installers written in dos. So dos MZ exe and com support will be just as important as NE exe support. Including incorrect dos MZ exe what are ones that start with ZM instead of MZ.

        Also a large number of wine libraries in fact build for windows. Biggest thing wine is lacking is a loader designed for Windows and a emulator for win16 mode because the dosbox emulator used for 16 bit and 32 bit dos applications could be used on Windows no problems.

        So wine is part emulated cpu and takes advantage of non emulated where possible. Also NE applications would have become emulated under wine if it had been impossible to fix the security fault in Linux kernel 16 bit protected mode. So someone making a emulator for 16 bit protect mode would be of interest to the wine project if it was cross platform.

        Just because wine uses dosbox for dos mode on 64 bit systems does not mean wine source code has removed the means to use native vm86 if the system offers it.

        So wine path seams to be use platform native where possible. Use emulation where that is not possible and if possible recycle a third party emulation.

        • 2016-11-14 2:34 pm
          chithanh

          Also NE applications would have become emulated under wine if it had been impossible to fix the security fault in Linux kernel 16 bit protected mode.

          I guess you mean the modify_ldt information leak.

          Actually the discussion on the kernel mailing list

          http://lkml.iu.edu/hypermail/linux/kernel/1404.1/02629.html

          didn’t go in that direction. Worst case it would have become disabled by default instead of enabled by default.

    • 2016-11-14 1:18 am
      dylansmrjones

      Could DOSbox be used? Later versions of Windows 3.x tried to prevent running on non-msdos/pcdos.

      • 2016-11-14 1:28 am
        ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

        Could DOSbox be used? Later versions of Windows 3.x tried to prevent running on non-msdos/pcdos. [/q]

        Windows 3.1 runs in DOSBox but it’s certainly not as seamless as a Wine analogue would be and, more importantly, good luck getting legit licenses for it if you want to re-release something you’ve lost the source code for.

        Also, as he says in part 5:

        [q]I’ve also noticed that running under Win3mu the programs feel a lot better compared to VirtualBox and/or DOSBox. It might be just that that response of the mouse is more natural.

        Edited 2016-11-14 01:34 UTC

  2. 2016-11-14 2:39 am
    Mark0

    And speaking of 16bit emulators, this could also be of interest to someone:

    http://takeda-toshiya.my.coocan.jp/msdos/index.html

    “This is MS-DOS emulator running on Win32-x64 command prompt.

    16bit MS-DOS compatible commands can be executed on Win32-x64 envrionment.”

    I used it with some mixed results, but worked great for some old compilers or other CLI tools like compressors/archivers.

    Edited 2016-11-14 02:40 UTC

    • 2016-11-14 2:12 pm
      ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)

      <span>And speaking of 16bit emulators, this could also be of interest to someone:

      http://takeda-toshiya.my.coocan.jp/msdos/index.html

      “This is MS-DOS emulator running on Win32-x64 command prompt.

      16bit MS-DOS compatible commands can be executed on Win32-x64 envrionment.”

      I used it with some mixed results, but worked great for some old compilers or other CLI tools like compressors/archivers.

      Huh. I don’t read Japanese but it looks like it’s probably a Windows analogue to dosemu, which I use for integrating things like Pacific C (from FreeDOS) into the build process for test files for an EXE parser I have planned.

      (Since the EXE files generated by Pacific C cause /usr/bin/file to produce output distinct from any of the native Linux-to-DOS cross-compilers I’ve tried so far.)

      Edited 2016-11-14 14:16 UTC

  3. 2016-11-14 3:16 am
    cybergorf

    reinventing the wheel?

    there is not only wine, bot there were also the Willow Twin Libraries in the 90s:

    http://www01.heise.de/ct/english/98/10/166/“ rel=”nofollow”>https://web.archive.org/web/19990913191434/

  • 2016-11-14 4:44 am
    ebasconp Silver Supporter

    What is wrong with reinventing the wheel?

    The guy is super-mega-geek, he is enjoying this journey and, who knows, the probability of having his product being better than the ones you mention is not zero.

  • 2016-11-14 3:21 am
    drcouzelis

    I miss Windows 3.1 for the user interface. For similar reasons that Thom loves CDE. It just did what I told it to do (as far as I can recall).

    http://www.osnews.com/story/18969/pt_VII_CDE

    …also, it’s been 21 years and I still can’t stand the concept of a taskbar, introduced in Windows in Windows 95. Grumble, grumble.

    • 2016-11-14 3:58 am
      phoenix

      I still think the TabWorks shell for Windows 3.x was the pinnacle of desktop UIs, with KDE 3.x a very close second.

      Nowadays, I just run a tabbed/windowed terminal and a couple different tabbed browsers so the desktop UIs is mostly irrelevant.

      Edited 2016-11-14 03:59 UTC

  • 2016-11-14 4:29 am
    Orisai

    While fun to develop, what’s the point of making a Windows 3.0 emulator, when you can create a VM using VMWare or VirtualBox, then install MS-DOS and Windows 3.x to run those games?

    • 2016-11-14 4:46 am
      ebasconp Silver Supporter

      While fun to develop, what’s the point of making a Windows 3.0 emulator, when you can create a VM using VMWare or VirtualBox, then install MS-DOS and Windows 3.x to run those games?

      “Fun to develop” should not be enough?

    • 2016-11-14 8:19 am
      jgfenix

      Easier to setup, seamless integration, smaller footprint.

      • 2016-11-14 9:03 am
        daedalus

        Yeah, being able to launch an application is far nicer than having to launch an emulator, boot the virtual machine, *then* launching the application.

  • 2016-11-14 10:38 am
    theuserbl

    As you can see in the video at

    http://www.win3mu.com/

    https://www.youtube.com/watch?v=yYsl5B_CefU

    its a converter, not an emulator.

    After installation of Win3mu, the programs still don’t run. But then the programs have to be selected, with right mouseclick in the popup menu “Convert with Win3mu” selected and the programs will be converted from 16bit to whatever, so that it runs on Windows 64bit.

    • 2016-11-14 11:41 am
      Mark0

      Nope. The converter just rename the 16bit .exe in .exe16, and create a new 32bit executable (with the original icon) that just launch Win3mu with the .exe16 file.

    • 2016-11-14 11:26 pm
      Drumhellar Silver Supporter

      It’s an emulator, but it wraps the 16-bit executable so users can just double click and launch it.

  • 2016-11-14 2:03 pm
    Z_God

    It’s interesting he decided to use a CPU emulator.

    The main reason why this is interesting is that it will allow 16-bit applications to run on for instance ARM as well. The NTVDM that someone ported to Windows 10 AMD64 reportedly also uses a CPU emulator. I wonder whether someone tried to run that on ARM.

    Most of the existing projects that enable Windows 3.1 support these days, such as DOSEMU and Wine require an x86.

    • 2016-11-14 3:04 pm
      Alfman verbose=1

      Z_God,

      It’s interesting he decided to use a CPU emulator.

      The main reason why this is interesting is that it will allow 16-bit applications to run on for instance ARM as well. The NTVDM that someone ported to Windows 10 AMD64 reportedly also uses a CPU emulator. I wonder whether someone tried to run that on ARM.

      Most of the existing projects that enable Windows 3.1 support these days, such as DOSEMU and Wine require an x86. [/q]

      AMD64 dropped support for virtualizing 16bit CPU modes from “long mode”, so having a CPU emulator is mandatory.

      https://en.wikipedia.org/wiki/DOSEMU

      [q]DOSEMU includes an 8086 processor emulator for use with real-mode applications in x86-64 long mode.

      As for DOSEMU not running on ARM, probably nobody’s done the work to port it. However other emulators should work.

      I’ve run windows 3.1 successfully from a sparc unix machine using the BOCHS emulator, which is portable. And I’d expect for it’s successor QEMU to run as well.

      • 2016-11-14 3:08 pm
        chithanh

        AMD64 dropped support for virtualizing 16bit CPU modes from “long mode”, so having a CPU emulator is mandatory.

        Well, mandatory only if you need vm86 mode.

        Wine shows that running 16-bit protected mode code works fine and mostly covers their use case of running win16 applications on amd64.

      • 2016-11-14 3:54 pm
        Z_God

        AMD64 dropped support for virtualizing 16bit CPU modes from “long mode”, so having a CPU emulator is mandatory.

        As was replied already, you shouldn’t confuse the different 16-bit modes here. Only real mode needs a CPU emulator and this is not required for win16 applications at all. Also DOS protected mode applications can run on the host CPU even on AMD64 systems. It’s just the DOS real mode applications that require CPU emulation. (And of course you need something to bootstrap DOS protected mode applications as they start out from real mode as well.)

        • 2016-11-14 8:18 pm
          Alfman verbose=1

          Z_God,

          Only real mode needs a CPU emulator and this is not required for win16 applications at all. Also DOS protected mode applications can run on the host CPU even on AMD64 systems. It’s just the DOS real mode applications that require CPU emulation. (And of course you need something to bootstrap DOS protected mode applications as they start out from real mode as well.)

          I agree, if you could skip the real mode code and go strait to protected mode, that code should be supported in AMD64 long mode. However it’s not merely the bootstrapping that’s missing, many protected mode programs were dependent on realmode DOS/BIOS calls (such as reading a file).

          I think we both understand this, it’s just that the original post gave the impression that DOSEMU did not use an emulator, however one is mandatory for DOSEMU because it needs to run realmode code.

          Edited 2016-11-14 20:33 UTC

          • 2016-11-14 10:50 pm
            Z_God

            I think we both understand this, it’s just that the original post gave the impression that DOSEMU did not use an emulator, however one is mandatory for DOSEMU because it needs to run realmode code.

            Yep! The replies you triggered were interesting though! Especially the one from oiaohm, I didn’t know about all this dark magic that would be needed regarding memory management ;)

            The dosemu version that’s in development can also use the new CPU feature that Rugxulo pointed out through KVM btw. Then no emulation is needed at all anymore.

          • 2016-11-15 12:59 am
            Alfman verbose=1

            Z_God,

            The dosemu version that’s in development can also use the new CPU feature that Rugxulo pointed out through KVM btw. Then no emulation is needed at all anymore. [/q]

            Cool, I didn’t know that, it’s on page 3751 of the combined software developer manual from intel:

            https://software.intel.com/en-us/articles/intel-sdm

            [q]The first processors to support VMX operation require CR0.PE and CR0.PG to be 1 in VMX operation (see Section 23.8). This restriction implies that guest software cannot be run in unpaged protected mode or in real-address mode. Later processors support a VM-execution control called “unrestricted guest”.1 If this control is 1, CR0.PE and CR0.PG may be 0 in VMX non-root operation. Such processors allow guest software to run in unpaged protected mode or in real-address mode. The following items describe the behavior of such software:

            • The MOV CR0 instructions does not cause a general-protection exception simply because it would set either CR0.PE and CR0.PG to 0. See Section 25.3 for details.

            • A logical processor treats the values of CR0.PE and CR0.PG in VMX non-root operation just as it does outside VMX operation. Thus, if CR0.PE = 0, the processor operates as it does normally in real-address mode (for example, it uses the 16-bit interrupt table to deliver interrupts and exceptions). If CR0.PG = 0, the processor operates as it does normally when paging is disabled.

            • Processor operation is modified by the fact that the processor is in VMX non-root operation and by the settings of the VM-execution controls just as it is in protected mode or when paging is enabled. Instructions, interrupts, and exceptions that cause VM exits in protected mode or when paging is enabled also do so in real-address mode or when paging is disabled.

            If intel had designed x86_64, it would have never been dropped.

            The feature matrix has never been more complicated, haha!

          • 2016-11-15 2:29 am
            oiaohm

            If intel had designed x86_64, it would have never been dropped.

            The feature matrix has never been more complicated, haha!

            Alfman that is wrong. You have forgotten Intel design IA-64 before AMD designed x86_64. Intel deleted everything that AMD included in legacy mode and the long mode protected 32 bit and 16 bit and said software emulation on IA-64 if you wanted to any of that that you had to use “IA-32 EL” the software emulator.

            Then with the VMX extensions intel did not want those modes either.

            Attempting to run win16 and win32 on intel idea of 64 bit x86(IA64) equals use emulator. AMD x86_64 equal emulator vm86 modes or trip through hell yet win16 and win32 applications should be usable if OS developers had put in the time.

            This is a case we have to be very thankful Intel was not left to design these things and mandate what feature limits we would be stuck with for ever more. Yes and if AMD fails for some reason we need to fear the future of the x86 platform as it been AMD different paths that have undo lot of Intel nasty moves and of course Intel moves have undone a lot of AMD nasty moves as well.

            Once dosemu is proven to be able to use KVM mode on Linux to run binaries that support will be able to be added to wine. This is where it gets interesting how little it really required to be emulated on modern day amd64 arch chips to run old applications if the OS allows you to use the cpu features.

            Emulation requirement of 16 protected mode on Windows is not hardware limitation but operating system software one from Microsoft.

          • 2016-11-15 3:14 am
            Alfman verbose=1

            oiaohm,

            Alfman that is wrong. You have forgotten Intel design IA-64 before AMD designed x86_64. Intel deleted everything that AMD included in legacy mode and the long mode protected 32 bit and 16 bit and said software emulation on IA-64 if you wanted to any of that that you had to use “IA-32 EL” the software emulator.

            AMD is the one who depreciated realmode under long mode. Intel is the one who added the capability back as described in the link. It was never “deleted” from IA64, that is a completely different architecture.

            Edited 2016-11-15 03:24 UTC

          • 2016-11-15 8:28 am
            oiaohm

            Alfman Amd64 long mode never includes realmode. But has had a switch to go from Long mode to legacy mode and back again that what the v86-vm86 patch for Linux uses.

            Amd64 original cpu boot up in legacy mode then OS had to switch to long mod

            http://v86-64.sourceforge.net/

            Basically the v86-64 patch for Linux follows AMD idea of how you are meant to access real-mode and vm86 modes.

            Amd64 was design because AMD did not like the fact IA64 stripped the modes completely and said emulate as this made old applications perform badly.

            https://en.wikipedia.org/wiki/X86-64#AMD64

            Basically IA64 is 1999 and Amd64 is 2000 when AMD says they are not following the IA64 path.

            To be truthful amd64 the switch from long mode to legacy mode and back is way better than 286 mode to switch from protected to real(what was reset the complete cpu).

            Alfman working with less than ideal instruction set has a long history with x86.

            AMD64 early documentation says you can only use vm86 and realmode from legacy mode and then goes to detail how to switch from long mode to legacy mode and back again.

            Please note using intel new VMX mode you are still technically switching out of long mode to legacy mode and back just now the CPU makes the process not require a few thousand lines of code and the overhead that causes.

            Intel has made the process easier not that the process was not already existing. Its like 286 vs 386 switching out of protected mode. 386 could do it without resetting the cpu and 286 had to reset the cpu both could achieve the same results but of course the 286 wasted the most cpu time doing it.

            Please do read the source of vm86-64 how they do it they don’t use any cpu emulation instructions like VMX does. Its just mode switching. You have to go from a long mode compatible 16bit or 32 bit protected to a legacy mode 16bt or 32bit protected then you jump from there to real or vm86. You have to be in the right segment type to swap modes.

            AMD did not remove vm86 and real-modes just made them pure pain to access with AMD64 from long mode.

            The path is

            long mode->compatibility mode(16/32)->legacy protected(16/32)->legacy vm86 or real mode

            The code complexity when you are dealing with 4 different cpu modes that have to get along give a lot of places to stuff up bady.

            VMX Unrestricted mode support replaces the above with this.

            long mode -> Legacy vm86 or real mode with the cpu doing the wrapper bits that compatibility and legacy protected modes had to do without you needing to know what they are or risking stuffing them up badly.

            So there is no difference in what can be done other than reduced code complexity and better performance on a cpu with VMX Unrestricted and a CPU without VMX Unrestricted. So vm86 was not removed just made hard and indirect to access. VMX Unrestricted does take quite a cpu wait as the cpu processes all the things to change from long mode to legacy and back.

            You have mixed up Intel adding a capability back with adding some instructions to perform an existing capability without major code complexity.

            So it one of those things where people are yelling new feature its not its old feature made easy to use. Anyone who has used the other 4 mode method and seen how it can go wrong is really thinks the new VMX way to do it is nice.

          • 2016-11-15 3:12 pm
            Alfman verbose=1

            oiaohm,

            Alfman Amd64 long mode never includes realmode. But has had a switch to go from Long mode to legacy mode and back again that what the v86-vm86 patch for Linux uses. [/q]

            As Rugxulo pointed out, Intel’s extension to AMD64 long mode supports real mode code, which requires segmented memory in particular. Intel added the ability to run realmode code without exiting 64bit long mode.

            This from Intel’s manual I already cited earlier:

            The first processors to support VMX operation require CR0.PE and CR0.PG to be 1 in VMX operation (see Section 23.8). This restriction implies that guest software cannot be run in unpaged protected mode or in real-address mode. Later processors support a VM-execution control called “unrestricted guest”.1 If this control is 1, CR0.PE and CR0.PG may be 0 in VMX non-root operation. Such processors allow guest software to run in unpaged protected mode or in real-address mode.

            Please note using intel new VMX mode you are still technically switching out of long mode to legacy mode and back just now the CPU makes the process not require a few thousand lines of code and the overhead that causes.

            That’s not accurate, I quoted this earlier from Intel’s manual pointing out a new VMX mode and not switching out of long mode:

            Processor operation is modified by the fact that the processor is in VMX non-root operation and by the settings of the VM-execution controls just as it is in protected mode or when paging is enabled. Instructions, interrupts, and exceptions that cause VM exits in protected mode or when paging is enabled also do so in real-address mode or when paging is disabled.

            [q]So there is no difference in what can be done other than reduced code complexity and better performance on a cpu with VMX Unrestricted and a CPU without VMX Unrestricted. So vm86 was not removed just made hard and indirect to access. VMX Unrestricted does take quite a cpu wait as the cpu processes all the things to change from long mode to legacy and back.

            You have mixed up Intel adding a capability back with adding some instructions to perform an existing capability without major code complexity.

            Who said anything about a mix up? I’m well aware that AMD64 could run real mode code under 32bit protected mode + VM86 by first exiting 64bit long mode, but it’s not the same thing as supporting VM86 directly from long mode where guests are mapped into 64bit address space, interrupts are 64bit, etc. It is indeed a new capability for 64bit operating systems.

            Edit: There’s no need to create a controversy over this, so if you want to say there’s no new capability, then whatever, it’s not that big a deal.

            Edited 2016-11-15 15:30 UTC

          • 2016-11-16 5:05 am
            oiaohm

            As Rugxulo pointed out, Intel’s extension to AMD64 long mode supports real mode code, which requires segmented memory in particular. Intel added the ability to run realmode code without exiting 64bit long mode.

            If you look at page tables when you are running realmode code with the you are in the legacy mode page tables not the long mode page tables. Check cpu state it will report legacy mode.

            Because what is going on is

            https://en.wikipedia.org/wiki/Second_Level_Address_Translation

            What intel calls EPT.

            So the real-mode stuff with VMX in fact switched to Legacy mode and uses a EPT recorded in Long mode.

            The 4 mode switch you can do the same thing EPT so keeping the vm86 stuff correctly recorded in long mode memory

            VMX in fact pulls a very rapid exist from long mode to legacy mode using the EPT setup for legacy mode. So it might not appear that you have existed long mode but when the vmx instruction complete you have in fact existed long mode completely and are back in pure legacy mode real mode with unrestricted guest.

            Most people miss that with VMX to use Unrestricted mode you must have EPT support. EPT support is to allow complete and total mode switch. Yes when you have switched into EPT mode you can only access the memory the EPT shows.

            VMX is just provides a different way to exist long mode and legacy mode by swapping cpu mode and page tables in a single command. There is a little bit of a myth that when you use VMX unrestricted you remain in long mode what is not the case cpu has completely changed mode for at least that core.

            VMX unrestricted just makes the process of going from Long mode to legacy mode and back less painful.

          • 2016-11-16 4:49 pm
            Alfman verbose=1

            oiaohm,

            So the real-mode stuff with VMX in fact switched to Legacy mode and uses a EPT recorded in Long mode.

            …

            VMX unrestricted just makes the process of going from Long mode to legacy mode and back less painful.

            Once again, that’s inaccurate. The new page tables are compatible with legacy mode, that’s the whole point, on that we agree. But this legacy mode emulation is quite distinct from switching the CPU back to an actual legacy mode. Intel’s document makes it perfectly clear that it enables legacy modes without switching to one, so if you have a problem with that, go take it up with intel.

            oiaohm, I know you are going to keep pretending that you disagree just to disagree, and for that reason, I’m getting off the discussion here.

          • 2016-11-15 10:16 am
            Z_God

            Once dosemu is proven to be able to use KVM mode on Linux to run binaries that support will be able to be added to wine. This is where it gets interesting how little it really required to be emulated on modern day amd64 arch chips to run old applications if the OS allows you to use the cpu features.

            This works already for a large part in the current development version. There’s a lack of testers though, maybe you’d like to join in:

            https://github.com/stsp/dosemu2/

            I’m not sure why you’d want to add this to Wine though. There is not really a strong interest in running DOS applications on Wine anymore. It would be neat if someone would pick that up again.

          • 2016-11-16 5:32 am
            oiaohm

            Z_God three words kinda should give a hint.

            “Digital Rights Management”

            There are some windows 3.11 and before historic games that the copy protect part is a dos program that either the windows 16 bit binary goes off hunting for or the dos binary goes hunting for the window 16 bit binary and alters each other. These horible things work when wine is using vm86 mode to run dos parts fail in dosbox. Yes this is for really old programs.

            Also more than you think want to be running dos games on wine.

            https://bugs.winehq.org/show_bug.cgi?id=18118 this bug is a collecting point for dosbox issues.

            https://bugs.winehq.org/show_bug.cgi?id=40944

            Notice the recent one merged to 18118. Yes person installed doom 2 classic by steam this year on wine and hello I need dos. So we now have the reverse of the window 3.11 age. Early 3.11 age installer dos; application windows with steam you have application dos; installer windows. Of course those not using steam on wine or 32 bit windows normally would not see these steam entries. So this could be a program a person has bought on steam today that happens to be dos.

            Z_God there is still interesting in running dos applications on wine. I will give you not as strong as it use to be. The reality is wine for max compatibility still needs to run dos one way or another. Wine currently support dosbox and vm86 modes to run dos binaries. Adding a third would not be forbidden.

            Z_God as long a steam has people downloading dos games every now and again it not going away wine feature list any time soon. I don’t run dos applications myself but there are people using wine dealing with them.

          • 2016-11-16 11:01 am
            Z_God

            In general DOS games in Steam ship with their own copy of DOSBox. They do not rely on any DOS support being present in Wine. There was also confusion about that in the second bug you pointed to.

            Likely there are win16 applications that depend on a DOS executable the way you mention. I don’t think that group is big enough however to motivate anybody to add KVM support to Wine to support such applications.

      • 2016-11-14 5:11 pm
        oiaohm

        AMD64 dropped support for virtualizing 16bit CPU modes from “long mode”, so having a CPU emulator is mandatory. [/q]
        Not true.

        https://en.wikipedia.org/wiki/X86-64#Operating_modes

        16 bit protect mode is part of long mode.

        Win16 only requires 16bit protected if it pure and does not use dos parts.

        win16 bit is missing from windows 64 bit for another reason.

        https://patchwork.kernel.org/patch/4089861/

        Turns out 16 bit segment mixed into things can cause some interesting bugs if you are not careful.

        Protected mode 16bit is in long mode but removed from windows and some other OS’s in 64 bit mode due to issues it can let lose from security side. Linux kernel and Freebsd still have 16bit mode usable in long mode.

        http://v86-64.sourceforge.net/

        As v86-64 patch shows swapping from long mode to Legacy mode to access vm86 mode is possible. So thunking on over drive. Just don’t mess up the double level of transitions.

        Its a horible set of jumps.

        64 bit bootloader is written in AMD64 documentation as being able to job to

        32 bit/16 bit protect mode legacy and from there you can jump to vm86 mode. The thing they fail to mention is that 32 bit/16 bit protect mode legacy can in fact return to bootloader still in long mode. Of course nothing in a AMD64 cpu design prevents a OS from using bootloader actions.

        Lets just say having to maintain tracking of memory in legacy and long mode at the same time is painful so its way simpler just to get rid of vm86 mode.

        AMD64 its not practical in most cases to use vm86 mode from long mode OS. Not that it cannot be done if you are super determined. Basically its one of those myths that running in long mode prevents vm86.

        Microsoft spread myth that vm86 mode was impossible for a OS in long mode mostly because implementing a OS maintaining memory mappings and other things for legacy and long mode at the same time is painful.

        To run most windows applications:

        Windows 64bit on x86 you require emulators 16 protected and vm86 mode.

        Linux, OS X, Freebsd x86 you only require emulators for vm86.

        Linux, OS X, Freebsd not x86 you need emulators for the lot why wine on those just goes qemu usermode with patch to correct threading.

        [q]And I’d expect for it’s successor QEMU to run as well.

        QEMU and BOCHS have not related.

        BOCHS is a full emulator and QEMU is dynamic translation. Both have different users. QEMU as it name suggests quicker but there are some issues in QEMU at this stage with threading. BOCHS being full emulator if you are needing to step though something instruction by cpu instruction then BOCHS is your beast but the price is the thing is slower but since it full emulation thread timings and other things to the applications appear to happen at the right times.

        So expecting BOCHS and QEMU to behave like each other is expecting a hell of a lot they are both very different methods.

      • 2016-11-14 10:22 pm
        Rugxulo

        AMD64 dropped support for virtualizing 16bit CPU modes from “long mode”, so having a CPU emulator is mandatory.

        https://en.wikipedia.org/wiki/Westmere_%28microarchitecture%…

        “New virtualization capability: ‘VMX Unrestricted mode support,’ which allows 16-bit guests to run (real mode and big real mode).”

        This is supported by VirtualBox.

    • 2016-11-14 3:04 pm
      chithanh

      Actually, Microsoft seems not interested in CPU emulation but rather go the path of binary translation to run x86 code on ARM.

      https://twitter.com/h0x0d/status/687618699474251777

      • 2016-11-14 5:23 pm
        Z_God

        It would be interesting if they will release that at some point. My point was more that this emulator should be able to work on the currently available win32 ARM platforms out of the box.

  • 2016-11-14 5:02 pm
    owczi

    Erm… Thom, you do know you can get 32-bit SkiFree from its author’s website, right? https://ski.ihoc.net/ – no need for an emulator ;)