ReactOS 0.4.11 makes great strides towards running Windows apps without the Windows Those keen to indulge in a bit of open-source Windows in the form of ReactOS will be delighted to learn that there is a raft of improvements in the latest version. We last looked at the project in July 2018 and came away impressed by the nostalgia factor of running what resembles Windows 9x, if still a little confused by the …
I have several small ham radio programs that require Windows and no great desire to bugger about with Windows X. What with all the Spectre-type issues, eventually I will want a new CPU, too; however, Intel and MS made a crappy little deal to not support Win 7 on Intel's newer processors.
So React OS might be just the ticket for those of us who need to run Windows programs, use a newer (hopefully Spectre-free) CPU and avoid Win X.
> Intel and MS made a crappy little deal to not support Win 7 on Intel's newer processors.
Are people still misunderstanding this ?
It would be suicide for Intel to make new x86-64 CPUs that are not compatible with earlier ones such that they won't run Windows 7.
What Microsoft have actually said is that Windows 7 will not be enhanced to use the new features added to later CPUs, while Windows 10 will be.
"What Microsoft have actually said is that Windows 7 will not be enhanced to use the new features added to later CPUs, while Windows 10 will be."
Microsoft will not support the extra instruction sets, nor the drivers for the new chipsets that are 'needed' to run the newer CPUs, nor will they provide windows updates as its not supported.
"Microsoft will not support the [...] drivers"
That's nothing new, try running XP on the latest hardware and you'll probably find it unable to detect any storage. Or for that matter, try running an equally out of date version of Linux on modern hardware, you'll probably be stuck with a CLI only screen, again, assuming it can even detect modern storage. Given the incredible range of hardware both support, it's pretty impressive that (for example) XP could work with SATA drives.
An out of date Linux wont necessarily give you no X Windows, most cards these days still support VESA and you will be fine with the VESA framebuffer driver. Besides, who needs a GUI ;)
As for storage, AHCI SATA can be dropped to Legacy mode. Then it will look exactly like a PATA connection and will work just fine.
You would have trouble with USB3, possibly not USB2 as I think UHCI devices are compatible with USB1 drivers however I'm not sure. If you are going back that far however, good luck.
>What Microsoft have actually said is that Windows 7 will not be enhanced to use the new features added to later CPUs, while Windows 10 will be.
What they have done will be enough to deter most people. I have some customers on RYZEN and Windows 7 and it works OK but with extra effort on my part.
React OS is likely to be very useful soon.
"React OS is likely to be very useful soon."
YES!
Question: who has something/enough to gain by investing in ReactOS in order to market it, distribute it, support it, and get it installed onto new computers at Dell and Lenovo?
I will continue to target Win32 API and windows 7 or XP compatibility for ANY windows applications I write. I _hate_ ".Not" and C-pound anyway, and this is 'yet one more reason' to keep going in the same well-trodden direction.
It is indeed a lousy decision, but there are ways around it. "wufuc" will remove the Windows Update block, drivers for Windows 7 are available for Ryzen CPUs (I run Win7 on my own Ryzen system without any issues), and I have also managed to get a Kaby Lake system functioning perfectly with Windows 7 as well.
This was done by using some earlier Intel drivers for most of the components, then modifying the .inf file for the Intel IRIS drivers to get them to install (the only bit I had significant trouble with). The hardware ID for the IRIS graphics only exists in the Windows 10 section of the .inf file meaning that the drivers won't install on Win7 if IRIS graphics are detected, but if you copy the IRIS line into the Windows 7 section and tweak it to match the formatting of the other Windows 7 lines, the drivers will install fine and all 3D features will be available.
Yes, it's a bodge and not ideal, but Windows 7 can run on later silicon with all hardware functional.
Of course, it's only really viable for one more year, and I also am watching ReactOS with interest!
Long shot I know, but there is a chance MS will open source the NT kernel before ReactOS gets close to being finished.
A few years ago such an idea (i.e. MS open sources the NT kernel) would have been seen as laughable. Today, what with their love of Linux, open source, and making money by being a services provider, it's not quite such an unrealistic idea.
M$ will not open the NT kernel this side of 2050, if ever.
And anyway, the kernel itself isn't the big problem. The basic drivers (NTFS is/was a big problem for ReactOS), the zillion support DLLs... that's the trouble. Implementing that and implementing it in a 99.999% compatible way is very hard.
Nevertheless, perhaps... in another two, three years... I might install it in a Linux host as a guest for those pesky little apps for which I can't find a Linux replacement and which don't run in wine.
Meanwhile Wine is coming along in leaps and bounds.
There might not be much Wine won't run in two, three years.
MS will not be releasing anything that might be an advantage to anyone other than as a by-product of some important MS objective. All the 'loves open source' is endearments from an undercover cop.
They've acknowledged open source is better at fostering developer attention, and that affects what tech and platforms invariably get used in business, and adjusted accordingly to prevent becoming an old bear like IBM, but that's it.
There might not be much Wine won't run in two, three years.
Gad, I so hope you're right. I am still struggling with wma/wmp issues trying ot get (32-bit) Links 2003 to run on Wine 3.0 on Linux Mint. (Yes, I should probably to update to 4.x, and see how that works. Maybe this weekend....)
"Meanwhile Wine is coming along in leaps and bounds."
It's worth noting that Reactos user-space libraries are largely imported from and kept in sync with Wine and as such progress in Wine causes progress in Reactos too. Reactos adds lower layers which reimplement the windows Kernel, drivers and key services rather than emulate them by calls to Linux APIs.
Whether having a windows-like kernel helps run your use case better depends on what, exactly, that use case is.....
Meanwhile Wine is coming along in leaps and bounds.
There might not be much Wine won't run in two, three years.
All depends on the presumptions your application is making about it's environment. As an example, the wife & daughter like to play this horrid abomination called "Roblox". The core application could "theoretically" be run under Wine, but it has to go back & forth between the application that actually *runs* the games, and your web browser that selects which one you want to play (stupidest UI decision ever). Would work fine if you could get Wine to use an install-specific browser (Codeweavers calls their application-specific containers "bottles"), but so far it insists on using the host-OS one, which has fuck-all clue of what this "Roblox" function-call is.
I'd try running Roblox in a VM, but VirtualBox 6.x is severely broken (they took on the Microsoft methodology of testing) and you can no longer get a *usable* ROS install in VBox. And the ROS folks seem uninterested in making a validation suite for outside testers to run on physical hardware.
I like Wine but it lacks some basic compatibilities even now.
A short time ago, I installed wine on a Devuan system. It gave me a ration of crap about being 64-bit only, and said something about installing the 32-bit version alongside. A zillion more dependencies later, I had both of them .
Then I tried to run a 32-bit application from within the 64-bit Wine thingy. *FAIL*
I re-ran as 32-bit [after some issues with path and the server thingy being 64-bit and still running, etc.] and could run the 32-bit application, but could NOT run a 64-bit application.
And there seemed to be NO way to actually have both 32-bit _AND_ 64-bit wine SIMULTANEOUSLY running. The server thingy was one or the other, and that was it.
OK maybe I did something wrong but 'out of the box' performance should have been easier to set up, then. The application ran, even installed itself into the Mate menu structure. I was moderately impressed.
(that application was one _I_ wrote, with XP and 7 compatibility)
There's still a need for a Windows replacement now and it will remain so for a few years yet. There are many reasons for this but probably the most pressing is that there are some situations and compatibility issues where a direct replacement for Windows is just a more practical option than a Linux/Wine combination.
I already use Linux and Wine but on some machines—and given that we've vowed never to move beyond Windows 7 because of the Win 10 spying fiasco—it would be easier to just replace it with a non-MS O/S that ran Win32/64 APIs in native mode.
Yes, it would have been great to have a solid-working ReactOS or equivalent a decade or two ago around about the time XP hit the scene but that was not to be. In those years, I was a strident critic of ReactOS and in many of my posts, I called it the 'Going-nowhere OS' but essentially this was out of sheer frustration more than anything else was. With it becoming stable so late in the day it's very unlikely it'll ever now reach the utility that it once ought to have deserved.
(I could never figure out why the vehement opposition among many, many elite techies to Microsoft and its high-90s percent monopoly of the O/S market never ended up providing more than just a trickle of support for ReactOS. (As was the case in earlier days with the Tandy TRS-80 when the cognoscenti quickly and eagerly replaced TRS-DOS with the considerably more capable NEWDOS-80, you'd think both commercial and open-source developers would have been falling all over themselves for a piece of the Windows-clone action.))
"The basic drivers (NTFS is/was a big problem for ReactOS), the zillion support DLLs... that's the trouble. Implementing that and implementing it in a 99.999% compatible way is very hard.
Of course, you are correct; the core issues are driver and DLL compatibility and ensuring the majority of main apps run on it without crashing. Over the years, ReactOS has been plagued with stability issues and the lack of drivers; it has been the major reason why up until now I have only viewed it as a curiosity. I've not tried this version yet but I've noticed that over the past year or so it's stability has improved very significantly.
In my opinion, the moment users perceive ReactOS has become stable and reliable then much more development is likely to follow. Changes will quickly follow; for starters expect to see the drab W2k UI to be titivated almost immediately.
Microsoft will not have failed to notice that open-source Darwin has had no impact on MacOS/iOS sales.
There is a big motive to open-source NT Executive with Hyper-V before the disapearance of the final chance to displace VMWare,KVM,Zen as the default hypervisor for new servers
I actually think that MS would rather make their desktop run on a Linux back-end (like a desktop manager) before they bother open sourcing any of the NT-based kernels.
Reason: too many 'ghosts' in the code
because, you KNOW people will grep it for profanity, unusual comments, and outright poor coding style
A version of Windows that runs on top of a Linux kernel (like Wine but an approved version) would work. There was a subsystem for OS/X that did something like that, XP compatibility - even had a DVD for it in my MSDN when I still got DVDs sent to me...
Y'know, there are many "little" programs designed to do useful things on old versions of Windows. One example that come to mind is the software to check the OBD-II codes on my 15 year old car. Another is a collection of little educational games that the school I used to work in made available in 3rd and 4th grade classrooms when the weather precluded outdoor lunch or recess. The kids seemed to enjoy them and I think that they may actually have learned a bit about arithmetic, history, or whatever. I doubt most of those things will run on a modern Windows. And I doubt they've been replaced by something "better". Some would doubtless run on Linux under WINE. And some doubtless wouldn't. I'm sure there are many other useful programs in school, business and personal contexts that have been left behind in the relentless march toward some glorious future that I must confess I can not quite visualize. If REACT extends the availability of old, useful, software, that's a good thing I think.
This quotation is attributed to George Mallory, regarding climbing Everest, not long before his death trying t climb it.
Viewed as a hobby, hat's off to them. As a practical project though, I think it's questionable. Windows is a monster of an OS to replicate, and they seem doomed to always be a decade or more behind.
I have to wonder if they wouldn't be better off focusing on being a being a better WINE. They could based on top of a specific Linux or BSD distro and come pre-installed and pre-integrated.
They might also look into coming out with a server version, also based on a sort of super-WINE. There are probably quite a few people who have legacy Windows server software, aren't tied into vendor support, and can run it in a VM.
The world has changed greatly since the ReactOS project started. A lot of software has moved to the web for example, where the browser and not the OS is the platform. For that which isn't, more people interact with Android on a daily basis than Windows. As a consumer OS, there's not much future in emulating Windows, outside of games.
A lot of businesses are locked into Windows for the reasons of legacy software, but most large or medium size businesses aren't going to run a large estate of ReactOS desktops without vendor support.
There might be a place for running specific types of legacy software on Windows for those who have otherwise binned Windows altogether and don't care about vendor support, but do you really need a full OS to do that?
The best thing, from a Linux perspective, is that it gives us somewhere to point all the people who just want "Windows but open-source" to!
(And there is not necessarily anything wrong with wanting that! Other than that Linux is "UNIX but open source" so has never been a good fit and trying to shoe-horn it into the role just leaves both sides feeling dirty and miserable!)
Speaking of software a release or few behind the current (desktop) iteration, I went to my local copy-and-print shop today. Their machines run MS Win7.x Embedded. Not that long ago, about six or so years, they were running MS WinXP Embedded.
If ReactOS has twice the feature list at half the size, twice the speed and twice the security, I think Canon, Fujitsu, and the like are going to take an interest.
>Their machines run MS Win7.x Embedded. Not that long ago, about six or so years, they were running MS WinXP Embedded.
If ReactOS has twice the feature list at half the size, twice the speed and twice the security, I think Canon, Fujitsu, and the like are going to take an interest.
Yes, I also think the market for ReactOs has characteristics similar to the eComStation (formerly OS/2) market. The only question is whether the markets are sufficiently different so that both companies/project sponsors aren't in direct competition.
"As I understand they share a lot of the code base with Wine and work together"
VERY good point... if Wine development _AND_ ReactOS development collaborate, perhaps things will get to a "production worthy" state faster, while simultaneously IMPROVING WINE [and dealing with the problems I noted above, for example]
Viewed as a hobby, hat's off to them. As a practical project though, I think it's questionable. Windows is a monster of an OS to replicate, and they seem doomed to always be a decade or more behind.
I have to wonder if they wouldn't be better off focusing on being a being a better WINE. They could based on top of a specific Linux or BSD distro and come pre-installed and pre-integrated.
Consider all those specialized control systems that have MSWin XP-based control software. Million-dollar CNC machines that require users to maintain old, clunky XP machines because they're not just going to throw the machine out merely because MS decided to break the API in later versions. Making a currently-supported, API compatible and source-code changable OS to take on these jobs is just one use I can think of right off.
The possibility of running that one absolutely stubborn application inside a minimalist MSWin build. Or perhaps for running a stripped-down gaming system without all that crap MS wants to force on you.
I've muttered bad-temperedly here before about finally ditching Windows when W7 support dries up, since it has been, IMHO, the best OS from MS. The later spyware versions will have no place on any personal system that i use (sadly, I may yet have to keep a laptop, infected with W10 rescued from the kill shelter, for working with clients). But, as I've also said before, I like some software that regettably is not ported/portable to *ix. I will cross-train to Gimp if I must, but Paint.net is just so damn nice to use! I am utterly familiar with the W7 UI, which is excellent for multi-large-monitor non-touch desktop use. Heck, behind a solid firewall and AV, it just works, year after dependable year.
The short version is: like many others, I'd actually pay money for a desktop OS that would run Windows applications without spying on me or trying to lead me into the punji-trap of subscriptions. Give me an OS equivalent in performance and functionality to W7Ultimate—with no upgrades, ever—just doing what it says on the tin, solid properly-tested security updates maybe monthly as necessary, and I'd pay a solid wedge for it and a few quid a year for the security fixes. (Oh, and It will need to support VMs. Various Linuxes hang around these parts, too.)
And since this is almost certainly a pipe dream, I guess that in a year or so, I'll be typing from a Linux desktop, and Gimping ....
PROTIP: You don't have to be in Linux-Land to use either the GIMP, or Krita Image / Drawing Tools. There are also other free Lightroom alterintves, that are in my opinion superior to the offerings of Adobe. in the form of both Dark Table, and RAW Therapee. All of these Programs will happly run under your copy of 64Bit Windows 7.
So you can slowly go, and get yourself acquainted with every one of these Programs, with out ever having to ever see a single <SEE ICON>
If the last version of LR you used was 2.0, probably... and good luck when printing on high-end photo printers in Linux, you'll have to buy TurboPrint to get them supported - and still, the tools are too basic.
Even photographers attempting to use a full Linux workflow found they have to use a Mac to print properly....
integrating gimp with ReactOS distro, as the primary graphics editor, sounds good to me. Also Libre Office, and editors like pluma. Anything Qt or GTK could (in theory) be compiled for it, right? There are probably installable packages for most of these already.
I haven't installed the new one yet, just remembering what I saw from last time. I still have to download the new ReactOS image now and test it in a VM. Last time I was moderately impressed, though it was not ready for prime time or even occasional use. Some difficulty getting the VM to work, too. Multimedia was the worst.
this time, still hoping
Ditto. I get the feeling that Microsoft may be making a big mistake with its approach to Windows 10. It doesn't really offer anything compelling over Windows 7, but instead brings with it a whole bunch of hassles, including the fact that an update might brick your system or remove features you have been using.
I also can't see subscription pricing going down well with consumers who have just splashed out on a new PC, to be told that they need to pay a monthly fee to Microsoft just for the pleasure of using their computer.
Not to mention weird and unduplicatable bugs - mail not working on random identical machines installed from the same build, machines refusing to shutdown via any method other than the CLI or the lock screen, try it from start and it just sits there doing squat.
Start menus that randomly don't open or close.
I'm really regretting moving to 10, on 7 ultimate machine was solid and never had any weird glitches, end of 7 support puts me off going back though and I have a tonne of software that only works on windows (I play a lot of games when I get time)
"I also can't see subscription pricing going down well with consumers"
ack, but Micro-Shaft will do a "froggy in hot water" maneuver to prevent people from noticing and/or complaining hard enough to affect their bottom line. Same with removal of Win32, which I expect to happen at some point, forcing EVERYONE to "go UWP" and/or "go '.Net'" or it won't work in Win-10-nic...
Hopefully theyll get to WIndows 2000. And stop.
Which is where MS should have stopped.
I know loads of compnaies that have crappy little programs that are essential to a larger, expensive product/process, which, due to 'WIndows everwhere!' only run on W2k/XP.
Having a free version of that platform would be great. Not the free bit, but the workign bit.
You know that Windows 2000 didn't support 64 bit CPU, and CPU had a single core? And was designed when memory was still counted in megabytes? Nor terabyte SSD disks existed? Or 10+ Gb Ethernet or USB 3+? What about Windows 2000 security?
To support properly all of that, kernel changes are required, and user space code as well.
Then, sure, you can avoid to make a GUI mess thinking web apps have a good design, and in attempts to become like Google fill the code with "telemetry".
But you can't really stop keeping an OS up to date.
I'm pretty sure Win2k has support for SMP... Boards from both AMD, and Intel from back in the day, when counting the "Cores" was as simple as counting the number of Sockets that Board had.
Yeah Ok this was probably more of a stacked racked config, then say something sitting inside a 200x's Mac Pro. with more thorughly modern Xenons then the Pentium II/III era Xenons from back then.
SSDs? What would that have to do with the OS? Or am I just being a silly goose for asuming that being SATA... Your SSD should have to adhear to LOL the ATA / IDE Spec? Which is as old as DOS!
USB 3.0 / 4 /4 2x2 etc... Yeah ok that could be an yitch... Asuming you wern't able to write the low lever kernel Divers for that. 10+Gib.... LOL remind us how long 1Gig Ethernet has been around again. By my count at least as long as Win2k. And, how widely do you think 1Gig Ethernet has been adopted within that time? Well AVM (Fritzbox), a huge player for Modem / Router / Wifi Boxen, only just got 'round to adding GigE to the line, about what Five Years ago. So forgive me if I refuse to hold my breath for a solid 10GE anytime within the hours of whatever remains before this even bcomes a thing, outside of the Enterprise market. /Clarkson rant
RAM (Or a lack thereof), probably would also need to be adressed in the modern age.
But, these are NOT the things in which the Op had in his mind surly when he wrote, what he did. And, for what its worth. Win2k was the best OS they ever came out with. Windows VII could be the second. I'm gonna dismiss XP as being little more than Win2k with DirectX (Whatever version it got up to at that point... Google it yourselves!), and a lick of stylish Blue Paint to soothe the inmates in then asylum.
Technology has changed. Yes, Windows 2000 has support for SMP, but to make best use of modern processors a more recent version of Windows is needed.
SSDs have a different access pattern, store data differently, and work better with TRIM support when the flash is filled.
10GbE is only used in Enterprise markets as it's too expensive for consumer use, but that doesn't mean it's not required. Gigabit Ethernet has been standard for over the last decade.
Windows 2000 was an excellent OS, but time and requirements have moved on.
64 bit is standard for even consumer kit these days.
>I'm pretty sure Win2k has support for SMP...
Need to be careful not to confuse server and desktop versions. But certainly W2K Pro did support 2 physical CPUs.
Windows XP-SP2 didn't have multi-core support, MS had to release a hot fix. Even with early SP3 systems it was advisable to check the XP system setting limiting the maximum number of CPU's had not been set. Windows XP Profession x64 ran really well on a dual quad-core Xeon system...
SMP <> multicore. It could have looked at them as different CPU each with its own socket, but that would have been far less optimized to understand how many cores you have on each CPU - because things on the same dye are different from things that have to communicate across sockets. Moreover it would be a problem for applications licensed by socket and not cores. Moreover new features are introduced to improve the system performance. Believe me, you wouldn't like your latest core i7 or Xeon to be used as a Pentium II.
SSDs: they need to be treated very differently from spinning disks - or you get less performance and more wear, never heard of the TRIM command, for example? Also, PCIe/NVMe allow for far more parallelism and longer queues - it's far better if the OS and its file system understand what disk technology is available.
ATA is younger than DOS - the first PCs didn't use IDE/ATA.... that came later. Initially, the IBM PC used the ST-506 interface. Thanks to god OS kept on updating their support for disk technologies.
10+G - if you speak only about cheap consumer devices - as you imply with your home routers - you could be right. But Windows does run in datacenters - where the real money are made - were 10, 40 and even 100Gb Ethernet are routinely used - and in high-end workstations as well. And it's not only drivers, the whole networks stack needs to be optimized for the higher speeds. Maybe on IPv6 to...
RAM. as RAM availability increase, and the more cores becomes available (and new CPU features), the memory manager code may need changes, sometimes big ones. sometimes deep changes. If you read "Windows Internals", you'll discover that each version of Windows has under the hood changes to improve how memory is used - which is one of the main factors of performance.
The GUI changes were not limited to the look&feel - the whole GUI subsystem has to cope with larger displays with more pixels (and higher dpi), and more demanding applications. The GDI of Windows 2000 was designed when displays rarely went beyond 1024x768. Improvements like Direct2D, color management, etc. were needed to allow for more demanding application. 2000 didn't have even ClearType to smooth font display. And there are a lot of "hard limits" in the code which were later removed.
I'm sorry, but your knowledge of Windows looks limited to simple consumer needs. There's far much more at stake.
"You know that Windows 2000 didn't support 64 bit CPU, and CPU had a single core?"
I set up w2k in a VM once, on a multi-core Intel 'Core Quad' system, and with a little tweeking it ran OK, dual core even. But it did have a nasty habit of consuming 100% CPU all of the time. Then again, Win-10-nic does that, too...
Also w2k has support for multi-processor, which might as well be the same as multi-core. And didn't the article say that ReactOS has Ryzen support in it?
I really think that the Win2k reference was for the user interface, and NOT the kernel side. Kernel side would need to support multi-core hyperthreaded processors with the most recent architecture and peripherals and windows driver models, compatible with 7 at the very least...
[and when applications query the windows version, ReactOS should optionally say it's Win 7 or Win-10-nic so that they'll still install]
WINE translates from win32 calls to calls in another operating system (usually Unix).
ReactOS natively implements the APIs and the driver model in an open source project. This means native Windows drivers can be used.
It's still early days for the project in terms of APIs implemented, so not all drivers work, but some official network/video/sound card drivers will work in the same way they do on real Windows. Also, the way ReactOS is architected, older driver models currently unsupported by modern versions of Windows are still supported.
Once ReactOS is compatible enough to run the applications you require, it's then possible to change the source if Windows imposes unwanted restrictions.
Wishing to access my income tax account online, and having failed with Verify and Experian, I tried HMRC more directly, but the credit reference agency that HMRC used took two seconds to tell HMRC that they should not recognise me.
So I am not allowed to look at my income tax account, though I have been paying income tax to the Inland Revenue and HMRC for several decades. It seems that one needs to have a credit record in order to be recognised as a person.
I recounted my failure in a YouTube video on GOV.UK HMRC so boring that it has only been viewed eight times in two weeks. Who cares?
I am very interested in trying to find altenatives to run "Windows" audio apoplications on for the future, I do hope ReactOS can run em.
Going to give this a spin this weekend to see if I can get Cubase, Traktor, SoundForge and a few other windows based audio apps working.
This would be amazing if it can run said apps, I still use W7 for these currently as Windows 10 is useless for pro audio apps. I gave a good 2 weeks of testing before a W10 update killed off ASIO and forced a Video driver on the machine which ended in a BSOD loop!
Will be interesting to see what pro recording studios use in the future (the non Mac ones).
Wierd you say you have issues, I am on the inw 10 insider program andMy MSI Laptop has never had any issues with ASIO4ALL when used in Traktor 2 and 3, Soundforge, Cubase, Ableton and others. Its way mre stable than it ever was running Win 7, even on the current skip ahead 20H1 bulds.
There's massive potential for a Windows-replacement in the NHS
We're having to migrate a vast number of machines away from Win7 at present. If Emis, Vision, SystmOne and all the associated peripheral softwares could be made to run on ReactOS then there would be the chance of a major shift in what we do
Good luck but as the people in Munich found when trying to ditch Microsoft, they didn't take it lightly.
The NHS must be a huge cash cow to Redmond. Any reduction in the number of licenses will IMHO result in a nuclear strike and a gazillion software licence auditors arriving to enforce the MS Licence rules to the letter. Woe betide if you have an old system lurking in some cupboard somewhere that was superceded yonks ago, if it can run windows they will expect you to pay them loadsamoney.
Yes, I'm overexagetating but having been on the wrong end of an MS license inspection due to an oversight in accounting it wasn't pretty. They even tried to count personal laptops in with the corporate ones. A lot of people made a hasty exit of the building removing thier own devices. Until then we operated a BYOD policy. That went out the door along with the CFO the next week.
...is to know when what they've got to offer and what they've done is 'Good Enough'--and then declare ReactOS 'done', except for the occasional point upgrade.
There are a lot of very valuable and entertaining programs which would--or will--run on ReactOS which will NOT run on Microsoft's latest--i.e., last many years--monstrosities.
These "new" operating systems suffer from the same, or worse, indignities, of most all "modern" operating systems, including Linux--the need to offer more and more "features", which include more and more totally 'un-fixable' serious problems ("bugs" is a much-too-nondescriptive term); and whose totally useless upgrades--which, as often as not--result in a WORSE version of the operating system, after having to run all night long. But the assurance is that the new problems introduced will be 'fixed' in the very next upgrade, folks--which will, of course, require another all-night, or 'right-in-the-middle-of-what-you're-doing' upgrade session.
Even "bug fixes" in the latest-and-greatest 'feature-laden' versions of some of the most famous linux operating systems are now so extensive that 'bug fixes' are now effected by one simple procedure and strategy by the developers: the bugs--even very serious ones--which are discovered and reported are simply ignored. After all, who can be bothered with pesky bug fixes when we're working on the latest, greatest, and NEWEST feature-laden distro which HAS to be out IN SIX MONTHS?
Encouraging news, particularly possibly for older hardware with 32bit driver only to be supported on 64bit hosts.
If ReactOS guest run in VM on a host that has PCI passthrough support in both motherboard and CPU, then that ReactOS guest in theory could see the hardware on the host which the host itself doesn't have drivers for. However with the Windows 32bit drivers installed in the ReactOS guest then this itself can utilize the hardware.
Some progress has been made here, with graphics cards but I'm interested in other hardware such as the Yamaha SW1000XG sound card which runs fine on 32bit Windows 10 with its Windows XP drivers but not on 64bit Windows nor Linux at all. The solution proposed here could resolve this.
Vintage but useful hardware could have its life extended, costs reduced for user not having to buy new hardware and reduced landfill. Good all round.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
