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?
Will there be a Ballmer emulator as well? I could use one of those in my stock market crash simulator.
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
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.
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
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
3. States targeted by the NSA find it more viable than switching to linux, fund it to completion, and most of the world stops using Microsoft's version.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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!
And yet you write like a 15 year-old...
Nothing you've said about it hasn't been repeated innumerable times, over a decade ago.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant