Does this build on NT 3.51 and/or (DOS-based) 3.1?

[i336]

The primary way people are going to want to experience this is with period graphics/visual styling. That's primarily going to be DOS-based 3.1 and NT 3.51.

Mostly for the purposes of general documentation, I'm curious to find out how well this would cope with running on

• NT 3.51
• NT 3.1
• DOS-based 3.1
• DOS-based 3.11

and, if there are any issues, if anybody without much inside knowledge would be able to tackle them.

[craigwi]

Given the history of WinFile, it probably can be compiled to run on those systems. If the changes are small, I'd look at a pull request. Feel free to submit one.

[DrFrankenstein]

I doubt that it would have any trouble building/running on NT 3.51, though it would help to have the project file in older formats along with .sln/.vcxproj.

I could give it a shot this week if I find some time.

[yuhong]

Win9x would be most interesting though.

[craigwi]

As noted, feel free to propose a specific set of changes. Otherwise, I'll consider this 'won't fix.'

[NazmusLabs]

I recall that Win3.1x has the WinG components that can be added on that allows us to run some win32 (32-bit, as opposed to win16 that is native to 3.1) apps in Windows 3.1x. I am curious to see if it "just works" in Win3.1x.

[highvoltage]

Yeah would be curious to see how "moved the ini file location to %AppData%\Roaming\Microsoft\WinFile" affects windows 3.1.

[ZanderBrown]

@NazmusLabs win32s

Fresh Vanilla DOS 6.2 + Win 3.1 (from my own genuine floppies) & Win32s (achived here) fails like so:

Note: You can't launch [new] WinFile from [old] WinFile because it's already open so to speak, Instead put [new] WinFile in c:\winfile\ and add it to Program Manager (c:\winfile\winfile.exe). Make sure WinFile isn't running and launch WinFile

[ZanderBrown]

Looks like it was new in 95/NT4

[NazmusLabs]

@ZanderBrown thanks for the info! I'm hopeful we will eventually have a "retro" branch that would contain as many of the new changes made to v10.0 and beyond without breaking compat. Windows 3.1 probably the best way you can run 16-bit apps on Windows 10 x64 going forward (yes, way better than an XP VM), and having a good file manager becomes important!

P.S. looks like you are running Win3.1 on a very low 16 colors mode, as it's not rendering the default windows cyan theme correctly and, instead, showing a navy blue color. I highly recommend using Win3.1 on DOSBOX, as it can provide sound, true 32-bit color support, and high resolutions beyond the wildest dreams of 1992. It also offers Win3.1 to access NTFS drives and removes any size limits, and you can browse and modify files in your 3.1 environment from File explorer. So yes, you can literally download an image in MS Edge (or whatever), save it, alt+tab to your 3.1 desktop and open the file in a 16 bit app. Impossible to do in a VM.

The screenshot you see is my Windows 3.1 environment. Notice the dark theme. Thanks to Windows 3.1's highly customizable UI recolor options, I was able to use the Windows 3.1 control panel to create a modern looking and flat dark theme that mimics the look of Visual studio and the like. The selection highlight and text highlight colors are taken from VS's dark them itself. The wallpaper is there to show that Windows 3.1 is truly running in 32-bit color depth.

[ZanderBrown]

Yes the personalisation options of Win3.1 are insane, didn't spend time setting up the display drivers and personally I've always prefered the low colour ¯_(ツ)_/¯

[NazmusLabs]

@ZanderBrown It's not the low color that bothers me in 3.1 (they are ugly in Windows 9x but looks fine in 3.1), but it's the terrible mouse support, causing frustrating mouse lag and frame drops in any VM software. The reason I use DOSBOX is that the mouse moves almost as fluidly as it does on Win10. But, perhaps you are using Win3.1 on DOSBOX, but just in low color, which means you are already getting okay mouse support even without installing any drivers :)

[ZanderBrown]

@NazmusLabs For this I'm running Win3.1 in a kvm so it has a 'real' MSDOS base, for any 'serious' use it's DOSBox

However DOSBox doesn't support SHARE so win32s won't work under it

[NazmusLabs]

@ZanderBrown Ooooh, so THAT'S why I couldn't get Win32S installed correctly. I couldn't figure out the errors for the life of me. Thankfully, the errors were actually somewhat useful rather than Windows 10's frustrating "Something went wrong, here's an error code, which I didn't document in any MSDN sites and that googling won't bring up anything useful. Have fun!" :P.

[MartinPayne]

You can install MS-DOS in DOSBox and then install Windows 3.1 and Win32s on that. It will happily run early Win32 applications and I find it to be a lot better than under VirtualBox.

This won't compile for Win16 but I'm sure it could run on Win32s, perhaps with some small modifications. Visual C++ 2.0 can create Win32s applications and can be downloaded from Microsoft if you have a Visual Studio Subscription.

[NazmusLabs]

@MartinPayne that's an interesting thought. I didn't think I would be able to install dos on top of DOSBox, as, DOS was an actual operating system whereas Windows 3.1 is just an operating environment running on top of DOS.

Also, I had mentioned earlier that we would need to create a separate retro fork to make it work, as even version 10.0 makes some changes that Win3.1 can't use, such as placing preferences in the App Data folder. We'd need to build off of the original_plus version and then manually back port only the compatible changes from the master branch. That'd be the easiest approach than trying start from a fork of the master branch.

[ZanderBrown]

It's possible but as far as I'm aware you lose all the DOSBox commands giving you little to no benefit over a 'real' VM

[MartinPayne]

@NazmusLabs DOSBox is really just a CPU emulator with enough BIOS and DOS interrupts implemented to get DOS software working. It lets you boot your own code and replace interrupt vectors as you see fit. It's probably best not to start the debate of whether Windows 3.1 was really an operating system, and whether Windows ran on top of DOS or DOS ran on top of Windows. 😂

I'll have a look at the weekend to see whether it can be compiled with MSVC 2.0 and whether it runs on Win32s.

@ZanderBrown The DOSBox commands aren't really that powerful, and the MS-DOS commands significantly exceed their functionality. The main disadvantage is that it's not so easy to share files with the host, but that's equally true of something like VirtualBox. DOSBox also has the advantage that it more closely represents the hardware of the era, for example the OPL3.

[NazmusLabs]

@MartinPayne Ah, thanks for the explanations. When I personally say Windows 3.1 runs on top of DOS, I typically talk as an abstract, and not technically or how it's actually programmed. It's easier and more practical to think of it that way because we launch DOS and then run Windows. Sure, behind the scenes it may be more complex, but for normal day to day operations, and especially for normal users who might be trying to get a 16-bit retro Windows 3.1 game running, it's far more practical and efficient to explain to them in this simplified way.

However, what I find funny is that some people calls Windows 3.1 an "app" that runs on DOS, not much more different than, say DOOM. Ouch. And I guess that works to, as it gets the point across for new users interested in retro software or retro gaming.

As for Win32s, I'd love to know how it works out. I don't have an MSDN subscription so I don't have access to the compilers. And to be honest, the thought of even ever needing a 16 bit compiler for a modern application was beyond absurd...until...now. Wow...talk about expecting the unexpected when it comes to software development...

P.S. I've only ran Windows 3.1 on DOSBox version 0.74, which was released 8 YEARS AGO, in 2010. I'm wondering if we get any lucky installing Win32s in a 2018 build of DOSBox. I mean the point of even having WinFile in Windows 3.1 is so we can use it in a practical sense. And my old 16-bit apps and games are running without issues in DOSBox; so, if I can't get Win32s running in DOSBox, where I actually would find a good file manager useful, what's the point other than a fun programming challenge to take on...

[DrFrankenstein]

To answer the title question; no, it does not build on Win 3.x, NT or not; or Windows 95 for that matter. It was mostly broken by the port to 64-bit; notably, the use of INT_PTR, LONG_PTR et al, which don't exist in older SDKs.

I tried with Visual C++ 4.0 and confirmed it just spits out errors all over the place.

16-bit support is even further back, as the qualifiers for x86-16's fancy pointers (__far, __near, etc.) have long been removed.

As far as running the binaries from the Releases section goes... those were built with a recent toolkit, and support for Windows (NT) 3.x is long gone. Inspecting the image in Dependency Walker reveals some broken dependencies in kernel32.dll, and the VC Redistributables installer won't launch either.

Of course, if it won't run on WinNT 3.51, it certainly won't run in Win 3.11+Win32s either.

Conclusion, I can't make a special build for those unless I backport this source (good news, that's very much doable with a bit of patience!)

Another option: I hear there's a way to get recent versions of VS to still link against the classic msvcrt.dll, which might get it to work. If anyone is familiar with this, I'd be interested to hear about it.

[yuhong]

How about VC6 with a newer SDK?

[MartinPayne]

I've given it a go in MSVC 4.2 and found much the same. There are a few errors about functions which don't exist, but most of the errors are to do with data types.

Looking at the source, there is some threading code in there which would rule out being fully functional on Win32s without some additional work (not sure whether the application would crash or handle this gracefully). Probably best to aim for Windows NT 4 and 9x first!

@DrFrankenstein Yes, it is possible to link against MSVCRT.DLL using newer VS (unsupported of course), but you may find problems with the CRT startup code not being compatible with older versions of Windows. You may also have to be careful with the linker options and edit some values in the PE header to get it working. I'm going to stick with MSVC 4.2 for now.

[NazmusLabs]

@DrFrankenstein wow, very informative. Definitely looks like it's not going to be an easy port. But thankfully we have the source code; so, it's in the realm of possibility. The project looks to be better suited as a fork project dedicated to rewriting this application using the source code for 16-bit windows and, older 32 bit NT clients.

[DrFrankenstein]

If anyone backports this to old versions of Windows, part of the work has been done in #59 (backport to XP). Hat tip to @roytam1.

[leeter]

Please make sure this is done into a separate branch, this shouldn't hold back conformance and features in the main codebase because of legacy support.

[NazmusLabs]

Yeah, definitely. If we are going to create a branch for older versions, we might as well have the branch focus on XP, 2000, MT, 9x, and 3x, end let the master branch just be focused on Windows 7 (Vista should automatically be compatible, as it's very similar to 7) and up.

On the visual style issue thread, I wondered out loud the need to test the changes in 2000, as MSDN suggests. But this would solve that problem and not hold back the master branch.

I think we should just start with a fork of the Original_plus and start with the XP support and go from there.

[leeter]

@NazmusLabs ironically Vista is missing quite a bit. My suggestion overall would be to skip it in general or just support what the current (latest) CRT supports without using the XP compatibility pack (since that's on the to be retired list anyway).

[NazmusLabs]

@leeter yeah, I was kinda aware of some of Vista's limitation, but definitely not an expert on that area. However, the reason I noted Vista would automatically work is because WinFile is using the most basic of Win32 and COM technologies. It's not using anything near the level that would require the platform features of Windows 7. I may be wrong, though. Perhaps VS2015 and later just doesn't compile to Vista property, but I'd be surprised of that was the case. Vista was still supported when VS2015 and VS2017 was released.

[leeter]

@NazmusLabs IIRC the main holdback that complicates vista targeting is the threadpool support changed significantly between vista and 7. I'd have to see if there are places in the codebase where using threadpool would make sense (e.g. don't hammer screws). More than likely most of that is taken care of in the backend of COM anyway. Realistically I think that's jumping waaaay ahead of ourselves for right now as gradual evolution of the codebase is probably the right path.

[NazmusLabs]

@leeter thanks for the explanation on the differences between Vista and 7. But yeah, perhaps staring with xp, 2000, and NT compatibility would be the easiest. And once that's verified working, it would be 9x. Since it doesn't work on 9x either, getting 9x working would be a huge step in getting it working for 3.x.

[DrFrankenstein]

In this project's case, the main difference between 95 and NT 3 is going to be SHLWAPI (which is absent from the latter unless NewShell is installed, I think). I don't think it's going to be too much trouble to remove/block it if we configure it for NT 3.

Once we reach that point, Windows 3.11 (with Win32s) should be a breeze; it likely will be to just avoid threading if we backport anything past original_plus. I know this version uses the modern toolbar and statusbar controls from comctl32, but I'm pretty sure that Win32s provides all that (to an extent, anyway). 16-bit commctrl (caution: 3.11-only) might have them, but possibly with an incompatible interface.

Personally, I wouldn't even bother backporting to 16-bit. It looks like a rabbit hole of caveats. Anybody could prove me wrong, though. After all, the original code was 16-bit, albeit many years before this snapshot.

[leeter]

@DrFrankenstein actually I'm not sure it's an issue with the codebase as is given what I filed with #84, the app was written before SHLWAPI and has what are basically shims from back then.

[yuhong]

The original Win95 didn't have SHLWAPI.

[DrFrankenstein]

That's possible, @leeter. I was only basing that on the fact that this codebase does include <shlwapi.h> and link against the corresponding .lib, but if it's not really used, this is even better.

[leeter]

@DrFrankenstein it might be used in other spots, I was just noticing that it would be a good replacement for code within. My philosophy has always been to use OS APIs instead of writing my own unless the OS APIs are just absolute 💩 . Less code I have to maintain and ship patches for.

[NazmusLabs]

I agree, @DrFrankenstein, that it's best to use Win32s for Windows 3.x. I'm just hoping someone is able to figure out how to get Win32s running properly with DOSBOX. I'm going to need to try their latest DOSBOX build, as the latest stable is from 2010. Hopefully, 8 years worth of updates improves compatibility.

[ZanderBrown]

Without booting 'real' DOS the best I've ever found is fakeshar aka 'Fake Share' but its likely things will be subtly broken as it doesn't actually implement any of the SHARE functionality just pretends enough that the if has_share() { check will pass

Perhaps if @craigwi has some spare time they can fish out the SHARE sources so we could fork that to make it work in DOSBox?

[MartinPayne]

@NazmusLabs Is there a reason why you are trying to use Win32s with the DOS which is built into DOSBox? Win32s does work fine in DOSBox if you install a real MS-DOS on it. It runs Freecell, various Windows 95 applications, and my basic Win32s application.

[NazmusLabs]

@MartinPayne see my posts about why we need DOSBOX rather than real DOS. Using DOSBOX allows me to get 32-bit color depth, NTFS file system support, and the ability to store Windows 3.1 and its apps and data files in a folder in file explorer, allowing me to access 3.1 files from Windows 10 without worrying about mounting Virtual Hard disks. I also don't get the limitation of disk space. Real dos has limited max disk space. With DOSBOX, I can have Win3.1 store a terabyte of stuff, in theory.

P.S. After installing Win32s, I did get an error, but FreeCell does seem to launch, as well as a 32 bit game.

[MartinPayne]

I've had a look at this today with Visual C++ 4.2. I've got it to the point where it successfully builds with two warnings. There are some caveats:

• It crashes on startup (but not before seeing the application flash up very briefly on Windows NT 3.51 and NT 4!).
• I can only get the Unicode build to work at the moment. There are a lot of errors in the ANSI build, so no Windows 9x support without significant effort.
• It won't start on Windows NT 3.1 due to requiring a kernel32 function which doesn't exist in this version.

I suspect the crashing is because I deleted some code to get the build to work. The problematic functions are "IsLFNDrive" and "IsNetDrive". I'm not familiar with either of these, so I'll have a look into them and find a more appropriate solution than deleting the code.

[ZanderBrown]

Both of them are going to be an issue for Win3 but i would have thought NT3 would be fine

[MartinPayne]

You're right. They are in the "shell32.lib" import library but not in the headers. Prototyping them gets the build working, but it's still crashing on startup. I'll do some debugging.

[NazmusLabs]

There's got to be some sort of unicode support for the 9x line on the web, especially because these OSes lost support in mid 2000s and remained popular for almost another half a decade. It's possible someone made a third party tool for 9x that can be redistributed if that tool is free and open source.

I'm hoping to try and see what happens if I attempt to get it running as is in Windows 98 with the KernalEX patch.

[MartinPayne]

My fork now runs under Windows NT 4.0:

At the moment it starts up under Windows NT 3.51 but gives the error "Unable to initialize background update support.". I'll look at that next.

MSLU supports Unicode on Windows 9x, but I'm assuming this code did successfully compile as ANSI at one point, so it should be possible to add that support back.

[ZanderBrown]

@MartinPayne congrats!

How major are the modifications you made? (e.g. could they merge with master with reasonable preprocessor directives?)

[MartinPayne]

@ZanderBrown Thanks!

The changes are fairly significant. I doubt they could easily be merged back into master without making it more difficult for everyone to maintain, and my understanding is that the goal of the upstream project is to continue supporting modern Windows without making significant feature changes.

[ZanderBrown]

@MartinPayne ah okay

Yes it's probably not worth merging all of that into master as it's primarily looking forward not back

[MartinPayne]

I have it running on Windows NT 3.51 now as well:

[craigwi]

Nice work. Based on my initial review, it looks possible to integrate some/many of the changes back to master. Even the change GetWindowLongPtr -> GetWindowLong can be reimplemented with defines. Same for INT_PTR -> INT. Right?

[ZanderBrown]

Yeah I think the closer we can keep the two codebases the better

[NazmusLabs]

Yeah, if it can be easily added back, then why not. It'd make this easier for everybody.

Plus, if this gets far enough, a retro branch (version 9, as applied to v10) would be nice to have here. That way, people wouldn't have to hunt for forks. Or at the very least, an an officially sanctioned fork that is linked to from the Readme page so people who want to cab easily get to it.