That being said, I think he is overestimating the market that would pay for this. This seems like it could attract at least a small community as an open source project, however. Unfortunately effort in development is not always rewarded with monetary gain.
Perhaps he should license it as GPL3 and offer commercial licenses? He may find some customers in software houses that are still selling Win16 software.
His approach is a bit different as he is shimming 16 bit APIs to their 64-bit equivalent. Wine reimplemented them to run on top of a POSIX environment.
His approach will result in higher fidelity for apps as they are basically running on Win64, just with a 16-bit virtual machine driving it.
Wine apps running on Windows would likely feel non-native as the UI components are reimplemented from scratch.
Wine actually has (mostly) functional theming support-- point Wine to a .msstyles theme DLL and it'll draw themed controls (rather than the Windows Classic style default).
They just don't ship a theme with Wine; understandable for licensing reasons (they can't distribute Microsoft's designs), but it means that Wine looks like Windows 2000 out of the box.
I find it a bit amusing that were they to "update" their look to that of the flat Windows 8+ UI, it would probably entail the removal of a lot of code.
...and yet even on a 25MHz 386, no one complained about the slow drawing speed of the "fancy" 3D buttons in Win3.x.
Well, modern flat design generally also includes a much more animated interface, which would probably entail the addition of much more code. And I don't think the drawing speed of buttons was ever a very strong reason for the rise of flat design - though I completely understand your distaste for it.
16-bit applications can't run in long mode (i.e. a 64-bit OS), so you'll need a 32-bit OS to run these apps in WINE. WINE is just a shim and a library reimplementation, not an emulator, so it just passes the instructions on to the CPU, and you're limited by what the CPU can do.
Hmm... I wonder if you can run 16-bit applications in WINE on a 32-bit VirtualBox VM running on a 64-bit Linux system. That sounds like overkill, though. Might as well just use PCem or DOSbox, depending on your use case (PCem: cycle-accurate emulation of a whole PC, including specific hardware models and running any OS a real PC could; DOSbox: playing some old games for fun).
TBH, I'm not sure what win3mu's point is, either: it probably won't be open-source, and right now the only reason to not use PCem or DOSbox is if you don't own a legitimate copy of Win3.1 and you're not willing to pirate it. An open-source clone of Windows 3.1 that can run any Win16 program in long mode (by interpreting the instructions like an actual emulator) would be a great idea, but this isn't it.
But yeah, I don't think it's explicitly supported since it's not their target market :) Codeweavers' focus is running Windows apps on Mac and Linux (Crossover - go support them! https://www.codeweavers.com/)
Edit: It looks like they completely dropped support for it as I can't find any of the old articles anymore; Seems it only supports mingw setup now. https://wiki.winehq.org/Cygwin_and_More
Crossover is a commercial version of Wine which includes a bunch of extra hacks for popular applications. It comes with support. It's how the Wine project pays salaries.
PlayOnLinux is a Wine wrapper which has preset configurations (best known working wine version and dll overrides) for a ton of popular games/software. Think of it like a virtualenv on steroids.
This seems ... insane. Good insane, learn-me-a-lot in-the-weeds insane but insane nonetheless
In the "why?" Section he mentions how a lot of programs don't run due to the quirks of the Windows API, and he is twiddling things to fix them.
Raymond Chen in "the old new thing" (#) documents his job at Microsoft which was to basically ensure windows handled crappy API calls that third party secs would make and any upgrades or alterations would break. They explicitly added code to windows like "if running adobe XXX then make our API call YYY perform differently and not return a Null"
This was a huge Microsoft department working over many years.
You flat out cannot emulate the Windows API. You just can't.
And all to run games that people today will find amusing for less time than it takes a Venti latte to get cold.
I was a Mac user and didn't play PC games until the Win32 era, but were there very many games for Win16?
I thought that targeting DOS was still common well into the Win95 years.
Also, there was a transitionary predecessor to DirectX that some (primarily edutainment) games released for Windows 3.1 (and for a short while into early Windows 95) called WinG. So far as I know most of the WinG games also relied on Win32s to get access to 32-bit code, but I don't know if Win32s was a requirement to build a WinG game or if there were 16-bit games for that platform too.
So, it's a closed source implementation of an API for an old OS/Windowing system atop DOS. Despite the fact that both DOSBox and Wine will run them fine.
And it's aimed at gaming, but most games quit windows and just ran on straight dos, so DOSBox is a better option anyways, especially considering that you're expecting me to pay for this, even though you've already said the compatability isn't great, and Wine and DOSBox are free and both have excellent compatability.
Or, a really interesting project plus a great series of blog posts.
From the FAQ on the author's site:
>Is it open source, can I contribute?
>>Thanks, but no thanks. This project was started as a personal challenge/learning exercise. To have others contribute would defeat the purpose right now.
Which I don't quite agree with (why not just not accept pull requests?), but it's fair enough.
It's specifically aimed at old Windows Games, of which there are many. It's not for old 16bit DOS games like Monkey Island or Elite for example.
So people out there have stacks of old CDs with freeware Windows Games on them (popular on the covers of the Magazines of the time) - this project would nicely re-open the use of these games.
Additionally, if he completes this, then there is a also a LOT of old 16 bit productivity and encyclopedia type software that never made the jump to 32 bit.
...But DOSBox and wine play all of this software better than this thing does. It had well-established, free, more compatable competition.
This would be inconsequential if this was a free utility which wasn't being sold as a commercial product, but it's not. It's a full commercial product, and if it's not better than freeware in it's main focus area, that's a problem.
Are there still apps for Windows 3 people would use on modern OS'? I'm under the impression you would run a VM if you really must, until/if when you make a transition.
I have one I'd love to use but it's no longer usable even under a VM. It's an audio mixing game called "No World Order" put out by Todd Rundgren back in 1993. It was a Windows 3.1 app, but remarkably worked up until I switched to Windows 7 64-bit. Even then, I could get it to work reasonably well with Windows XP in a VMware VM. Sound and graphics compatibility have never been a big priority for VMware, and the most recent VMware Workstation update seems to have broken the audio to a degree that I can't play the game anymore. I'm going to try VirtualBox at some point, but it's increasingly difficult to get a new Windows XP system up and running.
While you wait for Delphi 1, note that you can already obtain Microsoft's 16-bit Visual C++ compiler and linker at no cost (the same does not apply to 16-bit Visual Basic) and that Open Watcom has been released under an OSI-approved, if weird, license. This tutorial goes into more details: http://www.transmissionzero.co.uk/computing/win16-apps-in-c/.
I've been following the blog posts with great interest but I don't understand the move to turn it into a commercial project. I just don't think there's enough demand, especially for games (how many Win31-specific games were there?)
Where this would be incredibly useful would be for a lot of industrial automation, POS and other commercial software still stuck on Win31. Seems like it would make more sense to release an open source version and then add stuff like raw serial/parallel support as commercial add-ons to cover these cases.
Still, I don't blame Brad for wanting to get some return on his investment, he has put in a huge amount of work and it looks like a very well thought out and executed project.
I'd be fine if it stayed closed source and cost a few bucks to start, and then went open source after the initial revenue stream dried up.
Right now I run a WinXP virtual machine to play SimAnt and SimTower... I know nothing about VMs and was able to get everything installed and working in about 2 hours. So "messing with" virtual machines is not too much time, other than downloading and installing them.
Seeing as the Windows 3.1 crowd would be very niche, they'd most likely have no problem paying a small fee. I just hope it does go open source afterward.
I use Windows 3.1 a lot, mostly to play Solitaire. (Yeah, I could play a newer Solitaire implementation, but I like the nostalgia.) Also, my 3 year old son uses it for Paintbrush and Write - again, I get some nostalgia watching him using Windows 3.1 (although I myself didn't start using Windows until I was 9 or 10).
This is a cool idea, but running the real thing under VirtualBox appeals to me more. (Although it is slightly screwy - full-screen mode DOS boxes corrupt the display - due to using svgaptch to patch svga256.drv to support higher resolutions and colour.)
Yes, Wine implements the Win16 API. I just tried tetris and ski and the both worked fine in wine-1.9.22 (Staging). Didn't even need to even create a 32-bit profile.
I'd recommend PlayOnLinux instead of using your distro's Wine. Makes it really simple to have a separate prefix per application, and is usually updated with new versions very quickly.
Seems like a whole lot of hassle for little gain. A lightweight virtual machine should play those games perfectly, no? This guy is porting a huge amount of ancient APIs and their bugs too! Insane.
If you read his development blog-posts, it's mostly a lightweight 80186 emulator, plus forwarding Win16 calls to their Win64 equivalents; he's not re-implementing Windows from scratch.
There's an argument to be had about FOSS vs. proprietary software in general, but I think it's pretty clear when it comes to emulators. There is something wrong with closed-source emulators. Everyone who develops an emulator for a platform is working towards the common goal of preserving the software that runs on that platform so that people can continue to use it well into the future. All emulators build on research about the platform that has come before them, but if they don't release their source code, they don't advance the state of the art themselves. They're only useful for as long as they're actively developed and their closed-source binaries are compatible with modern operating systems, which means they haven't contributed to preservation of the platform.
Also, it's not like proprietary emulators are neutral towards the goal of preserving their platform, they can actually be detrimental to this goal. If Win3mu becomes more popular that QEMU/Wine, users will raise bug reports against Win3mu and certain issues will be fixed only in Win3mu. When the Win3mu dev loses interest or the platforms that Win3mu runs on become obsolete, those fixes will be lost. God forbid people will have to start running emulators on emulators when the best emulator for a certain platform stops being compatible with modern operating systems.
> God forbid people will have to start running emulators on emulators when the best emulator for a certain platform stops being compatible with modern operating systems.
Sadly, this is already happening. bZSNES is actually a thing now, since so many popular SNES romhacks will only run in ZSNES (i.e. not on real hardware, and not on a more accurate emulator like Snes9X or Higan), but ZSNES is written in 32-bit x86 assembly and contains a massive security hole that's been known for a while but hasn't been fixed.
It's even described as "a portable ZSNES emulator".
https://github.com/mudlord/bzsnes-libretro is a port of some kind (NSFW commits possibly). Has byuu gone into hiding? His Twitter is protected and I can't find any safe source for the "original" bzsnes.
byuu posted an article on his blog (byuu.org) just two days ago. His emulator was called bsnes, not bzsnes, maybe that's the source of confusion? bsnes has now evolved into higan, so that might also be why you can't find it. The higan source is mirrored on gitlab: https://gitlab.com/higan/higan
edit: sorry, wasn't aware of the (april fools) bzsnes release, realise now that I'm probably more confused than you are.
Nothing, but if you read the other comments, people here are worried that he's over-estimating the market size. But we all wish him the best. Hopefully, he's either done his due diligence or he's primarily in it for the fun.
That being said, I think he is overestimating the market that would pay for this. This seems like it could attract at least a small community as an open source project, however. Unfortunately effort in development is not always rewarded with monetary gain.
Perhaps he should license it as GPL3 and offer commercial licenses? He may find some customers in software houses that are still selling Win16 software.