Win3mu – Windows 3 Emulator(win3mu.com) |
Win3mu – Windows 3 Emulator(win3mu.com) |
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.
(In fact, it strikes me now that if you're on Windows 10, you could probably run Wine on the WSL.)
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.
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.
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 wish him luck and happiness :-)
hot patching and shims is still a thing in W10
Or am I wrong?
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.
Sorry, not interested.
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.
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.
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.
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/.
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.
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.
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.)
That 80s sound is back in force at the moment (under the "synthwave" moniker). Think Stranger Things OST.
Also, this one fits the Windows 3 nostalgia theme nicely (okay, not quite 90s music but still retro)
https://github.com/wine-compholio/wine-staging/wiki/Installa...
(Are you referring to the use of software like Colinux and Andlinux? Those only worked on 32-bit systems last time I checked...)
Here's an admittedly very old article by Dan Kegel on how to compile it on Windows: http://www.kegel.com/wine/wow.html
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
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.
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.
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.
edit: sorry, wasn't aware of the (april fools) bzsnes release, realise now that I'm probably more confused than you are.
edit 2: the "original" bznes source (AFAICT) is on archive.org: https://web.archive.org/web/20151105124237/http://snesemu.bl...
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.
...and yet even on a 25MHz 386, no one complained about the slow drawing speed of the "fancy" 3D buttons in Win3.x.