I've been thinking about a couple of different Win16 problems.
First, I've heard that Win16 app support is difficult due to debug limitations. Articles I've read say that cooperative multitasking is the primary complaint because a hung app can block everything but this doesn't seem to be a problem for Wine. There's probably other limitations of NE executables I'm not aware of.
Second, a few years ago there was a security fix that blocked running 16-bit apps on x86-64 kernels (bug #36664).
And finally, there is the general difficulty of executing 16-bit apps on 64-bit architectures via vm86, which affects 64-bit Wine.
While thinking about these problems it occurred to me that integrating an x86 emulator into Wine would be a practical solution. It only needs to support 16-bit apps, which are generally not constrained by CPU performance on modern systems, but 32-bit support could also be useful for 64-bit Wine. The emulator decouples the app from the hardware which avoids the security and support problems. It might also be useful as the start of non-x86 architecture support (ARM, RISC).
If the emulator had a least a JTAG interface then debugging tools could be used externally. A more complex debug API could support more advanced features, like gdb checkpoints, since full control of the emulated CPU and process environment is possible.
The only technical problem I foresee is supporting 16/32-bit thunking but it seems solvable.
Does this make sense?
Win16 app support idea
Re: Win16 app support idea
Win16 apps don't need vm86 mode, they run fine under x86-64. There's no reason to add a CPU emulator for them.
Re: Win16 app support idea
I guess I misunderstood the situation with them. I'll go hide back under my rock now.julliard wrote:Win16 apps don't need vm86 mode, they run fine under x86-64. There's no reason to add a CPU emulator for them.