ReactOS 0.4.7 released
reactos.org
reactos.org
Although I don't follow ReactOS, I thought they were working on supporting older Windows (Wikipedia says they try to run on Windows Server 2003 drivers). So does this mean they are catching up so fast to newer Windows versions or are we in fact seeing (very) old browsers in these screenshots?
I'd naively assume that finishing the undocumented API calls of the last century is a much more time-consuming task than adding what little came after 2003...
The Application Store has Opera 12.18 (from 2012), so I used that to try and download Chrome. Chrome tells me my computer isn't supported, but offers a download anyway. But when I try it, the installer stops after "On your marks!" so I have no idea how they took that Chrome screenshot.
Opera 12.18 is running okay so far, though.
In fact, for the last 10-15 years, Wine itself to some extent is written against Windows kernel APIs such as ntdll.dll, and only the lowest levels talk to the host OS and wineserver. This means that ReactOS can keep also some of Wine's lower level DLLs, such as kernel32.dll, as long as there is something below them.
I should try it in a VM again, maybe I can get my old VB6 IDE running again...
Why? Just run delphi 7 so that you at least will have sane exception handling ;)
But on a more serious note I wonder how the lazarus-ide will do on ReactOS.
Mostly for Nostalgia...
During Thanksgiving I talked to my Uncle who gave my family our first computer and also asked him if he remembered giving me his old copy of VB 3.0 to install. We couldn't remember if it was 20-something or 30-something 3.5" floppy disks but I remember feeling really cool being the only person out of my programmer buddies who had a legit VB 3.0 install.
It doesn't seem to deal well with the audio and network drivers, though.
I had no luck installing visual studio 6 in my vm. My old copy of borland 5 seems to be installing just fine, though.
Edit: I may have spoken too soon; I had to run bcw.exe manually, and got a message about 16 bit WoW not being supported.
1. Modern .NET for desktop apps, whose many semi-obsolete UI frameworks make Java's UI tools look simple
2. Learning HTML/JS/React/Redux/CSS/Bootstrap/Python/Django/SQL/SQLAlchemy/Webpack...
Neither is likely to appeal to someone used to how easily applications could be created in VB6 or Delphi.
(I believe this so strongly I cofounded https://anvil.works, which is basically VB6/Delphi for the web. That's not so much a disclaimer, I guess, as putting my money where my mouth is :-P)
I don't see how Delphi + VCL is any easier than C# + WinForms, especially given that the latter is a GC language.
However, the reverse engineering work of ReactOS developers has indeed benefited Wine too.
What did they "steal" that is of value that nobody can access after the "theft"?
Also their not alone because there is a `etc\hosts` file in my windows driver directory.
for context https://forums.freebsd.org/threads/41109/
Apple's XNU is actually also released as open source (for the most part; last I checked, the parts that pertained to iOS weren't exported). It's based on Mach (which wasn't licensed in an open source way! http://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/license...) as well as 4.3BSD (which is BSD-licensed).
If a company comes up with a new feature for a piece of open source software, it is in their best interests to push that code upstream. When they do so, the maintainers will continue to develop new features while maintaining this upstreamed feature. As long as someone else finds use in that feature, the company basically recoups their "investment" made by publishing it.
This is true no matter what OSS license your code is published under. And companies that don't upstream their code will fall behind those that do (except when it comes to companies that deal with drivers and hardware; that's a whole different ballpark).
With less-copyleft-than-GPL licenses, companies are allowed to choose what they share. I believe this weans them onto the Open Source train rather than purely allowing them to steal from it.
If you're rallying for software freedom above all else, why not back the AGPL instead? It's so copyleft it's GPL incompatible, because it covers SaaS as well as traditional software.
I don't see issue with other open source licenses, they all push toward the correct direction. I just also prefer licenses that prevent corporations from hiding the code in a binary after selling it. Sometimes the corporation benefits from taking an adversarial relationship, especially those who are hoping to hide their flaws and backdoors from users. You can argue once the users find out it really hurts the corporation, and they'll always eventually find out, but you can bet that the shareholders will have cashed out long before that happened. While the best growth is always mutual gain, some are willing to take a less effort win/lose, and I would like to be able to trust that some of our software is safe from that. It's my personal opinion that FreeBSD throws pearls to swine, and that we should be using such a license for libraries that we don't mind being incorporated into commercial software, but not for our entire operating system. We both benefit from the competition, but I don't see much benefit in giving the most powerful party even more power than they already have.
I keep testing my own Win32 Photoshop plug-ins on ReactOS, and they seem to work fine in my makeshift graphics editor. I'm having a hard time finding any glitches at all with those plug-ins now.
As I mentioned elsewhere, Opera 12.18 works okay, and I'm posting this comment from ReactOS & Opera (installed via Parallels Desktop).
I made it because my products are Photoshop plug-ins [2], but a lot of people were downloading them without having Photoshop. People would complain after installing that there wasn't a program to run. I thought including a bare-bones standalone graphics editor (no layers, no selections) with the Photoshop plugin download would solve that problem.
Actually, it didn't move the needle at all. Seems the people most likely to buy already had Photoshop / PaintShop Pro etc anyway. But it's been useful for running tests on ReactOS, or back when I was using Wine instead of Parallels on my Mac.
I would hope the OS can support a truckload more than four browsers! I would be interested to learn how well ancient Internet Explorer versions work.
I assume the screenshot must be old versions of the browsers.
If you want Chrome you need to find Chrome 49 (Chrome 50 ends support for Windows XP) and run it with --no-sandbox key
c:\dir\ssvn update
This might take a while, so please be patient.
Local Revision: 76032
Online HEAD Revision: 76032
Your tree is up to date.
So, can anyone confirm for me that 76032 is the reversion that they're calling 0.4.7?
There are lots of people who could switch to Linux if certain apps worked well under WINE. With the anti-user shenanigans Microsoft is doing in Windows now (e.g. using upstream bandwidth to seed updates, sucking up people's Internet connections, and potentially busting their data caps), this is needed now more than ever.
But no one's going to replace Windows with ReactOS. For example, is ReactOS going to keep up with drivers for current hardware? Of course not. Do they regularly release security updates? No. But Linux and Linux distros already do. So improving WINE helps people actually switch off Windows to a safer, less anti-user system.
I just don't understand. WINE is like a necessary evil, a noble sacrifice of its developers' time to enable users to switch from Windows to a free, open platform for the applications they can't run on one natively. It's a sensible abstraction that enables something that wouldn't otherwise be possible.
But why reimplement Windows, the whole OS? If the devs enjoy it, it's their time to use as they choose. But the end result would be much more beneficial for users if it were put toward WINE so users could leave the Windows platform behind.
Unlike Linux, ReactOS doesn't need to: one of the design goals was to provide binary compatibility with regular Windows drivers.
But even if that all works as well as it does in Windows, it's still inferior to Linux. Users are stuck with whatever binary drivers they can get, and whatever reverse-engineered, bug-for-bug compatibility the ReactOS developers can manage. It would be much better for users if they could run WINE on Linux.
They don't need to. They do implement whatever needed to have ABI compatibility with actual Windows drivers, so the vendor driver should work.
1. I presume this requires "bug-for-bug compatibility." How feasible is this without access to either the Windows source code or a lab full of machines and QA staff?
When a user gets a ReactOS BSOD because of a bug in the ReactOS driver ABI, what do they do? Even if they can report a bug and it eventually gets fixed, what do they do in the meantime? The answer is, probably, boot back into Windows and get their work done. Then they have to justify to themselves taking the time to try ReactOS again sometime in the future.
2. How many machines in the wild can run without any Microsoft-made drivers included in Windows releases? If the answer is less than 100%, those users will still have to own a copy of Windows.