Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: XDK System Software Overview

  1. #1
    Join Date
    Jan 2002
    Posts
    67

    Arrow XDK System Software Overview

    Xbox System Software Overview - official leaked document from the XDK

    The system software of the Microsoft Xbox game system will provide a small, fast, safe, robust, and customizable environment to enable the creation of great games for the Xbox game system. It will provide a set of useful common services to be taken advantage of by game developers, such as networking and file system input/output, so that developers can focus on creating great games. It will also provide an attractive, easy-to-use interface for functions other than running games, such as playing DVD movies or CD music or configuring the Xbox console.

    The Xbox system software will have these components:

    The Xbox read-only memory (ROM)
    The Xbox Dashboard
    The Xbox Title Libraries

    The ROM of the motherboard on the Xbox console will provide the following system-software services:

    Hardware Abstraction Layer (HAL)
    Driver model
    Hard disk driver
    DVD driver
    FAT32 file system
    UDFS file system
    Copy-protection support
    Certificate/signature validation
    Basic application services such as the application loader, memory management, and threading.

    Software System Kernel
    The kernel is based on Microsoft Windows 2000. Many features of Windows 2000 are not included in the Xbox system software, including those related to running on multiple hardware platforms or running multiple processes at once. For more information about unsupported Microsoft Win32 application programming interfaces (APIs), see Win32 API (below).

    There will be no support for code running in user mode (Ring 3) on the Xbox game system. All code will execute in kernel mode (Ring 0). Only one process runs at a time, and that process will support multiple threads. There is no Windows 2000 desktop user interface; the user interface is provided by the individual Xbox games or the Xbox Dashboard if no game is running.

    Even the main unit's heater is cool.

    Power Up
    When the user turns on the console, the system software is decompressed out of read-only memory (ROM) into random access memory (RAM). Once in RAM, the system software initializes the hardware (DVD, audio, video, and so on).

    After the hardware has been initialized, the system software will display the boot graphic and play the startup sound. Because there are no video or audio drivers in the kernel, this is done by poking the registers of the sound and video card directly. This graphic and sound will play approximately 1 second from the time the machine is turned on.

    Media Detection
    Upon power up and during the display of the startup graphic and the playing of sound, the system software attempts to determine what type of media is in the DVD drive. If it determines that the media is a game, it loads the game into RAM, checks the signature of the game to verify that it is an authentic copy, then starts playing the game. If the media is not a game, the Xbox Dashboard is run as follows:

    Movies are played by the Xbox Dashboard video player.
    Audio CDs are played by the Xbox Dashboard audio player.
    If unsupported media is present, an invalid content message is shown and the Xbox Dashboard game-system-configuration user interface runs. If no media is present, the Xbox Dashboard game-system-configuration user interface runs.
    For more information, see Xbox Dashboard (below).

    Supported media are CD, DVD, CD-RW, or DVD-R. There is no CD-R support.

    Game Launch
    Once the system software has determined that the media contains an Xbox game, it loads the game developer bitmaps, publisher bitmaps, license bitmaps, and so on. These will be stored in a predetermined location on the DVD, will contain no executable code, and will be identified with a predefined schema.

  2. #2
    Join Date
    Jan 2002
    Posts
    67
    The system software will display these bitmaps sequentially, after the boot graphic and sound have appeared, while the game itself is being streamed from the DVD into RAM. As the game image is streamed into memory, the system software checks the signatures of each section of the image on the fly.

    Once the game image is in memory, the system software will start the game. At this point, the kernel is acting in conjunction with the Xbox Title Libraries to provide all of the basic services for the game itself.

    The Xbox game image format is not compatible with other executable systems, such as Windows 2000 executable format. The Xbox game image must be loaded by the Xbox system software application, loading utilities directly into RAM in 64-megabyte (MB) blocks. Unlike standard Windows 2000 applications, there are no dynamic-link library (DLL) loads, no fix-ups, and so on.

    Xbox Title Libraries
    The Xbox Title Libraries define the programming model used to develop software for the Xbox game system. They consist of all APIs provided with the Xbox Development Kit, which are linked into every title written for the Xbox game system, including:

    Subset of the Microsoft Win32 APIs
    Subset of the Microsoft DirectX 8.0 APIs
    Xbox video driver
    Xbox audio driver
    Xbox universal serial bus (USB) driver
    Xbox modem driver
    Xbox memory unit support
    Xbox network stack: media access control (MAC), Network Driver Interface Specification (NDIS), Transmission Control Protocol/Internet Protocol (TCP/IP), and Winsock.

    The primary programming model for the Xbox game system will be defined by the Xbox Title Libraries. Because the Xbox Title Libraries are partitioned into distinct libraries (modular), game developers can pick and choose which libraries are appropriate for their title. For example, if a game will support online play, they include the Xbox networking library with their game. If no online play support is planned, they do not include the Xbox networking library. While some support is implemented in the kernel of the system software in the Xbox game system ROM (for example, file system support, threading, memory management), the APIs to access these features are exposed through the Xbox Title Libraries.

    Note All Xbox-compatible code runs at Ring 0 on the Xbox game system, which means the Xbox Title Libraries are implemented in kernel mode and all games run in kernel mode. However, all Xbox Title Libraries will be signature-compatible with their user-mode implementation. From a developer's perspective, the Xbox Title Libraries function as they would in user mode. Kernel mode results in faster performance at run time.

    Win32 API
    A subset of the Win32 APIs is supported by the Xbox system software. We are currently doing analysis to determine exactly which APIs will be needed. Some omissions from the standard Win32 environment will include portions of the User, Graphics Device Interface (GDI), OLE, or the Services interfaces. Any APIs from User and GDI that are essential will be included as needed.

    Services from Windows 2000 not available in the Xbox system software include:

    Services
    Plug and play
    Additional hardware enumeration
    Hot docking
    All unsupported drivers
    Power management
    Virtual memory (paging)
    Multiple-process support
    Multiple-processor support
    Windows NT File System (NTFS)

    Graphics
    Microsoft Direct3D will be the primary graphics API for the Xbox game system. Direct3D for the Xbox game system will be based on DirectX 8.0, and implemented using a custom driver specific to the final NVIDIA chipset and video adapter. The graphics API for the Xbox game system is compatible with DirectX at the API layer, while providing the thinnest, fastest-possible access to the video hardware. The Direct3D driver is combined with the HAL to create a completely monolithic driver implementation.

    The drivers support both National Television System Committee (NTSC) and Phase Alternating Line (PAL) TV output. Moving Picture Experts Group (MPEG) video is supported.

  3. #3
    Join Date
    Jan 2002
    Posts
    67
    Input
    The Xbox controller connections and external peripheral connection are USB ports with an Xbox proprietary connector. The Xbox game system implements USB drivers for any possible peripherals connected to the Xbox console. Only full-speed USB is supported.

    An API specific to the Xbox game system, based on Microsoft DirectInput, is used for development with most Xbox controllers. Xbox-licensed game systems should work without an additional driver. This assumes that Xbox consoles do not introduce any new axis or capability not covered by the standard Xbox game system API.

    Audio
    The audio APIs for the Xbox game system are based on subsets of Microsoft DirectSound and Microsoft DirectMusic, from DirectX 8.0. Audio streaming will not be based on Microsoft DirectShow, however. Instead, an Xbox-specific audio streaming API will be implemented for high quality CD playback without skipping, and without undue CPU utilization. The following features are supported by the Xbox audio APIs:

    WAV files
    MIDI playback
    Interactive music
    Microsoft Windows Media (WMA) files
    3D sound

    There is no support for Redbook audio or random instruments.

    Video
    Like audio streaming, the video streaming API for the Xbox game system will not be based on DirectShow. Instead, an Xbox-specific video streaming API will be implemented.

    Networking
    Xbox hardware includes two devices for online connectivity:

    Built-in Ethernet card for broadband: cable modems, digital subscriber line (DSL) or local network
    Optional 56-kilobits per second (Kbps) modem peripheral for dial-up, with a USB modem driver and dialer included in the Xbox Title Libraries.
    The Xbox Title Libraries include networking services for online capabilities. Included with these will be TCP/IP and Winsock support. If online connectivity is not wanted for a game, the Xbox networking libraries should not be linked and included with the game title.

    The API to access networking services is based on a subset of Microsoft DirectPlay from DirectX 8.0. DirectPlay lobby or voice features will not be supported, however.

    New Xbox Services
    The Xbox system software will include new services specific to the Xbox game system and not based on any existing Win32 or DirectX APIs. New services provided by the Xbox Title Libraries include:

    High-score publishing, including a common format to be shared online. Virtual keyboard support for simplified text entry and game-specific skins. User identity that associates names, preferences, and statistics to be shared online. Hard disk management to allow usage of the Xbox hard disk by game titles for configuration stores, cache space, and so on.

    Xbox Dashboard
    The Xbox Dashboard is an application installed on the Xbox hard disk, which essentially is the user interface when a game is not running in the Xbox game system. The Xbox Dashboard provides the following services:

    DVD player
    CD player
    System configuration utilities for the Xbox game system
    Multiplayer and online connectivity utilities
    Saved game management
    Error handling

    Initially, the user interface of the Xbox Dashboard offers the following choices to the user:

    Play
    Configure
    Go online
    Manage games

    DVD Player
    This can be configured for AutoPlay (so that a DVD video will play simply by inserting into the Xbox console and powering up) or for manual control, which presents controls for pause, skip, and so on.

    CD Player
    This can be configured for AutoPlay (so that an audio CD will play simply by inserting into the Xbox console and powering up) or for manual control, which presents controls for pause, skip, play list management, and so on.

    Xbox Game System Configuration
    This presents the user interface for all preferences and settings for the Xbox game system, including the following:

    Video configuration
    Audio configuration
    Parental control
    Date and time

    Multiplayer and Online
    This presents the user interface for all online connectivity, including the following:

    Lobby browser
    Lobby favorites
    High score browser
    Xbox Zone browser
    Online sign-up and configuration

    Saved Game Management
    This presents the user interface for hard disk management, including saving, deleting, and copying games between the Xbox hard disk and the Xbox Zone (online).

    Error Handling
    Errors that occur during system-boot execution of the Xbox Dashboard will be handled by the Xbox Dashboard. However, hardware errors (for example, hard disk failure) will be handled by the Xbox system software. Game errors also are not handled by the Xbox Dashboard, but by the game software itself.

    This thread was taken from another fourm.
    http://www.xboxhackz.com/forums

    Netman

  4. #4
    Join Date
    Oct 2001
    Location
    Out West
    Posts
    3,171

    All ring zero!

    Amazes me MS would risk running all stuff in kernel mode. How long before we start seeing BSOD on X-box?

  5. #5
    Join Date
    Aug 2001
    Posts
    61
    Uh, consoles don't *need* an OS. A console does one thing (or is supposed to) - play a game. one application. The base kernel provided is simply there to provide some library functions (DirectX), and provide an easy way to do scheduling of threads.

    Thus, it's the code itself that has to be verified against crashing, since a console crashing is a Very Bad Thing. Heck, bugs in a game are a big deal. The Xbox can get away with it since it's possible to grab patches and place them on the hard drive, but really, console games must be provided bug-free.

    No uptime in consoles. Plus, most developers will develop their own inhouse libraries and work at the metal later on, so kernel mode is essential for them.

  6. #6
    Join Date
    Oct 2001
    Location
    Out West
    Posts
    3,171
    Originally posted by Worf
    Uh, consoles don't *need* an OS. A console does one thing (or is supposed to) - play a game. one application. The base kernel provided is simply there to provide some library functions (DirectX), and provide an easy way to do scheduling of threads.

    Thus, it's the code itself that has to be verified against crashing, since a console crashing is a Very Bad Thing. Heck, bugs in a game are a big deal. The Xbox can get away with it since it's possible to grab patches and place them on the hard drive, but really, console games must be provided bug-free.

    No uptime in consoles. Plus, most developers will develop their own inhouse libraries and work at the metal later on, so kernel mode is essential for them.
    I recognize the need for speed Worf, but MS has plans to turn this into more than just a game console, and when that happens, I don't see a stable platform on which to build it.

  7. #7
    Join Date
    Jan 2002
    Posts
    64
    Possibilities:
    1) MS won't build off the XBOX but build a new piece of hardware with a platform that supports the "plans."
    2) Microsoft Upgrades the OS on the XBOX to a version that supports the "plans."
    3) The "plans" don't actually require anything special.

    Keep in mind that the reason the kernel runs a lot of things in user mode is so that it can trap a program's bad behaviour and shut it down, isolating it from the rest of the apps on the system. When there's only one app running (the game) there's no point in safely terminating the program because the user experience is still the same. It doesn't matter if kernel memory gets trashed and the game dies in a horrible fury or a dialog box pops up and says "Love Riders II has performed an illegal operation and will be shut down." The user will still be pissed. However the first one can be misinterpretted as an error in the OS and not in the game (there was a screenshot floating around of a game crashing on the Dreamcast and people were saying "Look, Windows CE sucks!" the problem is that game didn't use CE, it supplied it's own interface to the hardware and didn't load CE).

    The platform is stable. A bug in the game would have the same effect whether the game was running in user mode, kernel mode, or with no OS -- catastrophic failure. The only thing you can argue is that a bug in the kernel affects all games whereas a bug in a game just affects the one game. But I think you'll find that the amount of code in the kernel is much less than the amount of code in a game. In addition the kernel code has been tweaked to work with the hardware and tested against the hardware far more than a game would have been -- therefore all games benefit from the same tight, well-tested hardware integration done by the kernel. Companies don't have to roll their own hardware integration and can concentrate on the game. Not that all companies rolled their own, there are libraries out there that handle the hardware integration and then you are right back to the same kind of thing as the XBOX kernel -- companies relying on other people's code to do the dirty work.

  8. #8
    Join Date
    Oct 2001
    Location
    Out West
    Posts
    3,171
    Originally posted by Ghost Coder
    The platform is stable. A bug in the game would have the same effect whether the game was running in user mode, kernel mode, or with no OS -- catastrophic failure. The only thing you can argue is that a bug in the kernel affects all games whereas a bug in a game just affects the one game. But I think you'll find that the amount of code in the kernel is much less than the amount of code in a game. In addition the kernel code has been tweaked to work with the hardware and tested against the hardware far more than a game would have been -- therefore all games benefit from the same tight, well-tested hardware integration done by the kernel. Companies don't have to roll their own hardware integration and can concentrate on the game. Not that all companies rolled their own, there are libraries out there that handle the hardware integration and then you are right back to the same kind of thing as the XBOX kernel -- companies relying on other people's code to do the dirty work.
    All good and valid points GC. However, I think a PDA should also never "crash", but I can crash the Pocket PC in 30 seconds.

    As long as it's a game console, running fast in kernel mode makes sense for all the reasons mentioned. But if they decide to turn X-box into some sort of multi-media center, I still think it's gonna get ugly. And with online gaming, how long will it take to create a virus that will kill a box running everything in ring 0?

  9. #9
    Join Date
    Jan 2002
    Posts
    64
    Originally posted by BubbleLamp


    All good and valid points GC. However, I think a PDA should also never "crash", but I can crash the Pocket PC in 30 seconds.
    With a PDA you're closer to the standard software model. Just about anyone can develop for the PDA. You've got a wide range of devices and drivers and software. You've got varying levels of quality. It's just like the PC market but smaller (in several senses of the world). Different PDA manufactureres can modify the version of Windows CE running on their machines. Different drivers have different quality levels and it becomes a mess. With the XBOX Microsoft has taken a very strict stance on software. For instance (AIUI), Microsoft is doing all the driver development. In addition there is only one hardware platform. Also Microsoft requires all software released on the XBOX to be tested heavily, both by the developer and by Microsoft itself. Since Microsoft holds all the keys (both the software keys required to sign the software and and let it run on the XBOX and the hardware required to master the CDs) they can control what gets on the box. No kid that's learning C++ and wants to write his first game. This, of course, doesn't mean that the games will be bug free but it does guarantee that the quality of software will be far above what exists in the standard software market (this, by the way, is common on many platforms).

    In addition, Windows CE is a mini-Windows supporting a good portion of the Win32 API as well as doing things like supporting multiple processes and all sorts of other things that increase the code size and complexity allowing for many more bugs.


    As long as it's a game console, running fast in kernel mode makes sense for all the reasons mentioned. But if they decide to turn X-box into some sort of multi-media center, I still think it's gonna get ugly. And with online gaming, how long will it take to create a virus that will kill a box running everything in ring 0?
    A true virus? I doubt it will exist. However there may be buffer-overflow exploits, as there often is. But, again, if there's a bug in the game, then it's the game's fault, regardless of what's between the game and the hardware.

    Only one process runs at a time, and that process will support multiple threads.
    There will only be one process at a time. There isn't going to be multiple programs to care about. If one process goes down they all go down -- because there's only one. If Microsoft later decides that it wants to run multiple processes they will have to change the kernel to support them and if they do then there's nothing stopping them from moving process code back into User Mode (ring 3).

    I'm not saying that the XBOX is bug-free. I personally haven't encountered any bugs but that doesn't mean there aren't any lurking. And I don't know what plans Microsoft has for the XBOX specifically (versus building a nextGen XBOX that's a living room multi-media center) so I can't speak totally as to whether the XBOX can indeed handle it or if Microsoft is being too ambitious. I will say this, though: When Microsoft first tried to sell the XBOX they tried to sell it as a living room multi-media center, the game companies didn't like that idea too much, they wanted a game console. Microsoft then delivered them a Game console. Now they are announcing plans for a living multi-media center. I don't know for sure, but I'm guessing Microsoft knew what they were doing all along. Based on how well they've executed with the XBOX this far I'm sure they'll do just fine with their future plans.

  10. #10
    Join Date
    Oct 2001
    Location
    Out West
    Posts
    3,171
    Originally posted by Ghost Coder
    With a PDA you're closer to the standard software model. Just about anyone can develop for the PDA. You've got a wide range of devices and drivers and software. You've got varying levels of quality. It's just like the PC market but smaller (in several senses of the world). Different PDA manufactureres can modify the version of Windows CE running on their machines.
    Is it acceptable to crash even if it's 100% MS code? I don't think it is. They just did a dumb design with memory handling. That's why MS-powered devices scare me so much, whether it's a PDA or a smart refridgerator.

    Time will tell on the X-box. I'm not a gamer, so I'll be watching from the sidelines.

  11. #11
    Join Date
    Aug 2001
    Posts
    61
    Originally posted by BubbleLamp
    Is it acceptable to crash even if it's 100% MS code? I don't think it is. They just did a dumb design with memory handling. That's why MS-powered devices scare me so much, whether it's a PDA or a smart refridgerator.

    Time will tell on the X-box. I'm not a gamer, so I'll be watching from the sidelines.
    It's never acceptable to crash. Regardless of OS (Windows, MacOS, MacOS X, Unix (all flavors), Unix-Workalikes (Linux, Hurd, etc), PalmOS, etc).

    However, sometimes hardware limitations make it possible to crash (e.g. PalmOS - it's nearly impossible to recover from since there's no MMU to enforce protections). Hence, the only protections possible are extreme paranoia when coding the OS.

    But yes, Microsoft stuff has historically been less stable on the same hardware. Perhaps it's incompetent use of the MMU. Or it could be that Microsoft makes everything 100 times more complicated than it has to be! (Really, some things Microsoft does really hinders bug-free codewriting).

  12. #12
    Join Date
    Jan 2002
    Posts
    64
    I have to agree there. I'm more Microsoft positive than the average person, but I still can't deny that MS does stupid things:

    From http://msdn.microsoft.com/library/de...s/TOOLINFO.asp
    lpszText
    Pointer to the buffer that contains the text for the tool, or identifier of the string resource that contains the text. This member is sometimes used to return values. If you need to examine the returned value, lpszText must point to a valid buffer of sufficient size.
    And then from http://msdn.microsoft.com/library/de...TM_GETTEXT.asp
    Set the lpszText member to point to a buffer that receives the text. There currently is no way to specify the size of the buffer or to determine the required buffer size.
    That's great.

    Microsoft is aggressive (and I'm not talking about business practices). They often bite off more than they can chew in software development. It's why they are number one today, but it's also why some products have poor quality. If you look at how far Windows NT has come and then compare it (Windows 200/XP) against how far Unix has come in twice the timeframe you'll see it's pretty amazing.

    Microsoft does have a quality issue with some products ({cough} the entire Win9x line*). I just don't think the XBOX is one of them. Microsoft ends up being like little companies inside -- the different product teams can differ quite a lot. I think the XBOX was given the opportunity to do things right and proper. They were able to do things like lock down the specifications and not give in to feature creep as technology improved or got cheaper (this was also driven by the fact that third part software developers needed a stable platform to develop for). Even though they were in fierce competition with Nintendo and Sony they didn't seem rushed and, in fact, slipped to ensure quality (or perhaps it was just manufacturing problems). They probably could have rushed and got out a release with all the broadband code and everything that will be coming out in a few months but instead released with what they did and probably made sure it was stable (and it's still very good).

    * Microsoft should have dumped Win9x the second Windows 2000 came out but they couldn't. Unfortunately they were imprisoned by backwards compatibility. All those people that wanted to run the applications they'd been using since 1986. Weird DOS apps that did strange things. Crazy Win16 programs that used undocumented calls to get weird functionality. Win2000 wasn't compatible enough so they had to keep building Win9x products. You'll find instances of this in lots of software products all over software development land -- often times what consumers want is contrary to good software. Microsoft had/has a hard time saying no.

    But anyway, enough about this.

  13. #13
    Join Date
    Jan 2002
    Posts
    67
    GhostCoder

    You Got PM.


    Netman

  14. #14
    Join Date
    Aug 2001
    Posts
    61
    Heh. I've sorta realized why Microsoft uses hungarian notation everywhere. Microsoft *LOVES* big functions. They sort of architecture everything to fit that goal (WinProcs... oi!). Of course, big functions mean it's a long way from the declaration to the usage...

    (of course, you should've seen a WinSock program I had - written with full hungarian to the point of unreadability. I know socket code, and basically the socket calls were the only thing readable).

    Although, the xbox does have one limitation - it's bound by the same potentially buggy APIs... unless in a year or two, Microsoft will allow people to bang on the metal directly.

  15. #15
    Join Date
    Jun 2001
    Location
    Dallas
    Posts
    588
    So, anyone have the XDK yet?
    Information wants to be free....

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •