ReactOS Runs On The XBox

KJK::Hyperion writes "ReactOS (the open-source Windows clone) has been ported and successfully runs on the Microsoft XBox (screenshot), thanks to the interest and knowledge base of the XBox Linux project and the work of Gé van Geldorp (HAL and boot loader) and Hervé Poussineau (FATX driver)." (Read on for more.)

KJK::Hyperion continues "This port definitely establishes two facts: the XBox is nothing but a broken PC, and the kernel + HAL design that ReactOS inherited from Windows is sound - all of the changes to the core system necessary for the XBox port (namely, the blacklisting of a buggy PCI device and handling the fixed partition table on the built-in hard disk) were limited to the HAL. This is a first, important step towards better portability, as it has already underlined some shortcomings in our build system.

What the port is lacking is hardware support: especially, ReactOS has no USB support at the moment, so it basically just sits there being pretty, because mouse and keyboard won't work. The network and video cards should be mostly identical to their "real" counterparts, so the Windows drivers for them should work (except the video card, a modified GeForce - it's been established we need some HAL trickery to make the Windows driver load). We wouldn't mind some help :-)

To run ReactOS on the XBox you need our custom version of the Cromwell boot loader (not released yet) and the XBox HAL for for ReactOS."

Comments

Re:ReactOS?

[KJKHyperion]

ReactOS is Wine - everything Wine has, ReactOS has too, except the Linux-specific parts (that, in ReactOS, will be handled by drivers). And ReactOS does implement recent APIs, we're no way stuck with Windows NT 4 compatibility, in fact our current baseline is more like Windows 2000 (especially true for the kernel). Finally, we won't just get up one day and declare 1.0: it will be 1.0 when compatibility reaches the intended milestone for 1.0 (namely, good enough to replace somewhere between Windows NT 4 Workstation and Windows 2000 Professional)

Re:ReactOS?

[k98sven]

Oh please. I didn't say "Windows is backwards compatible with every single app".

I said that Microsoft tries hard to keep backwards-compatibility.

But don't take my word for it, I don't work for them. Read Raymond Chen's various blog articles on the subject. He is one of the poor souls at MS who worked his butt off to try and keep backwards-compatibility.

Re:ReactOS?

[KJKHyperion]

I believe this is pretty much what happened with ReactOS (I'm not a ReactOS developer), so I wouldn't hold it against the current crowd too much.

ReactOS was born in dark, barbaric times. In 1997, your most realistic option to build PE executables with GCC on Windows was DJGPP, the port of GCC to a DOS extender, because MinGW didn't exist yet. I have had the dubious privilege of trying that - when I joined the project, DJGPP was no longer required for the main tree, but the boot loader still had to be built with it.

Also, the "don't design, code!" attitude worked in the beginning, to get anything done and avoid the mistake of the ReactOS father, FreeWin95, forever stuck in the design phase, but it backfired when real stuff began to run. It just doesn't work when cloning a system as firmly established as Windows - you can't always attack the problems by implementing function after function, many times you need a good overhead view. The short of it is that we have some embarassingly bad code in the kernel.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Hmm Running a..

[WJMoore]

...where is the slashdot article for reactos?

That would be here:
ReactOS 0.2.3 Released
Steven Edwards On The Future Of ReactOS And Wine

Re:Hmm Running a..

[AstroDrabb]

No. Wine doesn't "intercept" anything. It is not like WINE has some _HUGE_ switch statement where it just "intercepts" Win32 calls and translates those to Linux calls. WINE has _rewritten_ the WIN32 API (well, a lot of it so far). For example, I write a program with an API to control it with functions like:

sendMessage(int, int)
beep(int)
sleep(int)
phoneHome(int)

Now, you come along and rewrite those some functions for your program with the same "function signatures" (which just means the same function names, parameters and return types). Your not emulating/intercepting me, you have _totally_ rewritten what I did on your own. Granted, what I did above was very samll and the Win32 API is HUGE. That is why it has taken the WINE team (the core group is pretty small) a long time to get a large part of the WIN32 API rewritten to the Linux platform. For example there is a Win32 API called CreateWindow. That _same_ function had to be recreated under WINE in Linux. Under Win32, it creates a window with the Win32 API. Under Linux, it takse the same parameters and creates a window using the methods that the Wine team created.

You are correct in the sense that the WINE team has tried to "emulate" the look and feel of the Win32 API. That is why a Win app under WINE often looks the same. They (WINE) have tried to make the windows looks just like a window in Win32. However, at the end of the day, WINE is still not emulating or "intercepting" anyting. They are recreating API's and copying a look-n-feel.

Re:What a horrible idea

[KJKHyperion]

Windows applications are not legacy. Linux is not a Windows replacement. BSD neither. We are totally, absolutely, positively sure: it's a Windows clone we want. We don't all secretly dream running Linux, and in fact several of us must fight the puke back when forced to deal with it (except KDE. I like KDE. I'd like it even more if it ran under Windows). Some have had their weird ideas phase, but you get over it soon.

We're tired of hearing about this every damn time, and I'm not speaking personally here. Even the Linux users among the developers are fed up with that argument. It doesn't make sense, ReactOS is real, is here, today: deal with it already, because at the point it is now, it's not just going to go away.

Your technical argument doesn't make sense, either. One of such DLLs you talk of is called "the Windows kernel", and it's a pretty big piece of software (a 2+ MB binary, for the record). And it has a private API to talk to the HAL. And one to the authentication service. And another to the event logging service. And yet another to the PNP service. Each of these services can be queried by applications with an undocumented RPC protocol. It's a recurring theme in Windows: most APIs have two sides with unknown grounds in the middle, and many DLLs expose multiple client sides. Picture the graph in your mind. No, more arcs. No, way more than that. Yes, you're getting closer, and yes, that arc does go twice the same way. Etc.

One has to wonder why couldn't Wine just provide a loader for Windows executables and let the (air quotes) D-L-L-s (air quotes) do the rest, if your statement had even the slightest trace of truth in it.

Please don't trivialize our work, which is something you apparently don't fathom in the slightest