Oh, one other thing…going back to true 16-bit means writing a toolbar from scratch. Win32s 1.30 provides the Win95 one (which the code currently uses), and NT 3.x has a different/older one that the code could use, but I don’t see anything in the MSVC 1.5 headers for this.

(In all seriousness, it’s amazing how much Win 3.x was a smoke and mirror show where applications coded sophisticated functionality outside of the platform. Although it gave the appearance of being capable, it was the apps themselves doing all the work. Win95 cleaned a lot of this up – the custom 2-D icon canvas in Program Manager became ListView, the tree in File Manager became TreeView, the various toolbars became a control, status bars became standardized, etc. Trying to write for Win 3.x involves reinventing a lot of wheels.)

I think this thread is seriously underestimating the work involved. It’s doable (it’s just work), but there’s quite a bit of it.

1. This source is from the NT version of Winfile. Getting it to run on Win9x involves removing security support and compiling it for ANSI (8 bit chars.) This build is currently broken.
2. Getting it to run on Windows 3.1 with Win32s requires removing all the CreateThread calls and replacing them with messages. I’m unclear on exactly why these were ever here; obviously the 16 bit version didn’t have them.
3. Getting it to run on Windows 3.0 means replacing all of the file management parts (which use a Win32 API) with their corresponding DOS APIs. It probably also means dealing with the bonkers 16:16 memory model. Things like ExtractIcon don’t exist there, so expect some manual parsing of executables to find their icons.
4. Getting it to run on Windows 2.0 would involve a lot of refactoring. I’ve seen MDI done on 2.0 (Word and Excel both did it) but it’s not a platform feature so there’d be a lot of reimplementing. Also, note the File Manager displays text with icons, but 2.0 doesn’t support owner draw controls (ever wonder why MS-DOS Executive didn’t do this?) Again, this can be reimplemented by owning the whole thing and using GDI, but that means reimplementing a list box from scratch. I suspect that a lot of control functionality that winfile has implicitly been using would be found to be missing in trying to do this; one way to think about WinFile is it was released with 3.0 as an app demonstrating all of the new capabilities and UI paradigms of 3.0.

Honestly I’m not expecting much of this to happen unless new people really step up for it. If I had to guess, (1) will happen but even (2) is currently looking unlikely. I know there are not well informed opinions on the internet (but Windows was ancient and didn’t have all the stuff you need!) but in this case there’s a lot of truth to it. The further back you go, random things just don’t exist and need to be redone. It’s not going to be a recompile.

I hope he do version for Windows 3.0 and Windows 2.0. I hope can email him.

At least one person is working on getting it going on older operating systems:
https://github.com/TransmissionZero/WinFile-Classic
So far still NT (3.51 and 4.0) though.

3.0 for sure, as it has MDI. I’m not sure about 2.0 though.