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.
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.
It might be a derivative, but calling at a “custom version of Windows 2000” is absolutely wrong.
Saying it is a custom version of Mac OS, I would call it absolutely wrong. Here, just wrong is enough :p
I'm pretty sure I've heard of companies using open source emulators for backwards compatibility with old consoles/selling 'classic games' before.
To my understanding the hardest problem in XBox emulation is the GPU, and unfortunately this doesn't help with that.
I know at least Sony uses PCSX ReArmed for their "PlayStation Classic".
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.)
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).
3) hired one of the iNES developers to develop their emulator, who kept using the file-format they were familiar with.
Not sure about the Xbox One - it might be just a different aspect on the hypervisor.
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.
almost makes you wonder if it's a honeypot...
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.
(of course there was that thing in '06... https://www.linux.com/news/reactos-suspends-development-sour...)
the dolphin emulator team (gamecube/wii emulator) made a statement on the nintendo leaks:
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.
This dump seems to be full code + full build environment, which seems pretty extraordinary.
I open up the start menu, type 'vlc', and get no matches. I close the menu, reopen it, and try again. This time, it finds VLC no problem.
They've had almost 5 years to fix this.
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?
It's also incredibly bloated. Gone are the days when a few gigabytes would be enough for your Windows partition.
The Microsoft Teams chat application uses 200MB to 550MB of RAM when idle.
My all-time favourite example of high-density software is Super Mario 64, which weighs in at 8MB.
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 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
Straight from Windows 3.x :-)
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.)
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.)