Slashdot Mirror
The State of ReactOS's Crazy Open Source Windows Replacement
jeditobe writes with a link to a talk (video recorded, with transcript) about a project we've been posting about for years: ambitious Windows-replacement ReactOS: "In this talk, Alex Ionescu, lead kernel developer for the ReactOS project since 2004 (and recently returning after a long hiatus) will talk about the project's current state, having just passed revision 60000 in the SVN repository. Alex will also cover some of the project's goals, the development and testing methodology being such a massive undertaking (an open source project to reimplement all of Windows from scratch!), partnership with other open source projects (MinGW, Wine, Haiku, etc...). Alex will talk both about the infrastructure side about running such a massive OS project (but without Linux's corporate resources), as well as the day-to-day development challenges of a highly distributed team and the lack of Win32 internals knowledge that makes it hard to recruit. Finally, Alex will do a few demos of the OS, try out a few games and applications, Internet access, etc, and of course, show off a few blue screens of death."
Making it not crash would be moving away from emulating windows, I guess?
Just over 5120 more revisions to go until a nice round number!
You do not have a moral or legal right to do absolutely anything you want.
Will there be a Ballmer emulator as well? I could use one of those in my stock market crash simulator.
ReactOS takes an initiative and gets part of its kernel rewritten in c++ ...
...
Aleksey Bragin, the project coordinator writes:
"Monstera is a new implementation of a memory manager (along with a cache manager) compatible with the ReactOS kernel at source code level and providing the same binary compatible Native API through a lightweight wrapper. Monstera is implemented in a subset of C++ programming language.
Key ideas:
1. Object oriented language for object oriented kernel. When NT was implemented, C++ wasn't that good.
4. Don't drift away too much. It's still based on NT architecture, but think of it as if Microsoft Research would decide to reimplement NT in C++ for fun."
Microsoft deliberately made the architecture of Windows so byzantine, baroque, and spaghetti-like that even their own in-house staff of tens of thousands of developers could barely make sense of it
Never attribute to malice that which is adequately explained by stupidity.
Give me Classic Slashdot or give me death!
Apart from when there is direct evidence of malice on Microsoft's front.. of which there has been plenty. They've even been convicted for anti-competitive behaviour.
David Cole and Phil Barrett exchanged emails on 30 September 1991: " "It's pretty clear we need to make sure Windows 3.1 only runs on top of MS DOS or an OEM version of it," and "The approach we will take is to detect dr 6 and refuse to load. The error message should be something like 'Invalid device driver interface.'" Microsoft had several methods of detecting and sabotaging the use of DR-DOS with Windows, one incorporated into "Bambi", the code name that Microsoft used for its disk cache utility (SMARTDRV) that detected DR-DOS and refused to load it for Windows 3.1
( a href=http://www.theregister.co.uk/1999/11/05/how_ms_played_the_incompatibility/>source article )
The article continues in that vein for quite a while..
which is totally what she said
You know that Micro$oft will "react" quite badly to this. It's one thing to be Linux where the look and feel is totally different, but if you manage to get a reverse engineered solution for Windows even close to viable, the long knives will come out.
I foresee one of two things happening... 1. The project fails because it is TOO large for the possible gains it could provide and takes too long to get working. 2. The project is successful but M$ kills it by FUD and actual legal action. Both of these are equally possible. If the second option happens, I give them about a snowballs chance of going head to head with M$ and coming out with a commercially viable Windows clone.
Good luck storming the castle boys!
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
It's an oddity, but why do we care about this project anymore? It started out back in '96 to be a clone of Windows 95. Then it was switched to be an NT4 clone. And every few years they update the website to say it's to be a clone of some newer version of Windows.
Meanwhile, it's still pre-alpha, (barely) runs on almost no hardware, and runs almost no programs. Wine is in a far better state. And in recent years, Windows' dominance has even been severely undermined by Android, providing a real, viable alternative OS that happens to be free and open source. And Linux has long since usurped it as the #1 server operating system. So after a couple decades of delays with almost no progress to be seen, ReactOS is on the verge of outliving its usefulness, before it ever started. Sort-of like GNU HURD for Windows fans.
There's plenty of open source OS projects out there that /. doesn't report on twice a year. Let's make ReactOS one of them!
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Anyone remember one of the earliest Windows dev kit? The one that came on 3.5inch floppys. I seem to remember there were 20 of the leetle buggers. And it came with a tall stack of pretty useless books too.
After I realized there were three duplicate functions for each and every action, and that the parameter list was different for the three different implementations, I returned to Unix and swore that uSoft had NO idea what it was doing.
Microsoft deliberately made the architecture of Windows so byzantine, baroque, and spaghetti-like that even their own in-house staff of tens of thousands of developers could barely make sense of it
Never attribute to malice that which is adequately explained by stupidity.
... but don't rule out malice.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
reactos was the real reason why i ported samba-tng to w32, using mingw32 to compile it up. worked absolutely great. unfortunately you cannot effectively run samba-tng/w32 under windows (without changing the port numbers) because the ports 137, 138, 139 and 445 as well as the critical NamedPipe services are already occupied... by microsoft's implementation of SMB as well as microsoft's implementation of the critical MSRPC logon services (LSASS, NETLOGON and so on) without which it would be flat-out impossible to even log in to the box in order to see if the services were running!
likewise unfortunately because wine has had to implement MSRPC (completely independently), although it would run successfully you likewise would have to change the MSRPC pipe service names as well as the TCP and UDP port numbers of the endpoint mapper (port 135) because wine has had to implement \PIPE\winreg, \PIPE\srvsvc and many others which are *also* implemented in samba-tng.
the amount of cross-over between samba, wine and reactos at the core fundamental networking level (much of NT's design was based around networking and RPC services, even when run as a stand-alone system), is just crazy. especially when you consider that it takes about 250,000 lines of hard-core intensive c code just to get even the _fundamentals_ of MSRPC correct. it's been over twelve years so i've had to stop letting people know about the duplication of effort and just let them get on with spending their time learning the hard way that they're working on exactly the same thing... without sharing any effort between them.
there's some absolute golden nuggets in amongst the wine/reactos code. periodically - every few years - i have a go at extracting the DCOM implementation from wine - to build a stand-alone GNU/Linux + w32 DCOM library. the last person who tried that called it "TangramCOM". he forgot to commit some critical bits to the repository (such as the IDL compiler). if anyone's ever worked with DCOM at a high level (using e.g. python) you'll know that it's just stunningly easy. DCOM was - still is - why microsoft has been so insanely successful after all this time. the equivalent in the MacOS world is ObjectiveC, which achieves similar results (without the networking) at the compiler-level which is pretty ambitious and nuts but highly effective all the same.
ahh, what can you do, eh?
Stupidity and malice for the win!
Dark Reflection
When Windows is used in the enterprise it's used generally because the stake holders buy into the commercial software model and have beliefs that systems backed by giant companies (be it Microsoft, Oracle, IBM, etc...) provide less risk. When a project ends up in flames at least they have a lifeline to call. Well, that is the perception. We know it doesn't really play out like that most of the time. If you're a stake holder in the other camp (lean start up, et al) then you're on an Linux based open source stack and taking advantage of the maturity of that open ecosystem. So I don't know where this would fit. I guess I could see Oracle or IBM funding it and trying to grow it to a point they could offer it as another option. Outside the enterprise Windows is just a walking dead OS.
I think it's actually a little of each. Look at the apache POI project for supporting microsoft document formats in enterprise java apps. from wikipedia:
The name was originally an acronym for "Poor Obfuscation Implementation", referring humorously to the fact that the file formats seemed to be deliberately obfuscated, but poorly, since they were successfully reverse-engineered.
The other acronyms in the project, such as HSSF (horrible spreadsheet format) are equally revealing.
It took FreeDOS forever to get to version 1.0, and it is widely used to solve issues involving old hardware. Often used in systems which control machinery.
I'd suggest that the choice to retain backwards compatibility for so long is stupidity. And it hasn't even worked very well. These days Linux is more compatible with old Windows apps than Windows is.
I'd suggest that it has also encouraged businesses to think very stupidly about in-house application development, which is where a lot of the problem is.
Essentially, lots of businesses created some in-house apps 10-15 years ago, which make use of quirks, design flaws, and bugs in Windows XP (or earlier) and IE6. Microsoft sat down to fix the quirks, bugs, and design flaws, only to find that they had to choose between dropping support and pissing off a huge portion of their customer base, failing to fix the flaws, or continuing to emulate the bugs for a decade in some kind of "compatibility mode". They've pretty much chosen a middle road that does a little of all three.
The problem is, this has only encouraged a mentality within businesses to think of application development as a one-off project. Management thinks, "Oh, well we'll just pay some programmers to develop a business-critical application, and then we'll be done with it. We'll get rid of the programmers, and the application will just keep working forever, because Microsoft will keep supporting all these whacky design choices." This is a very dangerous way of treating software development. Sooner or later, you're going to have to update your app. If you treated it as a one-off project, then you end up with a decade-long backlog of bugs that were never fixed, and a lack of any expertise because you've gotten rid of all the original programmers.
Stupidity is a entropy-like quantity, not energy-like. It isn't conserved, but it can not decrease.
Rethinking email
Good point, but this project, if successfully implemented, is more likely to catch on than the gazillion Linux distros out there, given that:
Only thing I think - this project should have 2 parts - one for win32, another for win64. The former should aim to be an FOSS XP, while the latter should aim to be an FOSS Windows 7. After all, Windows 7 loses some of its XP compatibility, which is why you have things like VirtualPC from Microsoft. In this case, just make the 2 completely separate, and let one run win64 apps on the 7 clone, and win32 apps on the XP clone. That way, one is also likely to meet the resource constraints of the OS.
They do need to have a proper team and a realistic deliverable target. And remember, they won't be playing catch-up w/ Microsoft, since Windows 7 is good enough, so they won't need to make an FOSS Windows 8. Once the FOSS 7 is made, they'd have done a good chunk of the work. Anyone can try to be a Red Hat to this software, and that alone will make them competitive w/ Microsoft.
I think "stupidity" is too strong a word. A person of average intelligence wouldn't be capable of managing a project that large. "Mediocrity" might be closer to the truth.
At 480p the text is kind of hard to read ...
Interesting to see their testing methodology and how their massive code base broke a lot of build systems!
Never attribute to malice that which is adequately explained by stupidity.
However, remember that any sufficiently advanced stupidity is indistinguishable from malice.
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh
Malice: the Windows Registry.
What happened with windows is the least energy path all software takes. It, in fact, takes a huge investment for any long maintained program to not take this path.
It is true that Microsoft, for reasons that had to do with marketing (and also the anti competition, true) took this path quicker than was purely mandated by normal entropy laws. They also defined an "always backward compatible" policy (even when apps use unsupported, undocumented, APIs or side effects), that made it impossible to invest the (quite hefty) price and refactor out the ugliness.
Still, aside from the anti-competitive part (which did not take as big a part as you'd expect), there is no evidence of malice here. Just poor engineering policy and too strong a marketing department.
Shachar
Some MS shills out there today...
I remember trying DR DOS with Windows., and the "error" messages.
I also remember installing some windows variant on a machine that had OS/2, and certain "messages".
If I had gone for the suggested defaults, the install would have wrecked my OS/2 installation.
They had some tricky wording about the partition ( the one with OS/2 on it ) probably being empty and how I would increase available disk if I "reclaimed" it...
Sleazy is what it was. You can like MS if you want to, but don't be childish with your mod points,
emt 377 emt 4
Yes, it says alpha, but I've used it, and I don't believe it's fair in the slightest. They could call the next snapshot "stable" if they were delusional enough, but that wouldn't make it truely reflect the state of the project.
ReactOS is still a mess, that (poorly) supports very little hardware, runs far *FEWER* apps than Wine, and is utterly missing most everything.
If I had much interest in Windows, I would completely change their approach around... I'd start writing kernel patches that would allow Linux to load Windows device drivers. And then I'd write a GUI/front-end that makes a Linux/X11 system look and operate just like a Windows system, with all software running through Wine. That would get them most of the way there, in short order. And if they gain any popularity with their Linux-based Windows work-a-like, then it would drive a LOT of interest in Wine. Then they'd only need Wine improvements to get their OS up to parity with Windows.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant