Is Win16 support doable?

[HBelusca]

I would like to know whether Win16 support is doable: whether SmallerC knows how to generate ASM code that can then be assembled (by NASM, etc) to Win16 NE executable, and be possibly linked to other Win16 dlls.

[alexfru]

Smaller C doesn't know that because nobody has taught it that.

Small memory model is probably doable, but in it you won't have far pointers, long or float. Which is kinda useless.

Frankly, the whole Win16 thing in 2017 makes infinitesimal sense.

The guts of the compiler know nothing about segmentation. The huge memory model is an inefficient hack (every pointer dereference hides a translation between physical and far addresses) and it may not work in protected mode (in general, segment selectors do not translate to virtual/physical addresses directly; you need to set up the LDT in a special way such that adding 8(?) to a segment selector (IOW, using the next LDT entry) corresponds to advancing the physical address by 64KB or something like that (I remember Borland Pascal supported that with DPMI, but I'm not sure if it's doable with Win16)).

See #13 for some details.

Also, I don't know whether the scheduler saves full 32-bit registers.

And I have no knowledge of the NE format or the old 16-bit Windows APIs.

And I don't know how to test it. Will NEs work on Win7 32-bit? Do I need to have some special DLLs?

But most importantly, why do you want this? Can't you use Open Watcom?

[Trinitek]

Personally, I have a passive interest in Win16 just for the sake of studying old architectures.

Enhanced-mode Windows 3.0 and 3.1 have a 32-bit protected mode kernel and do support 32-bit registers in applications. You can expect all of the extended general purpose registers, segment registers, and FPU stack to be preserved by the scheduler. And yes, the old subsystem is present in 32-bit Win7, so you can run NEs without any special dependencies.

[alexfru]

@Trinitek Thanks for the details! As for the learning, I don't think Win16 is worthy or special and you shouldn't be learning from my Win16 learnings, go to the source(s) yourself. :)

[HBelusca]

Thanks for the information! I was asking about the Win16 possibility, because here at ReactOS we want to add support for a Win16 layer through the usage of our version of NTVDM, and we were wondering which build toolchain would be best to use; we want something lightweight and preferably not something very stuffed like OpenWatcom. See https://jira.reactos.org/browse/CORE-9452 for the details.

[alexfru]

I've done a bit of research and here's my view of the problem.

In order to get Win16 more or less on par with Win32 here's what's needed:

• compiler adjustments for segmentation
• a whole new executable format in the linker with painful segmentation bits
• pretty much a whole new standard library with extras to create a window, process messages and simulate a console in said window

What this may give you:

• a somewhat incompatible type system (int will be 32-bit)
• a limited set of available Win16 APIs (only what's needed for C I/O including a very limited windows.h; hundreds of Win16 DLL imports/exports or redoing an existing windows.h are out of question)
• probably no easy way to just import something from a DLL (just as with Win32 today: you'll need to extend the library yourself, see e.g. the srclib/kernel32/*.c files)
• no DLL generation
• no resources in the executable
• console in the window or just the empty window, no buttons, no nothing GUIsh

With this you wouldn't be able to make programs to exercise all of the Win16 APIs that need to be implemented in ReactOS. It would be a small thing, but very limited and at times awkward to use. It would be quite a bit of work to do just the above but you'd not be very pleased with the result. And anything beyond that is simply too much work.

I think you should simply use Open Watcom.

[alexfru]

I've looked at it some more and played with things and I'm not promising Win16 support in Smaller C.

However, if you want something small in terms of dev tools, you can just as well use assembly. Here's a demo. All you need is NASM and a Win16 reference.