Sometimes I wonder why every single release of ReactOS seems to make the front page of HN. Then I'm quickly reminded of how well-written, interesting and detailed the release notes are. It's like reading through an adventure story where the contributors are heroes. More open source projects should have this.
I suppose it's because ReactOS is replicating Windows, that is, it awakens fond memories of old activists (times when MSWin was the private enemy number one).
Nowadays, I guess the new activist would be more bothered by something that can replace Android (or Apple for extra kudo).
Nobody perceives ReactOS as a threat at the moment, but I wonder what Microsoft's stance would be if the project developed much faster, for example by receiving funding from a bigger institution...
Cut Windows licensing charges for corporates to ensure that the total cost of ownership of Windows is lower than ReactOS. IMHO ReactOS should target corporates who have old Win32 apps still running on XP or Win7 that they can't or won't migrate to Win10.
There should be a ReactOS crack team out there, helping people with such things. I have seen in the corporate world, virtual machines running Windows XP, carefully hidden from the watchful eye of the Nazgul, I mean corporate IT. Why? Some function or other can not run in newer versions of Windows.
However, such a ReactOS installation would hardly be blessed by IT either... not anymore than a random Linux installation. :-/
Where I think ReactOS could shine is in the embedded realm. In that realm, you often have custom development anyway. 100% compatibility is often not needed. You might have product initially done on Windows Win32, then tweaked to run on Windows CE (or whatever they call it nowadays). Instead you could tweak it to run on ReactOS and call it day. Since ReactOS can take standard Windows drivers, getting BSP support should be feasible.
Also, ReactOS should offer EC2 images like Ubuntu does:
I've seen that too - but with corporate IT dept support - at a large UK mortgage lender running a loan origination system initially built in the 90s with an MFC Win32 GUI. Over the years the system has been so heavily customised by the vendor that it's practically bespoke. Migrating the existing system to run on modern OSes, or adopting a new system would be a huge expense, and can't be justified by any rational cost benefit analysis. IMHO there's a huge overhang of legacy Win32 GUIs out there. I'm hoping they'll fund my retirement.
I don't think it's possible for ReactOS to target corporates anytime soon with the current device driver database - Linux + WINE will do much better at the moment.
Has anybody tried running some old computer viruses on it?
Or what about those "tech support" calls you get, where they try and take over your Windows computer? It would be fun to follow their instructions in ReactOS, mainly out of curiosity (and to screw with them).
Seriously, next time you get a call from one of them, give them an excuse to ring you back later; then install Virtualbox, ReactOS, some mic and screen recording software, and wait.
At the very least, Steam OS was kind of a far off hedge. Like building a fallout shelter in your back yard. Pretty cheap, kind of spectacular, very low chance of it being used. But, boy, should the need arise you'd be happy to have it.
I don't think that was the original intent, just what it came to be after it was clear that Microsoft wasn't going to aggressively dismantle the open* nature of Windows as a platform. Based on Microsoft's language around the Windows App Store and UWP at the time, and just being Microsoft, that was a reasonable concern.
*That is, open for anyone to develop and release software for without going through a third party.
What a waste of time and energy the Windows Store and UWP are. I've yet to see any apps on there better than the pre-existing standalone ones, and the developer messaging on that front has been all over the road. At various points C++, C#, and JS have been touted as the way to go forward, but from where I sit everybody is still banging on Win32.
The big holdup with UWP, IMO, is that they strictly limit access to the file system. And if you want to give an UWP program access, up comes the age old win32 picker dialog.
If MS really wanted UWP to take off, they should have bundled a UWP file manager on par with explorer, and a matching picker.
As it is, UWP is just another .NET dumped on top of the same old win32/NT base.
From a technology standpoint, no it's not. UWP is very much closer to the Win32 roots than .NET ever was. UWP is COM+ basically, with a thin wrapper.
From a marketing, developer's and practical point of view, I agree with you 100%. They bet so much on UWP, yet their footsteps falter the last mile. UWP is like running an Android emulator on your PC - you have 2 different worlds at once. Really weird and it must confuse "normal" users much more than us who know a lot about both the history and the technology.
Indeed, Microsoft's UWP (Universal Windows Platform) would've come with an app store [1] and that was a big threat to Steam much moreso than gaming in general.
I've just tried to install it as a VirtualBox VM, and it kinda works! I had to select a different network adapter for the network to work, and the screensaver screen made the system unresponsive. But it's still impressive.
I totally love it that it has a 50/50 chance of getting stuck in the login screen like a Windows 98.
What did you do to get the network working specifically? I was hoping that adding the legacy network adapter would do it, but it prompted and subsequently failed to install an ethernet driver after I did.
I tried with limited success on a very old laptop (on the previous release):
* USB drives didn't come up correctly - it couldn't see anything past the "root" hub (as an end user it was just a USB port on the laptop).
* Wasn't able to connect to the internet using either the Belkin wireless card or the standard ethernet port.
* Stability was relatively impressive, didn't handle lack of RAM too gracefully though.
As there wasn't an easy way to get any kind of media into the laptop, I gave up. Getting either of those working well could at least extend the usefulness to being a great writing machine. Gvim + LaTeX and I'll be fully away.
Half the time I think a person wanting to rip off Windows (I know, I know) would be better off writing a Windows 95/98 looking X11 window manager and hacking it to only use Wine. Seemingly for free you would get tonnes of hardware support and the obvious benefits of Wine. You could even emulate the "upgrade whilst shutting down" behaviour to update Linux underneath. I think you could quickly end up with something that would pass at first glance.
> Half the time I think a person wanting to rip off Windows (I know, I know) would be better off writing a Windows 95/98 looking X11 window manager and hacking it to only use Wine. Seemingly for free you would get tonnes of hardware support and the obvious benefits of Wine. You could even emulate the "upgrade whilst shutting down" behaviour to update Linux underneath. I think you could quickly end up with something that would pass at first glance.
This was attempted once with "Lindows" (later renamed to "Linspire" after the inevitable Microsoft lawsuit). Wikipedia informs me that they're actually still around in one form or another and owned by Xandros these days.
Apparently [1] Lindows -> Linspire -> Freespire [2]. There's also Xandros Desktop OS but that's apparently discontinued anyway [3].
I never personally used Lindows (or any variation of it), but I'm pretty sure you could create an experience that users would find pretty difficult to distinguish between Windows and Linux for the most part.
The key would be making sure everything is redirected through Wine and for the most part the OS does all the maintenance itself. Then it's just a case of wrapping some common utilities with a Windows like layout and it should be good to go.
Lindows was interesting. Windows was much more relevant then, not as much web stuff going on, no mobile apps. Unfortunately, Wine was not very feature complete, so it fell on its face quickly.
Lindows launched in 2001 IIRC. At the time, Wine didn't have regression testing, so someone hacked up a simple test-runner in C, called it "winetest.exe", ran the tests on Windows 95, 98, NT 4 and XP, and submitted it the Wine project.
The idea was to capture how actual Windows works, so Wine could implement how Windows actually works, not how you'd think it works just from looking at API docs.
I'm especially curious about a use case for building and testing binaries that could be deployed on Windows. Is it reliable enough and high enough fidelity that it won't introduce false positive/negatives?
