[pjc50]

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]

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?

[pjc50]

There was some use of self-modifying code, although I can't find exact references. It'll be on Raymond Chen's blog somewhere.

I don't think it should matter whether the original source was VC or not, and if you write a solution that does make it matter you'll find yourself tripped up a lot. (Your favourite game turns out to have been compiled with Watcom or Borland rather than VC, etc). Presumably if you could find the 16-bit VB interpreter bits and pieces you could run those too and run your VB app.

I did run across this blog post http://discuss.joelonsoftware.com/default.asp?joel.3.607174...., which could be turned into a Win10 complaint with a simple search-and-replace.

Some compatibility craziness, that isn't quite relevant to our win16 emulation case: https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=...

[pjmlp]

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.

[solarengineer]

I was about to add a reference to the win32s thunking, and then chanced upon this [0] MSDN article that talks about supporting 32 bit I/O in 64 bit drivers. [0] https://msdn.microsoft.com/en-us/library/windows/hardware/ff...

[mschuster91]

> I've long wanted a human-assisted decompiler for 16-bit DOS/Windows code, as a means of salvaging old games.

If you're lucky (like me with EarthSiege 2), your game might also have a 32bit version, which you can run through IDA/Hexrays just fine.