Slashdot Mirror
ReactOS Runs On The XBox
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."
Now the cheapest personal computer running windows you can buy! Under $200 USD!
-1 Idiot!
ReactOS is not an emulator. It doesn't even resemble one. Not even a little bit. Its not like Wine which is so darn close to being an emulator it might as well be. It is a totally different piece of software.
ReactOS is a F/OSS operating system, and here's the catcher, designed to look and run like Windows NT 4.0.
Note to self: No more arguing with the faithful.
The Cache of the Image
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)
Make a difference - use Windows! (open source clone of Windows NT)
No. ReactOS has been in the making for a very long time. (For example, it aims for Windows driver compatibility... With NT 4.0.) It shares some code with WINE. In other words, a very different beast.
The cached HTML doc refers to the image on the original server. You're not helping.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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.
So what you're saying is it emulates an API. Right?
No more than my car emulates a mode of transportation employing paved streets, or Mentat's MPS emulates SVR4 STREAMS (or even BSD sockets).
Wine implements the API.
this will help their steaming, smoking server... I believe mirrordot has a local copy of the image.
Screenshot (pops)
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.
Make a difference - use Windows! (open source clone of Windows NT)
USB controller is in the nVidia southbridge, then there is a 4 port USB hub chip connecting to the USB ports that are gameports.
I obviously know that Wine is not an emulator since the sentance you cited states that Wine is not an emulator (slightly roundabout yes, but not so terse as to be easily mistaken to mean something else).
The difference is Wine intercepts Win32 calls and translates them to something the Linux system can understand. However ReactOS doesn't have to intercept these calls to the Win32 API since it is _duplicating_ them directly.
Note to self: No more arguing with the faithful.
Comment removed based on user account deletion
Comment removed based on user account deletion
That would be here:
ReactOS 0.2.3 Released
Steven Edwards On The Future Of ReactOS And Wine
You're kidding, right?
A usable, workable microkernal that snuggly runds Win32 by design, and you're suggesting they give up and poke and Linux some more?
And let's not forget that they have essentially "joined WINE" -- both projects apparantly share rather liberally between each other.
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.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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
Make a difference - use Windows! (open source clone of Windows NT)
I look forward to the modded controllers with CTRL/ALT/DEL. Kick, block shoot and reboot.
I'd like to see Plan-9 for XBOX, now that would be some funky fun to be had.
Doesn't a CPU emulator also implement the specification of the CPU?
Yes, and so does the native CPU. I wouldn't say that implementing a foo is sufficient to say that it's emulating a foo.
I suppose it comes down to a definition question, but here's the basic rule-of-thumb I might tend to work from (and it's just off the top of my head):
An emulator:
Wine meets the first criterion: it implements the Win32 API. It also meets the second. However, it does not meet the third, because it doesn't track much state. It doesn't need to track file descriptors, or TCP/IP connections, etc, because it can leave that to the underlying OS.
Generally, I call something meeting 1, 2, and 3 an emulator. If it meets 1 and 2, I tend to refer to it as a "compatibility layer". Wine is an example. So is the Linux compatibility layer of FreeBSD (which is sometimes informally referred to as the "linuxulator", but this is taken as a fun name rather than a formal description). I'm writing a compatibility layer for a project at work now, to translate $myproj v1 API calls to $myproj v2 for-- you guessed it-- backwards compatibility. But the v2 portion tracks all the state.
I don't generally refer to things as an emulator unless they meet all three. Bochs is an emulator. So are SPIM and WABI. VMware is an interesting case: it emulates most of the hardware, but only a little bit of the CPU; the bulk of the CPU work is done natively.
If you don't consider Nitfol or a JVM as emulators, you may want to add the criterion that the interface they implement must primarily exist in a non-emulating implementation. I probably would include that criterion, but that would mean I'd have to go back and edit this post.
Think of emulation as a software reimplementation of hardware, usually on a very low level. Emulators often emulate a system and interpret the machine instructions, whereas this is providing facilities for the applications to run on a C/C++ level.
Hehe, I recently downloaded ros-explorer and the amazing thing is... it even works on windows 98! (yeah, i sometimes have to kill mmtask to get it started, but err, it's not like the thing /was/ designed as a replacement explorer for win 98 :)
http://www.sky.franken.de/explorer/
change system.ini to run taskman instead of explorer then launch ros-explorer, it's cool!
"Ge van Geldorp has been fiddling with getting ReactOS on the XBox: I think most of the differences between a standard PC and the Xbox can be handled by using a custom HAL for the Xbox, after all, that's what the HAL is for. At the moment, we build 1 HAL, based on the value of MP in config it's either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is based on preprocessor statements. I'd like to be able to build 3 HALs in parallel, the UP, MP and Xbox HALs.
Alex Ionescu noted that a new kernel will probably be needed to sucessfully get ReactOS on the XBox. This is because, despite how hard Microsoft tried, the kernel is still architecturally dependant to a degree. Furthermore, between Steven Edwards and Alex, they decided that ReactOS on the XBox would be complicated by the lack of BIOS, proprietary graphics, lack of legacy I/O, proprietary PnP, etc.
Steven eplains a little more about the propietary graphics: [It] is a standard NVidia GeForce Chip minus a VGABios. VBE works fine on it and we have been in discussion with the xbox-linux people about how to trick it in to working with the Nvidia windows binary driver. The Windows driver supports everything from the old Riva cards up through TNT, GeForce[2,3,4}, etc. All we have to do is add a few hacks to videoprt.sys, the HAL and a few other places and it should load according to the research I have done. They have not done this on Linux already because of lack of resources.
GvG hopes that it won't be necessary to put Xbox specific code in the kernel, but I'm not 100% sure about that.
Maritn Misuth brings up an interesting question regarding how ReactOS will behave under the XBox: I've heard that XBOX WinNT kernel implementation has only around 120 kb in mem, allows single process only, (propably windows messaging) is done by polling and has not memory protection, so games can access hardwae directly. Will ReactOS on XBOX mimic this behavior? This was answered with a definitive "No". The XBox port is meant to run ReactOS on the XBox, not to create an XBox OS. It should be noted that the port of ReactOS is not mean to run XBox games (like the XBox WinNT kernel port by Microsoft), but merely to run ReactOS on the hardware."