3 ms·
Pretty hard. It's not just a matter of executing 16bit assembly, you also need to handle mapping every single window message and callback between 16bit handles
by 0x0 10y ago
Pretty hard. It's not just a matter of executing 16bit assembly, you also need to handle mapping every single window message and callback between 16bit handles and the real native handles, of which there are thousands and the meaning/interpretation of parameters are unique for each one.
This guy is doing just that in .NET. While he uses a full blown CPU emulator for executing 16bit x86, the hard part is all the thunking and bidirectional mapping of handles and memory pointers and stuff: https://medium.com/@CantabileApp/implementing-window-messaging-in-win3mu-979a0ea31571 https://medium.com/@CantabileApp/implementing-window-messagi...
- derefr 10y agoThis seems like the harder strategy of the two. What about simply having a small Windows 3.1 or 95 VM that gets run in the background under HyperV, with fresh VXDs written for it to allow it to use paravirtualized resources, so as to allow it to do the same sort of "infinite framebuffer canvas used to back native windows for the compositor" tricks VMWare's Unity mode and the like do?
- 0x0 10y agoDoesn't MS already ship this as a "Virtual Windows XP Mode" based on VirtualPC? The huge downside is of course the lack of integration with your main OS - copy&paste and drag&drop of rich/dynamic content, OLE embedding, keyboard settings, shared file systems and drive letters, printer drivers, all sorts of windows preferences, applications installing random global windows hooks, etc etc.