The State of ReactOS's Crazy Open Source Windows Replacement 208
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."
Wow, this is still around? (Score:2, Interesting)
Gotta hand it to the guy, he's got some tenacity.
A spin-off of a previous attempt to clone Windows 95, development started in early 1998, and has continued with the incremental addition of features already found in Windows.*
[*] - http://en.wikipedia.org/wiki/ReactOS [wikipedia.org]
samba tng ported to w32 (Score:5, Interesting)
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?
Not sure who the target audience would be. (Score:3, Interesting)
Re:Wine and ReactOS are casualties (Score:4, Interesting)
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.
Re:ReactOS is a good name (Score:5, Interesting)
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.
Re:Just complete it (Score:4, Interesting)
Android devices are already displacing a large number of desktops. There's little difference between a large tablet with a keyboard, and a desktop (or laptop, actually).
With rather full-featured and mature browsers, office suites, printing support, and a vast array of available software, I fully expect Android to continue encroaching on desktop computer usage. There is NOTHING to prevent it from doing so, over time as legacy Windows apps (slowly) die off.
And what do you plan to use your open source Windows 7 clone OS for, two decades from now?
Re:Wine and ReactOS are casualties (Score:4, Interesting)
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,
Re:Wow, this is still around? (Score:4, Interesting)
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.