A VM?

Which VM emulators/simulators provide a debugger though?

You run a 32bit Windows in a VM and a debugger inside that?

Okay but which are the best debuggers that support Win16 (or NewExecutable) exes?

Are you trying to debug code you've compiled yourself or not? If so it depends on the compiler, if not your options are limited to really just one of the text mode debuggers (softice, codeview, tdw) but only with win3.1/95. If you are using ntvdm (which is recommended because if it crashes you can just kill ntvdm rather than having to restart the whole vm) there's windbg and the watcom debugger.

crazyc wrote:

If you are using ntvdm (which is recommended because if it crashes you can just kill ntvdm rather than having to restart the whole vm) there's windbg and the watcom debugger.

I wonder, why is OS/2's VDM never mentioned anywhere in this respect? Was there no debugger of this kind available at the time? 😕
Sorry if I ask. It's perhaps not the right spot. It's just.. When it was new, the OS/2 VDM used to be much more flexible than NT's VDM.
And according to the readme files of DOS/Win16 PD+Freeware programs that I came across in the past years, the authors often mentioned OS/2.

I'd expect NTVDM to be better for win16 programs but if you want to use OS/2 go ahead.

If you have access to SoftICE Win9x (from a now defunct company called Numega), it can debug Win16 program from Win9x OS. Last I checked, it even worked within recent version of QEMU running Win98SE as guest OS.

I had a long reply but I forgot that Firefox neglects to preserve un-submitted form contents if you have an extension which unloads idle tabs.

The gist of it was that you should check the options for NE-format executables that I dug up a few months ago.

I haven't tried debugging Win16 executables yet but, in theory, you can use any of these options:

• Run a Win32 debugger on NTVDM under 32-bit Windows inside a VM (eg. the "OllyDbg on NTVDM" option used in the blog post linked under "Reference Materials")
• Check if Boxedwine has Wine's built-in debugger backend enabled and, if so, use something like gdbgui to connect to it.
• Install a lightweight Linux distro like Lubuntu into a VM and run regular Wine on that, then connect to it using gdbgui.
• Run the Open Watcom C/C++ debugger in Windows 3.x inside DOSBox or in a 32-bit Windows in a VM. (I'm not sure how far back in time you'll have to go to find a Win16 build of the installer, but you can install the Win16 tools using the DOS installer and then manually set up the relevant bits of config.)

Interesting, thanks for mentioning it. Also saw your blog - Btw, there also was a WinMem32 API in Windows 3.1 which could be used for writing flat-memory apps (thus dropping 286 support).
I haven't found much information of it, but you can check its presence in Byte Magazine May/92, p.24, if you like. Anyway, just saying. Now have to stop going slightly off-topic..

Jo22 wrote:

Interesting, thanks for mentioning it. Also saw your blog - Btw, there also was a WinMem32 API in Windows 3.1 which could be used for writing flat-memory apps (thus dropping 286 support).
I haven't found much information of it, but you can check its presence in Byte Magazine May/92, p.24, if you like. Anyway, just saying. Now have to stop going slightly off-topic..

Sorry to keep things slightly off-topic, but I just have to respond to that.

According to this Wikipedia Talk page entry...

Unlike win23s which was installed separately, winmem32 was included with Window 3.11, and it also provided a 32 bit flat address space (for systems with 80386 or later processors). However, only Watcom C/C++ 10.0 fully supported winmem32 as one of it's standard memory models with a 32 bit flat address space, hiding all of the 16/32 bit interface stuff from the programmer. All Microsoft had at the time was an example assembly "thunk" program for using one function provided by winmem32. This resulted in the Watcom C/C++ 10.0 compiler being relatively popular until Windows 95 was released and became the mainstream Windows OS.

Also, given that none of my references for Windows 3.1 APIs mention it, I think it may be specific to Windows 3.11, which limits its utility.

That aside, Watcom's Win386 doesn't just allow protected mode applications (a la a DPMI host), it also provides a bunch of helper functionality (like a DPMI extender) to make writing 32-bit applications on a 16-bit platform more comfortable.

(Mainly customized Windows API headers and a bi-directional thunking layer that's as automatic as they could make it... so it's similar to Win32s, but built into your application. It also offers a redistributable FPU emulation driver for Windows in case you want to use the inlined floating point optimization that prevents your program from switching in emulated versions internally.)

Win386 is also fairly obscure on the web but Open Watcom's C/C++ Programmer's Guide (pguide.pdf) spends just over a quarter of its length on it, right after spending about the same number of pages on how to write DOS applications using DOS/4GW.