I don't think you could get what you want--the ability to run arbitrary PEs on Windows 3.1--without, essentially, recreating Windows 95.

For one thing, Win16 and Win32s executables all share a single address space, so only PEs with a relocation table can execute under Win32s. Any PEs missing one and it's game over, not even considering whether it makes unsupported API calls or not.

Are some of your favorite Win32 programs open source such that it might be possible to backport them to either run under Win32s or to a Win16 app?

I don't know a lot about it, but extenders like DOS/4G are what came to my mind when reading your post. WINE also comes to mind, but I imagine porting it to Windows 3.1 would be difficult if not impossible. My imagination, however, is limited; I may be mistaken. What would be even more interesting, though, is whether successfully porting WINE to Windows 3.1 would also allow a Windows 3.1 installation on a modern PC to use 64-bit software. There are probably hurdles I am unaware of, but if a DOS extender can allow a 32 bit program to run in DOS, what would prevent the existence of 64 bit DOS extenders?

You are better off focusing on HX:
https://github.com/Baron-von-Riedesel/HX
https://www.japheth.de/HX.html

Win32s from what I've seen, is only capable of running a small subset of 32-bit programs (s = subset). These are mostly business-oriented apps of the time. You can run the 3D-Pinball (Space Cadet) that Microsoft supplied in the "Plus!" package - I've tried it and it works. The remaining list of compatible apps is useless to me so I haven't investigated further.

http://stephan.win31.de/w32slist.htm might be interesting.

there are probably some experiments you can do with trying to re-engineer or hack win 95 functionality into win3.11 and referencing the link Robbbert supplied but to be honest i'd find win 95 portable and simple too. In its basic undemanding form with nothing beyond basic drivers and no updates it's very light and undemanding - a 486 with 8mb ram is enough (actually it can work on 386-20 with 4mb ram!) and most early windows 32bit software would have that as that as fairly minimal requirement too

Part of the issue is that Win32s does not support threads. Threads are far more critical to Win32 GUI programming than you might experience doing only console mode or DOS or Unix programming, so applications would have adopted them quite early after Win95, long before SMP/multi-core became the norm which is their obvious utility. Consider an application that needs to do a long running operation such as decompressing a file or some mathematical calculation while updating a percentage progress indicator. With a main GUI thread and a processing thread, it's not much different from console mode programming: as you progress through the calculation, you calculate the percentage done and send a message to the GUI with a new percent done string to update the screen. As a bonus the user can continue to interact with menus, buttons, etc. in the GUI since it's a separate thread.

With Win16 it is much different. It is cooperatively multitasked and there are no threads. You have to intermix a long running operation with calls to PeekMessage() or the entire system will lock up until the operation finishes. Here is an old MS KB article talking about this, admonishing developers to break out of the PeekMessage loop once their operation is done so they don't hog the CPU: https://jeffpar.github.io/kbarchive/kb/074/Q74042/ GetMessage blocks until there is another message for your application (good for keeping the CPU free when the system is idle, but not allowing any time to do your background operation) while PeekMessage returns immediately; before variable-frequency CPUs, variable speed fans, and especially laptops, someone might program a constant busy-wait loop in their application and not realize it.

Hi. I think the others explained it very well.

From what I know, Win32s was an early testbed for Win32.
To developers it was accessible early on, before NT 3.x and Chicago were a thing or available.

Early Windows NT 3.1 applications run just fine on Win32s, thus.

Threading wasn't used so often in the early days, I think, it was more about porting Win16 code to Win32. Initially, I mean.

Over time, the focus for Win32s shifted more to Win95 compatibility.
That's why late Win32s 1.30c can run some applications which Windows NT 3.1 can't run.

If you want to learn a bit more about Win32s, you may want to have a look at my /our Windows emulator thread over here:

Emulation on MS Windows 3.1x ?

A lot those early Win95 era emulators can still run on Win31+Win32s.

If you like to develop for Win32s, Delphi 2.0 is a good start.
It creates Win32 applications with relocation tables. Just don't use the Win95 specific elements.

Good luck! 🙂👍

Edit: There's also a Japanese Win32s with special character support (double byte encoding AFAIK).
Re: Timeline of MS-DOS for NEC PC98 and more

I'm wondering about one thing...
- Windows 1.x/2.x/3.x all use cooperative multitasking, and so does Windows 9x for Win16 apps - Win16 apps are supposed to return control to the system pretty often, as already mentioned
- Windows NT uses preemptive multitasking, and so does Windows 9x for Win32 apps - it's not required for Win32 apps to interrupt long operations on their own, it's the system that's supposed to preempt the apps

But what about Win32s apps?
Are they required to behave like Win16 apps?
Or is there preemptive multitasking for them in WIndows 3.1x ?

Grzyb wrote on 2023-06-14, 20:59:

I'm wondering about one thing...
- Windows 1.x/2.x/3.x all use cooperative multitasking, and so does Windows 9x for Win16 apps - Win16 apps are supposed to return control to the system pretty often, as already mentioned
- Windows NT uses preemptive multitasking, and so does Windows 9x for Win32 apps - it's not required for Win32 apps to interrupt long operations on their own, it's the system that's supposed to preempt the apps

I think that's right. Cooperative Multitasking, -or non-Preemptive Multitasking as some folks call it-, uses a more democratic approach.
There's a message-based system and applications are given time in a time-slice scheme (time sharing).
Though the second perhaps affects DOS programs (non-Windows programs) on Windows mainly.

Windows 3.x applications, by design, are supposed to give back control to Windows/CPU once they're finished.
However, some badly written or misbehaving Windows applications don't do this. They "hog" the system.

That's why Windows 3.1x had merely limited multimedia capabilities, also.
It could happen that two different tasks were competing for CPU time or failed to share the System Timer.
Keeping video and audio in perfect sync, thus wasn't easy sometimes, for example.

However, if only a few applications were running, Cooperative Multitasking could be quite quick,
if not quicker than Preemptive Multitasking. It depended on the situation. 🤷

Grzyb wrote on 2023-06-14, 20:59:

But what about Win32s apps?
Are they required to behave like Win16 apps?
Or is there preemptive multitasking for them in WIndows 3.1x ?

Well, yes, most of the time. Win32s sits atop of Windows 3.1x and translates Win32 API calls to Win16. And vice versa.
To my knowledge, Win32s compatible applications run in Cooperative Multitasking and share one single address space.
This means that Win32s compatible applications can talk to each other and use same DLL in memory.

This causes the special scenario that Win32s compatible programs can do many forbidden things that Win16 programs can do.
To my understanding, they can intermix 16-/32-Bit DLLs and do other funny things, for example.
That's something that isn't possible on Windows NT or Win 9x, making Win32s an exception.

Win32s also has a set of dummy functions that do nothing, except keeping Win32 applications from crashing.
The console output can be considered to be one of them, maybe. Win32 console programs do run on Win32s, but there's no i/o window.
For command-line utilities, this is still good enough, maybe. The do their job, then quit. Switches like "/ or - or :" are supported.

Edit: I'm speaking under correction here, of course. I'm not without errors, either. 🤷

There was Watcom Win386, essentially a Win3x extender in a way DOS/4GW is a DOS extender.

You can read about it here:
https://www.os2museum.com/wp/watcom-win386/

This sentence sounds especially promising:

Win386 is still available as part of the latest Open Watcom release (version 1.9 as of this writing)

But it was first released before Win32s, and was essentially obsoleted by it (and soon by Windows 95). It's also not compatible with Win32s or Win9x (by that I mean Win386 cannot run applications written for those two).

If you want to run 32 bit apps (including "some win 9x software") but keep the Windows 3.x vibe I'd suggest NT 3.51 instead.

Azarien wrote on 2023-06-15, 21:35:

There was Watcom Win386, essentially a Win3x extender in a way DOS/4GW is a DOS extender. […]
Show full quote

There was Watcom Win386, essentially a Win3x extender in a way DOS/4GW is a DOS extender.

You can read about it here:
https://www.os2museum.com/wp/watcom-win386/

This sentence sounds especially promising:

Win386 is still available as part of the latest Open Watcom release (version 1.9 as of this writing)

But it was first released before Win32s, and was essentially obsoleted by it (and soon by Windows 95).
It's also not compatible with Win32s or Win9x (by that I mean Win386 cannot run applications written for those two).

If you want to run 32 bit apps (including "some win 9x software") but keep the Windows 3.x vibe I'd suggest NT 3.51 instead.

Thanks! I've found a short blog entry about it at:
https://virtuallyfun.com/2013/11/11/so-i-was- … 86-c-8-5-today/

Makes me wonder if these Windows programs can still be run on Windows x64.
I mean, at the core, they are 32-Bit. But the stub.. 🤷

It would be interesting to check this, since Microsoft itself used the WIN386 technology
in some its professional products (Fox Pro 2.5/2.6).

With a little bit of effort the extender part could be detected by the PE loader in Windows.
If Microsoft had made it aware for it, I mean. So despite an NE header, it could be launched, still.

Edit: Windows 3.1 had a WinMem32 API, which allowed (not so easy) flat-mode programming in 386 Enhanced Mode.
Not sure if it was already available in Windows 3.0 or if it was related to the WIN386 extender.

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

There were also some libraries for compiling 32bit linux/BSD apps to run on win 3.1 but I'm feeling you don't want that kind of Frankenstein.

delsydebothom wrote on 2023-06-18, 03:28:

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

I'd spent some time back in the 90s doing just that, basically stripping down Win95 to run more like Win3.x and the bare minimum to run some programs. It basically unzipped and you can immediately run it. So sticking a program that could run in a tiny environment can be done. Just replace the shell, or run a lightweight shell. The problem comes when you keep adding programs, you might as run a full Win95 anyway, because you'll need more features of Windows as your app basis grows. So I guess that would be my answer, is you might as well run Win95 if you have too many programs.

Well what if you wanted to package up a windows program, but not have to worry about Windows licensing? Well I guess you could loadlin linux from DOS, boot into Xwindows, and then call Wine... 😉 But I guess at that point you might as well build up a Linux program installer with Wine in mind and advertise your program runs on Linux, and just call it there.

Anyway doing this "AppImage"-like Windows environment using real Windows on top of DOS, well, it's just not gonna happen in practice.

delsydebothom wrote on 2023-06-18, 03:28:

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

Windows 95 needs MS-DOS 7.x.
Install Windows 95, set BootGUI=0, and you've got pure MS-DOS 7.x - from there you can run WIN.COM with some .EXE file as the parameter.
If you insist on having everything in a single .EXE, then make that .EXE a self-extracting archive, which extracts everything somewhere (preferably to RAM-disk), and then runs the extracted WIN.COM with the parameter.
Note that it's possible to strip Windows 95 down to just 5 MB - http://web.archive.org/web/20080804134312/htt … /~e8gus/nano98/

delsydebothom wrote on 2023-06-18, 03:28:

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

I achieved this a few years ago by trying to make the smallest win95 possible. I managed to reduce it to less than 2.88mb (but at this size the only function was to prove that it was possible to do it, as it is completely useless to try to use it) but I discovered that it is possible to load it "portable" as win 3.1, you only need to have ifshlp.sys loaded in config.sys to type win.com and load successfully.

I ended up creating a lean version, with drivers and direct x, just to run games. I set shell="a.exe" in win.ini, and created this a.exe that will just run the game, whatever the name of it is (I set it through a proper ini), so I could start playing any game windows from dos.

This was also thought of, because I was developing a fork of dosbox, capable of running windows games. My project is to be able to play dos and win9x games from modern windows explorer.

Rikintosh wrote on 2023-06-18, 04:57:

I achieved this a few years ago by trying to make the smallest win95 possible. I managed to reduce it to less than 2.88mb (but a […]
Show full quote

delsydebothom wrote on 2023-06-18, 03:28:

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

I achieved this a few years ago by trying to make the smallest win95 possible. I managed to reduce it to less than 2.88mb (but at this size the only function was to prove that it was possible to do it, as it is completely useless to try to use it) but I discovered that it is possible to load it "portable" as win 3.1, you only need to have ifshlp.sys loaded in config.sys to type win.com and load successfully.

I ended up creating a lean version, with drivers and direct x, just to run games. I set shell="a.exe" in win.ini, and created this a.exe that will just run the game, whatever the name of it is (I set it through a proper ini), so I could start playing any game windows from dos.

This was also thought of, because I was developing a fork of dosbox, capable of running windows games. My project is to be able to play dos and win9x games from modern windows explorer.

Will any Win32 stuff work under the minimal, Win3.1-looking Windows that is used during the first GUI phase of Windows 95 setup?
What about, after you use DriveSpace to compress a drive on Win95 and it reboots into that screen where it defrags your drive, it also looks like that Win3.1-like version? -- don't think I've seen that screen since the 90s though so that's from memory.

jakethompson1 wrote on 2023-06-13, 23:25:

I don't think you could get what you want--the ability to run arbitrary PEs on Windows 3.1--without, essentially, recreating Windows 95.

For one thing, Win16 and Win32s executables all share a single address space, so only PEs with a relocation table can execute under Win32s. Any PEs missing one and it's game over, not even considering whether it makes unsupported API calls or not.

Recreating Windows 95? OP said "9x", and of course there are applications written for 98 SE which won't run on 95 RTM, so really where would one draw the line? How many APIs do you need to support to get to a Windows 95 baseline, and then how many more do you need for 98 SE? These are just rhetorical questions not directed at anyone in particular, although if anyone feels like answering them I would be interested (but not because I want to do the work to implement them - I'm just curious)!

If one wants a lightweight operating system capable of running arbitrary Windows 95 or 98 or 98 SE applications, I think "what parts can I strip out of 95/98/98 SE to make it more lightweight" is a practical question you might ask - and that's a question which has already been answered quite a few times over the years, I think - whereas "how do I reimplement 95/98/98 SE on top of some other operating system" is a lot harder (unless you start with wine) and "how do I do that but on top of a closed source, 16-bit operating system" is probably approaching the most difficult way you could do it as far as I know. Of course that might be a fun project for someone who knows how to do it, like trying to run DOOM on some obscure hardware, but probably much bigger and less cool.

Grzyb wrote on 2023-06-14, 20:59:

But what about Win32s apps?
Are they required to behave like Win16 apps?
Or is there preemptive multitasking for them in WIndows 3.1x ?

Looks like Jo22 was right - from the Win32s Programmer's Reference:

Win32 applications operate under the same constraints as Win16 applications. To keep the user interface responsive, Win32 applications must check their message queue regularly. On Windows NT, a Win32 application that does not check its message queue and handle messages in a timely manner only affects its own user interface and the user may switch away and work on other applications. Windows 3.1, however, uses messages to schedule processes. Therefore, applications (16- or 32-bit) must handle messages in a timely manner in order to keep Windows 3.1 responsive.

Azarien wrote on 2023-06-15, 21:35:

This sentence sounds especially promising:

Win386 is still available as part of the latest Open Watcom release (version 1.9 as of this writing)

Yeah, it works in 1.9. I wonder if it works in 2.0; I've never tried using that version.

If you want to run 32 bit apps (including "some win 9x software") but keep the Windows 3.x vibe I'd suggest NT 3.51 instead.

I wonder if anyone has ever tried making a "lite" version of any Windows NT version?

Jo22 wrote on 2023-06-17, 16:03:

Makes me wonder if these Windows programs can still be run on Windows x64.
I mean, at the core, they are 32-Bit. But the stub.. 🤷

It seems unlikely to me that Microsoft would have done the work to keep such a small subset of Windows 3.x applications working on 64-bit Windows, particularly since I imagine it wouldn't have been that simple.

Win386 application code is itself is 32-bit as you say, and is linked against the Win386 API, which is a 32-bit API that - as Azarien (sort of) said - is not the Win32 API, but instead uses the Win16 API (so contains some 16-bit code too). Since Win386 was (according to the virtuallyfun link you posted) "bound to the executable", I guess it's separate enough from the application that perhaps one could make a loader that - instead of using the Win386 loader and API inside the executable - mapped the Win386 API calls to Win32 calls instead of Win16.

However, my understanding from reading the documentation is that the Win386 API is mostly meant to look just like the Win16 API, but is callable from 32-bit code. That is natural - it would be work for Watcom to design a whole new API, and then it would be a bigger barrier for their users to port their code from Win16 to Win386 - so some kind of Win386 loader for Win32 would be effectively doing the work of mapping from the Win16 API to the Win32 API but for 32-bit code instead of 16-bit code. Many of the Win16 API functions also exist in Win32 (but with different parameter sizes like in Win386), but there are quite a few significant differences too. Such a translation layer seems like the kind of thing which would work for some programs but not others, and of the few people who actually have a Win386 program they want to run, I can imagine that many would probably think it is much more reliable to just run a 32-bit version of Windows in a VM than use the buggy translation layer.

Edit: I just remembered that winevdm exists, so that must mean that the work of mapping Win16 to Win32 has already been done (but not by Microsoft!). It has a lot of issues raised in GitHub though.

the3dfxdude wrote on 2023-06-18, 03:47:

Well what if you wanted to package up a windows program, but not have to worry about Windows licensing? Well I guess you could loadlin linux from DOS, boot into Xwindows, and then call Wine... 😉 But I guess at that point you might as well build up a Linux program installer with Wine in mind and advertise your program runs on Linux, and just call it there.

If one was happy to run it on Linux (and modern Windows and Mac) perhaps one could use Boxedwine.

jakethompson1 wrote on 2023-06-18, 05:03:

Rikintosh wrote on 2023-06-18, 04:57:

I achieved this a few years ago by trying to make the smallest win95 possible. I managed to reduce it to less than 2.88mb (but a […]
Show full quote

delsydebothom wrote on 2023-06-18, 03:28:

Some very early Windows software came bundled with runtime versions of Windows; a minimal version of windows automatically loaded when the program was launched. I suspect designing something like that around Windows 95 would be rather inefficient and unwieldy. I don't even know that it is possible. I also suspect that even if it is, it would require dropping back into DOS, rather than being something that could be run from within Windows 3.x. Part of the purpose would be defeated in that case, probably. Still, imagine a script that could package all the necessary parts of Windows 95 into an executable file to run, say, Starcraft or Neverhood Chronicles from DOS. It would be nifty.

In fact, it would sufficiently nifty that if someone more knowledgeable than I am says that the idea is plausible, it would be all the kick in the pants I'd need to start learning what I need to to figure out how to do it.

I achieved this a few years ago by trying to make the smallest win95 possible. I managed to reduce it to less than 2.88mb (but at this size the only function was to prove that it was possible to do it, as it is completely useless to try to use it) but I discovered that it is possible to load it "portable" as win 3.1, you only need to have ifshlp.sys loaded in config.sys to type win.com and load successfully.

I ended up creating a lean version, with drivers and direct x, just to run games. I set shell="a.exe" in win.ini, and created this a.exe that will just run the game, whatever the name of it is (I set it through a proper ini), so I could start playing any game windows from dos.

This was also thought of, because I was developing a fork of dosbox, capable of running windows games. My project is to be able to play dos and win9x games from modern windows explorer.

Will any Win32 stuff work under the minimal, Win3.1-looking Windows that is used during the first GUI phase of Windows 95 setup?
What about, after you use DriveSpace to compress a drive on Win95 and it reboots into that screen where it defrags your drive, it also looks like that Win3.1-like version? -- don't think I've seen that screen since the 90s though so that's from memory.

no, that was a mini 3.1 similar to the mini 3.1 used during windows installation. It is not able to run 32-bit applications.