6 ms·

Win3mu Part 1 –Why I’m writing a 16-bit Windows Emulator

74 points by mpalme 10y ago

analognoise 10y ago
Would be cool but there's no code to see. Too bad, too!
Jaruzel 10y ago
I love this, and think it would be great thing to have if MS don't shut it down. However, for those people who only have an occasional use-case for keeping Win16 apps around, there's always the Win3.1x on DOSBox option. For Example: https://joshmccarty.com/2013/08/run-windows-3-1-in-dosbox/ https://joshmccarty.com/2013/08/run-windows-3-1-in-dosbox/
- w0utert 10y ago
  >> I love this, and think it would be great thing to have if MS don't shut it down. I would be highly surprised if MS would even try to shut it down. On what basis would it not be allowed to write an emulator that translates old Windows API calls to new Windows API calls? And even if they could shut it down, what does Microsoft stand to gain by doing so?
  - Jaruzel 10y ago
    MS have a vested interest in convincing people to migrate to newer Operating Systems and Applications. They could have supported the original WinSXS for 16/32bit thunking in Windows 8 -> 10, but chose not to.
- Narishma 10y ago
  Last time I tried it, Windows 3.1 in Dosbox had a very laggy mouse cursor.
ptman 10y ago
Would wine work?
aruggirello 10y ago
BTW you can run 16-bit Windows apps in Wine under 64-bit Linux, provided your kernel version is <= 3.13, or >= 3.15 and you disable a security enhancement preventing 16-bit code execution by issuing (from root, possibly in your start-up scripts): echo 1 > /proc/sys/abi/ldt16 Some 16-bit programs under Wine might also need: echo 0 > /proc/sys/vm/mmap_min_addr Edit: not sure about kernel version 3.14.
- muterad_murilax 10y ago
  Is it possible to run 16-bit Windows applications in Wine on the Windows Subsystem for Linux?
  - swiley 10y ago
    The "kernel" there is written by Microsoft and is kind of wonky. Stuff like FTDI cables don't even work the way you would expect.
viraptor 10y ago
Just curious, maybe someone has better idea if this is harder or easier than writing the whole CPU emulator. What about writing a compiler from 16b binary to 32b/64b binary? Specifically, translate the common calls to be as close to compiled native as possible. It seems to me that unless someone wrote some functions directly in asm, most code should be relatively easy to translate. Pros: better performance, better memory usage, most instructions map 1:1, there's lots of extra registers for storing extra state required by the translation, easier debugging (you can compile each function separately and verify without running). Cons: harder debugging (at runtime), harder to test, properly translating memory segmentation, need to find a way to adjust all the offsets automatically, need to convert all the API function call conventions (can be quite tricky with variadic arguments).
- pjc50 10y ago
  There's all sorts of weird stuff like 'thunks' that need to be taken into account. It would be faster but is considerably harder to write, and "faster" isn't much of a requirement for Win3 apps. Whereas a straightforward emulator of the 16-bit set with the standard computed jump table is fairly easy. Mostly requires a lot of typing. If your interpreter fits in the i-cache it can even be faster. Although apparently since WINE will run 16-bit code, it looks like preservation of the 16-bit world is a Solved Problem. (I've long wanted a human-assisted decompiler for 16-bit DOS/Windows code, as a means of salvaging old games. For a few games people have done this by hand and built modernised versions with the bugs fixed.)
  - viraptor 10y ago
    Ok, my (unmentioned) assumption was VC-created code with no added assembly. I realise that VB code for example would be stupid hard to convert this way. I'm curious what do you mean by thunks in this case - specifically why would they be different than other code. Is it that the common code in original program may not be valid common code after translation?
    - pjmlp 10y ago
      Thunks were used to execute 32 applications in 16 bit mode via Win32s, and were also the way you would prepare callbacks to be exposed to Windows APIs.
coroxout 10y ago
If this old favourite from my Win3.x days runs, I'll be delighted: http://telcontar.net/Misc/LavaLamp/ http://telcontar.net/Misc/LavaLamp/ (will try some of the suggestions in this comments thread too - thanks!)
UncleSlacky 10y ago
Why not ReactOS?
- chris_wot 10y ago
  ReactOS is an effort to rebuild NT from the ground up, definitely not Windows 3.x An entirely different beast.
  - nandhp 10y ago
    ReactOS has an NTVDM, however, which runs on 64-bit (it does processor emulation, like OP). However, it looks like it doesn't support Windows applications yet: http://community.reactos.org/index.php/news/years-progress-ntvdm-part-2 http://community.reactos.org/index.php/news/years-progress-n...
BitGlitch 10y ago
Would be cool to see some of your code, possibly making it open source could be pretty sweet.
cool-RR 10y ago
"A couple of weeks ago I upgraded my partner Jen’s PC to 64-bit Windows. It all was going well until she went to play some Windows 3 card games that she enjoys when we realized that 16-bit programs don’t work on Windows x64. [...] it got me thinking… What would it take to write an emulator with just enough support to run these old games?" I can hear Jen rolling her eyes from here.
Ir0nMan 10y ago
wonders if Jen is the writers business partner or his girlfriend who has asked that he refer to her as his "partner"
Zardoz84 10y ago
I need to see if DosEMU keeps working on an moderm Linux of 64 bit. It make circles around DosBox, because not emulates the CPU. Instead, it used the old good virtual x86 mode like the dos box of Windows 3.1/95/98 and XP

74 points by mpalme 10y ago

Would be cool but there's no code to see. Too bad, too!

I love this, and think it would be great thing to have if MS don't shut it down. However, for those people who only have an occasional use-case for keeping Win16 apps around, there's always the Win3.1x on DOSBox option. For Example: https://joshmccarty.com/2013/08/run-windows-3-1-in-dosbox/ https://joshmccarty.com/2013/08/run-windows-3-1-in-dosbox/

w0utert 10y ago
>> I love this, and think it would be great thing to have if MS don't shut it down. I would be highly surprised if MS would even try to shut it down. On what basis would it not be allowed to write an emulator that translates old Windows API calls to new Windows API calls? And even if they could shut it down, what does Microsoft stand to gain by doing so?
- Jaruzel 10y ago
  MS have a vested interest in convincing people to migrate to newer Operating Systems and Applications. They could have supported the original WinSXS for 16/32bit thunking in Windows 8 -> 10, but chose not to.
Narishma 10y ago
Last time I tried it, Windows 3.1 in Dosbox had a very laggy mouse cursor.

ptman 10y ago

Would wine work?

aruggirello 10y ago

BTW you can run 16-bit Windows apps in Wine under 64-bit Linux, provided your kernel version is <= 3.13, or >= 3.15 and you disable a security enhancement preventing 16-bit code execution by issuing (from root, possibly in your start-up scripts): echo 1 > /proc/sys/abi/ldt16 Some 16-bit programs under Wine might also need: echo 0 > /proc/sys/vm/mmap_min_addr Edit: not sure about kernel version 3.14.

muterad_murilax 10y ago
Is it possible to run 16-bit Windows applications in Wine on the Windows Subsystem for Linux?
- swiley 10y ago
  The "kernel" there is written by Microsoft and is kind of wonky. Stuff like FTDI cables don't even work the way you would expect.

viraptor 10y ago

Just curious, maybe someone has better idea if this is harder or easier than writing the whole CPU emulator. What about writing a compiler from 16b binary to 32b/64b binary? Specifically, translate the common calls to be as close to compiled native as possible. It seems to me that unless someone wrote some functions directly in asm, most code should be relatively easy to translate. Pros: better performance, better memory usage, most instructions map 1:1, there's lots of extra registers for storing extra state required by the translation, easier debugging (you can compile each function separately and verify without running). Cons: harder debugging (at runtime), harder to test, properly translating memory segmentation, need to find a way to adjust all the offsets automatically, need to convert all the API function call conventions (can be quite tricky with variadic arguments).

pjc50 10y ago
There's all sorts of weird stuff like 'thunks' that need to be taken into account. It would be faster but is considerably harder to write, and "faster" isn't much of a requirement for Win3 apps. Whereas a straightforward emulator of the 16-bit set with the standard computed jump table is fairly easy. Mostly requires a lot of typing. If your interpreter fits in the i-cache it can even be faster. Although apparently since WINE will run 16-bit code, it looks like preservation of the 16-bit world is a Solved Problem. (I've long wanted a human-assisted decompiler for 16-bit DOS/Windows code, as a means of salvaging old games. For a few games people have done this by hand and built modernised versions with the bugs fixed.)
- viraptor 10y ago
  Ok, my (unmentioned) assumption was VC-created code with no added assembly. I realise that VB code for example would be stupid hard to convert this way. I'm curious what do you mean by thunks in this case - specifically why would they be different than other code. Is it that the common code in original program may not be valid common code after translation?
  - pjmlp 10y ago
    Thunks were used to execute 32 applications in 16 bit mode via Win32s, and were also the way you would prepare callbacks to be exposed to Windows APIs.

coroxout 10y ago

If this old favourite from my Win3.x days runs, I'll be delighted: http://telcontar.net/Misc/LavaLamp/ http://telcontar.net/Misc/LavaLamp/ (will try some of the suggestions in this comments thread too - thanks!)

UncleSlacky 10y ago

Why not ReactOS?

chris_wot 10y ago
ReactOS is an effort to rebuild NT from the ground up, definitely not Windows 3.x An entirely different beast.
- nandhp 10y ago
  ReactOS has an NTVDM, however, which runs on 64-bit (it does processor emulation, like OP). However, it looks like it doesn't support Windows applications yet: http://community.reactos.org/index.php/news/years-progress-ntvdm-part-2 http://community.reactos.org/index.php/news/years-progress-n...

BitGlitch 10y ago

Would be cool to see some of your code, possibly making it open source could be pretty sweet.

cool-RR 10y ago

"A couple of weeks ago I upgraded my partner Jen’s PC to 64-bit Windows. It all was going well until she went to play some Windows 3 card games that she enjoys when we realized that 16-bit programs don’t work on Windows x64. [...] it got me thinking… What would it take to write an emulator with just enough support to run these old games?" I can hear Jen rolling her eyes from here.

Ir0nMan 10y ago

wonders if Jen is the writers business partner or his girlfriend who has asked that he refer to her as his "partner"

Zardoz84 10y ago

I need to see if DosEMU keeps working on an moderm Linux of 64 bit. It make circles around DosBox, because not emulates the CPU. Instead, it used the old good virtual x86 mode like the dos box of Windows 3.1/95/98 and XP