DOS ain't dead

So I already "know" that the Win16 environment didn't allow you to write console mode apps like Win32 does.

And I already know that Watcom and others worked around that issue by opening a graphics window in their C library for writing to stdout.

PDPCLIB doesn't currently have Win16 as a target, and indeed, I never really programmed under Win16 because without a console I'm not very interested.

I now believe I have a simple workaround that I would have been happy to use if I had thought of it earlier and had started PDPCLIB earlier.

What I can do is treat Win16 as a batch system, and the C library can simply open a w16stdin.txt, w16stdout.txt and w16stderr.txt.

That would have given me a lot of memory for some tasks both then and now. ie I could make that executable work today with the x64 CM16 work. Even if I had lost the source. I assume they made most of the LDT available, giving me around 256 MiB. Possibly double that depending on what they (or I) did with the LDT. ie do they allow a huge malloc and create code aliases for all the entries? OS/2 1.0 doesn't allow that - I have to do individual 64k allocs if I want to create a cs alias.

Anyway, sniffing around, it looks like Windows 1.0 provided a KERNEL.DLL with functions OpenFile. I don't see a WriteFile. I think C library authors were maybe meant to use _lwrite, but in that case, why not use _lopen too? What is OpenFile for?

Anyway, with the batch system in place, would it have then been possible to optionally install a TSR to intercept DOS opening those particular filenames and redirecting them to some other place (like the original console window or a new black screen if the original is inaccessible?).

And then fast forward 40 years from 1985 to 2025, and instead of a TSR, I simply get my x64 CM16 pseudobios to recognize opens of those "standard names" and write them out normally, so it is no longer (if it ever was) "batch only".

If all this is technically possible, any suggestions on the "standard names" instead of w16stdin.txt etc?

Sorry for the confusion - just found out that Windows 1.0 was real mode only. Not sure why they introduced the NE format at that time (1985). Maybe future planning.

Anyway, so the question should be about a "PM16 version of Windows". And not necessarily virtual memory - just being able to malloc() 5 MB on a 16 MiB 80386 running in PM16 would be what I am after.

And with a bit of advanced planning when I was a toddler, I might have been able to compete with Gates for the 80286 market, as it doesn't sound like Windows ever took advantage of that capability - only OS/2 1.0 did that. Presumably Gates (allegedly) called the 80286 "brain-dead" because he wasn't selling a product for the 80286 at the time or whatever.

So my competing product would be mini-Windows clone that took advantage of the 80286 and was compatible with Windows/386. And since I'm rolling my own anyway, mine gives you a console, instead of batch-only on Gates's crappy competing version.