The Xbox OS isn't "a custom version of Windows 2000". They took the networking stack and a couple other bits from NT, but otherwise it was built from scratch.
XQEMU hasn't "struggled to emulate the original Xbox OS and kernel" - it's a low level emulator and thus just emulates the Xbox hardware with no knowledge of the OS.
> The Xbox OS isn't "a custom version of Windows 2000". They took the networking stack and a couple other bits from NT, but otherwise it was built from scratch.
From the whole Win2k obviously not, and it is common for journalists to not be very precise, but at least the kernel seems to have tons of architectural similarities with the NT kernel, and I would not be surprised if it was a derivative?
I also found https://books.google.fr/books?id=-8YlaRclj2gC&lpg=PA603&pg=P... and that's pretty much what I expected. But nobody who knows the difference about kernel vs. whole windows OS think that they would take explorer.exe and random obscure IT stuff and so over, and 150k is not crazy big, but for a core OS kernel this is completely expected.
The high level API seems to be based on a subset of DirectX and even a few pieces of Win32, so that's not completely unrelated either. It's obvious that the GUI was not taken from Windows, that you won't be able to maybe install a printer and so over, and it is probable that tons of custom code was also written, but that does not make the relationship disappear completely.
The scheduler is radically different and that has knock-on effects on the rest of the OS. The OS gets a fixed time slice every frame before control is handed back to the game. The security model is engineered to distrust the user of the device as an anti-piracy measure.
It might be a derivative, but calling at a “custom version of Windows 2000” is absolutely wrong.
There are also custom scheduling policies in the XBox One IIUC. I agree that a “custom version of Windows 2000” for the original XBox is wrong, but it is not extremely consequential in this article, I can see where it comes from, and I don't think its erroneous enough for it to be a big deal to be presented like that to the public; only experts will find the distinction interesting.
Saying it is a custom version of Mac OS, I would call it absolutely wrong. Here, just wrong is enough :p
The 20KB stripped down Windows kernel that shipped on the XBox isn't hard to emulate...emulators such as CXBX do this for many functions by calling the respective windows function on the host. Low-level emulators (XQemu) take the opposite approach by emulating well understood hardware (hdd, cdrom, usb) and then running a binary dump of the xbox firmware (which contains the kernel, it's not on disk) directly.
To my understanding the hardest problem in XBox emulation is the GPU, and unfortunately this doesn't help with that.
Sure Nintendo might have just downloaded the rom, but they may have:
1) just concatenated the prg and chr roms and added an iNES header so they could validate in third party emulators. (Likely extra helpful for games where they were developing anti-epilepsy patches, since third party emulators have some really nice debugging tools.)
or
2) Used a third party cart dumper that adds the iNES header, because it was faster and easier than setting up a 3.5 inch floppy drive to try read the original rom from the archive. (And much faster than retyping in hex dump printout from the archive).
I never understood why music publishers care so much about licensing for old games. Are they worried people are going to put on GTA3 to avoid buying a couple songs? It makes more sense to me that playing old games would encourage those song sales.
Before your comment I thought the more likely reason that Microsoft qualifies games is to reduce the amount of development and support effort needed for their emulator. Even Halo 1 struggled to get some good framerates, IIRC.
a bunch of nintendo console code leaked earlier this month as well, including the code for the gamecube.
any big emulator project that wants to maintain legitimacy is going to stay far away from these leaks. they'll send out messages on mailing lists warning developers NOT to look at the code and NOT to go fixing bugs based on the leaked code.
an emulator is legal as long as it's a clean-room implementation. if an emulator suddenly gets way better after a leak, it's going to draw some legal attention.
I don't think it is a honey pot, but you do make a valid point around the grey legal area to even read the code.
The linux directx module that microsoft pushed earlier this week might not even get code reviewed because of the risk of reading patented interfaces that could taint the developers future work: https://www.phoronix.com/scan.php?page=news_item&px=Microsof...
> an emulator is legal as long as it's a clean-room implementation
And this is why it is often done on completely legitimate open source projects, and many projects don't shy away from doing so. Wine, ReactOS, and many more regularly do so completely legally.
that reactOS kerfuffle is just one of many, many examples of how a tainted clean-room design can completely derail an open-source project, and most stories have a nastier ending than that one.
the dolphin emulator team (gamecube/wii emulator) made a statement on the nintendo leaks:
I'm trying to think of a good use case for exploring the NT 3.5 source code but I can't really think of one. It had the Windows 3 user interface and a number of enterprisey things like telephony (TAPI) and UPS control, but was overall pretty bare-bones.
I remember a few quirks. I lacked a CD drive and borrowed one to install NT 3.51. When I gave the CD drive back, NT wouldn't boot. It turns out that it installs ATAPI.SYS if you have a CD, which won't boot without it. It installs ATDISK.SYS if you don't have a CD.
System administration was pretty clumsy. I really began to appreciate the text file based UNIX philosphy over the point-and-click Microsoft approach. I had been dual booting NetBSD and OS/2 2.1 before that.
Nonetheless it was solid compared to Windows 3.1 and 95. Perhaps being limited to what it was, it'd be easier to study the native api and how it was being accessed by the several subsystems (Win32, OS/2, POSIX). A much lighter version of NTFS was running on it. I remember at the time you needed a windows source license to write a filesystem driver. I was using Visual C++ 4.0. 100Mbit ethernet was fast for the time and I was a little jealous of people using 155Mbit ATM.
I'd love to try and have a go at compiling the NT3.5 source. What tools would I need? There are Makefiles and things in the archive, but having installed MS Visual C++ 6.0 in a Windows 2000 virtual machine, it still seems to be lacking commands like "build" and "nmake" which are referenced in these files... Does anyone have pointers?
What mystifies me is that the core of the OS is actually pretty good. I've never had any issue like a blue screen since a decade ago. The kernel and driver subsystems are rock solid. Had a few occasional GPU driver crashes but those are mostly the fault of the driver devs and they don't cause a system reboot since Vista.
Why is the userland so bad in comparison? are they employing much worse developers to take care of the windows explorer/search/browser side of things? it is true that if you really try to pay attention you will notice many quirks and bugs here and there in the user interface interactions, with the start menu search being such a horribly visible offender (also bugs in the explorer search box).
Microsoft managed to make a uniform looking user interface for both win9x and XP/Vista/7, why are they having so much trouble with Windows 10 control panels?
Agree that Windows 10 seems to get the difficult stuff right. Stability, security, advanced graphics infrastructure, and very impressive backward compatibility with old binaries. Also agreed that the new control panels are a trainwreck, offering no advantages whatsoever over the old control panels they're trying to (very gradually) replace.
It's also incredibly bloated. Gone are the days when a few gigabytes would be enough for your Windows partition.
That's a good example from the demoscene, but that was done as a tech demo, rather than as a serious commercial product. To illustrate the bloat of modern software, I think it's better to point to examples of highly compact 'real' software.
Of course, a great deal of effort must have gone into squeezing it down to 8MB, and it wouldn't be reasonable to ask modern developers to go to those lengths, but still.
The most annoying thing in Windows 10 is the damned file explorer jumps three seconds after you have just opened it and clicked on a folder. Makes you have to reposition the view a second time.
Windows 10 is just layers built on top of layers all the way back to nt, you have to remove stuff instead of adding it to make it better.
the funniest part is that you can have literal archeological expeditions from the menus, each click bringing you further back in its history https://i.imgur.com/K0xEDaN.png
you can get back to components so old that are out of the new styling as well, taking the right turns: https://i.imgur.com/NWR6Epm.png
For a small team (or individual) to evolve the code to the point where it had parity with Windows XP would be a herculean effort, never mind Windows 10.
They were working with code that already pretended to be in protected mode anyway (with the exception of locking and unlocking blocks of memory... which was unnecessary with a hardware MMU.)
Even saying that, it was amazing at the time to run essentially unmodified 'real mode' binaries in protected mode. (There was a tool that would take an existing binary and set the 'okay to run in protected mode' flag.)
yeah, they go into that in the referred-to book (The Personal Computer from the Inside Out).. though spectacularly irrelevant in this day and age, it still makes a thrilling read, for me anyway ;)
It does me too... I was an early high school computer enthusiast/programmer around this time, and remember waiting for Windows 3 with bated breath. At the time, I didn't appreciate the engineering and politics behind what went into Windows 3, and it's fun to look back on it all in retrospect.
I never liked the product as much, but the same thing's true for me for Windows 95. I remember waiting years for it, and then all the drama around Schulman's work to try to uncover _undocumented_ API's that Microsoft was reserving for itself to give its software an advantage. The AARD code is about all I remember of that that was real. (And of course now, Apple has undocumented API's all over its products, and it doesn't get nearly the press that that did then.)
The Xbox code leaked in 2004 and was passed around extensively. You can find public download links from even ~2010. This was discussed in the popular 2005 CCC talk: https://events.ccc.de/congress/2005/fahrplan/attachments/591...
The Xbox OS isn't "a custom version of Windows 2000". They took the networking stack and a couple other bits from NT, but otherwise it was built from scratch.
XQEMU hasn't "struggled to emulate the original Xbox OS and kernel" - it's a low level emulator and thus just emulates the Xbox hardware with no knowledge of the OS.