Does this build on NT 3.51 and/or (DOS-based) 3.1? #9
Comments
|
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. |
|
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. |
|
Win9x would be most interesting though. |
|
As noted, feel free to propose a specific set of changes. Otherwise, I'll consider this 'won't fix.' |
|
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. |
|
Yeah would be curious to see how "moved the ini file location to %AppData%\Roaming\Microsoft\WinFile" affects windows 3.1. |
|
@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 |
|
@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. |
|
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 ¯_(ツ)_/¯ |
|
@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 :) |
|
@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 |
|
@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. |
|
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. |
|
@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. |
|
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 |
|
@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. |
|
@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... |
|
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 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 ( 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. |
|
How about VC6 with a newer SDK? |
|
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. |
|
@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. |
|
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. |
|
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. |
|
@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). |
|
@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. |
|
@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. |
|
@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. |
|
|
|
@ZanderBrown Looks mostly fine to me. I would have put all the XPs and Server 2003s on the retro side though because they are out of support. Unless there are plans to ensure that all future changes work in those older OSes, I would expect the red bar to move to the right over time. |
|
@MartinPayne yes we flip flopped over that a few times in #104 |
|
@MartinPayne the biggest reason for the line being where it is is because of x64 support. Having server 2003 and xp x64 would meaning needing to compile x64 builds. We thought that the retro branch should only be 32 bit focused. Secondly, xp is much older than Server 2003/xp x64, a couple of years in fact. However, my understanding is that in terms of platform level APIs, Server 2003 is closer to XP than it is to Vista. |
|
I don't think that would require a 64 bit build, because Windows XP 64 bit should support 32 bit applications, and the other 64 bit Windows certainly do. But anyway, the diagram looks like a sensible plan and it can always be changed later if supporting them in master proves too difficult. I see we now have a retro branch, so let's start getting some PRs ready! There are a few things we should decide on about the retro branch:
Let's discuss, then I can look at putting my commits into a PR and submit it. |
|
This is just my opinion but how much there really are users who would like to use this with the ancient systems? At least for me, it is fantastic that I can build this with NT 3.51 but I'm not really using it there for my daily work. Most of the people are likely using Win10 and such and therefore it would be quite OK that new features etc. exist only in the master branch? |
|
@ttsirkia the idea is that a different branch for older version means the master branch can continue to focus on the latest features. Versions of Windows from the 90s have become a timeless legacy, especially for retro PC enthusiasts and retro gamers. The 3.x and 9x lines of Windows are the almost universally agreed upon operating systems that almost anyone building or restoring a 90s era hardware will install. They, as an extension of DOS are the PC gaming platform from the 90s. Thus, these operating system continue to remain timeless even in virtual machines. DOS has full support for running 3.11, allowing you to seamlessly run any 16 bit app you might want. Having a good file manager is a great edition for these operating systems and enthusiasts. @MartinPayne yes, we do have a retro v9 branch now! And the decision was made to branch from the latest commit rather than original_plus because the idea, as discussed, is to keep the code bases as close as practically possible. This leads to a few loose guidelines:
One great example of these that has already occured is the Reimplimentation of visual styles in order to improve compatibility with Windows 2000 and earlier. As for the toolset, we haven't decided on anything yet. I'll definitely have to check out your recommendation. Oh, I think @craigwi is looking for someone to head the retro branch. I'd talk to him if you are interested. |
|
@NazmusLabs I meant that the retro branch is very good idea and I appriciate the work that has been done to be able to build it with old operating systems. My point was that is it worth of maintaining two separate branches and port the master branch modifications there or would it be enough for the retro branch that the current (original) version can be compiled by using old IDEs? |
|
@ttsirkia That's the thing: even the original_plus version, the oldest version we have in this repo, doesn't compile to run on even Windows NT4, the very OS this app directly came from, let alone NT 3.x. @MartinPayne had to make a lot of changes for the app to work on NT4. And even more so to get it running unstabley on NT 3.x. The OSes we really want 9x to achieve isn't even close to being compatible. You can see the progress he made on his fork of original plus here https://github.com/TransmissionZero/WinFile-Classic Now, the goal of retro is two fold.
We have yet to reach the first goal. |
|
@NazmusLabs Yes, I actually referred to the great work @MartinPayne has done with his fork to allow the compilation with old IDEs. It is great to have a retro environment with NT 3.51, VC++ 4.1 and compile the whole thing and see it running. |
|
Oh, and why not just keep the focus on just getting it to run and not bother with back porting commits from master? Well, then what's the fun in that? 😉. Otherwise, once we get it running, the software become "complete" and dead, not to see another enhancements again. But keeping it open to enhancements allows it to remain "living" with the possibly of it getting update. Anyone can pitch in even after the main work to get it compiled is done. This way, we leave the code as a software project that doesn't end and can always be improved upon. More importantly, it allows new people to play with older dev tools and/or learn about historical software and what it's like developing on only operating systems while at the same time contributing to a project that can actually provide value to people rather than writing another yellow world app for Windows 3.x. But that's just my view. 😊 |
|
I'm not against anything, just wondering how much extra work it mean to port the changes and what is the actual value for it. Of course, if it is purely fun, why not? :) I think this repository is currently one of the most interesting "legacy" projects. |
|
@MartinPayne It would be good to "try and get clever with the preprocessor" within reason to avoid conflicts with master |
|
@ttsirkia ah. I think the idea here is that this branch is for people who want to put in the extra work for whatever reason, be it to learn, develop skill, meet a certain need in their retro setup, etc. Most people will continue to work on master. Essentially, people who are at the time working on this branch must see some value in what they are doing, otherwise why spend so much effort. Perhaps we can look back later and see this as a great thing...or perhaps we will realize that the effort was futile and it was a horrible idea that crashed and burned. 😛😂😅 |
|
I agree with @ttsirkia, at least in the short term. We know it can work in NT 3.51 to Windows 10, and we think it could work in Windows 9x once the ANSI build is complete. However, including all the feature updates in the retro branch at this point is just moving the goalposts. I'd prefer to concentrate on getting it running in Windows 95, then focus on merging the features gradually so that we can alter any which break the build, or reject any which are never going to work. |
|
@MartinPayne sure, and it was what I initially suggested as well, and, so, I understand what you are saying. So what do you propse? A PR that to the retro that brings it back to the "vanilla" state? |
|
@NazmusLabs Or a force push of the "original_plus" tag to the retro branch. I've been having a go with MinGW this afternoon to see if I can get the build working with that. I'm not quite there yet, but I have confirmed that applications compiled with MinGW are compatible with Windows NT 3.51. Therefore, it might be best if we focus on MinGW for the time being because it's freely available and wouldn't have any problems with |
|
@MartinPayne relieved to hear MinGW us compatible with NT3.51. I was wondering if it would be ideal to do a fore push since that gets rid of every single changes post original_plus, as a lot of things like right-click suppor are essential productivity enhancements. Also things like the about dialog boxes, visual styles support, don't known have compat issues. So just wiping out these changes seem a bit drastic. |
|
@NazmusLabs It wouldn't be a case of wiping those commits out because they still exist in master. It would just be holding off from bringing in new features until we've got something working, then we could look at bringing in the features one by one and ensuring it still builds. Looking at the commit history for the MinGW makefile, it looks like the build has been broken twice due to new features being added. The same would happen to the retro build, which means it would be longer before we reach our goal of Windows 9x and potentially 3.1 support. |
|
In that case, submit a pull request to bring the retro branch even with the work you have done in your classic fork. Then others can review it and what not. |
|
So are we satisfied with the mingw version running on Win NT 3.51 and possibly Win3.1? |
|
@craigwi For Windows 95 and NT 3.51 (and 3.50?) onwards, yes. For NT 3.1, that wouldn't work because MinGW executables aren't compatible with NT 3.1. I think the only practical option for NT 3.1 is MSVC 2. @malxau appears to have had some success with that as per TransmissionZero#1. For Win32s, I think MSVC 2 is the only option too. I've had some success with my fork of WinFile built with MinGW, but it crashes on older OSes when optimisation is enabled, and part of the toolbar doesn't display on NT 3.51. It's proving a little tricky to debug though. |
|
I've been working on the creation of guides for compiling DOSBox and also improving DOSBox host OS compatibility with older versions of Windows. https://www.vogons.org/viewtopic.php?f=31&t=55706 I can confirm that the latest Mingw (not mingw-w64) for Windows can compile working executables for NT3.50+ for i386. Also both mingw and mingw-w64 environments have been zipped up and uploaded to my Google Drive so should be pretty easy to develop right away for any project. I do recommend using Linux with mingw-w64 over using mingw-w64 in Windows since occasionally you'll run into issue where the MSYS or pacman tools provided are out of date and have bugs whereas in linux they are just an apt away. Also compile times are much faster without have to go through MSYS. As far as optimization check the switches I use to compile DOSBox on the mingw guides on Google Drive with those switches I haven't had any issues with crashes when I just use -O3 and march= but others did cause crashes. If you use Mingw make sure you aren't using Mingwrt < 5.0.2 otherwise you'll run into a bug where a compiled executable run on an OS that doesn't support SSE with a processor that does will cause the executable to crash. This also happened in virtualization products like vmware since by default the processor is i686+ unless you disable SSE in the vmx file or run a TSR to disable SSE so yeah just use mingwrt 5.0.2 or mingwrt < v5. For 3.1 mabye try OpenWatcom. I haven't verified that though. I've been checking this thread occasionally, keep up the good work guys! I'm tempted to try this with HX DOS heh. |
|
Here's a DOSBox-based Win 3.1 environment (you have to install your own copy of Win 3.1) that has various kludges for transferring files between guest and host: http://www.columbia.edu/~em36/win31dosbox.html It would be good to offer an updated WinFile for it... BTW, I've got a version in testing that uses DOSBox-X instead of DOSBox, but the DOSBox version seems to work well enough. |
|
If you can't get Windows NT 3.1 to run the newer version of winfile , probably you won't get the win32s version working because if I remember correctly the win32 subset api (win32s) is mostly the same api as for windows nt 3.1 with certain parts of the api missing , if i'm wrong the api for win32s might be from nt 4.0 or 3.5-3.51. |
|
For SHARE.EXE compatible operating on DOSBOX, |
Is, of course, Don't know about |
Use VSHARE.386 for Win32s. DOSBox (and DOSBox-staging) support the use of Win32s. |
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
and, if there are any issues, if anybody without much inside knowledge would be able to tackle them.
The text was updated successfully, but these errors were encountered: