[XNA] Positives About Custom .NET Version

Now I want to go over some potential positives of having a custom version of the .NET Framework available on the Xbox 360.

1. TCR compliance at the execution level.

I don't know how many of you have ever worked on a console title, but it can be a real pain in the ass. You have to make sure that you don't write to forbidden areas of memory, you have to use the proper library versions, you have to use the correct compiler, you have to make sure you don't ship with anything looking for certain forbidden paths that are actually okay to use during development and debugging...lots of major pains in the ass.

Using the .NET Framework, as long as you try to avoid allowing unsafe calls, you can actually enforce most code-side TCR requirements at the framework level. Code trying to open forbidden path Q? Throw an exception. Code trying to jump to forbidden address X? Throw an exception. The ability to stop code at the execution level is critical if they want to maintain security of the console.

2. Get people into the proper frame of mind for developing in a Least-User Access model.

Now initially, it sounds like XNA apps are going to require the hard disk. If so, one can make the assumption that there are going to be four folders exposed to an XNA app: their installation folder, the title folder, the user folder and the scratch folder.

The installation folder will most likely be read-only, and will consist of the files necessary to run the game. Writes to this folder by the XNA app will most likely be verboten. The title folder is meant for shared access between all users on the console. Things like shared high score lists and shared content updates would go here. The user folder is meant for user settings and saved games. The scratch folder is meant for temp files.

This mirrors the way that games should be written for Windows Vista and even XP. Files installed to Program Files are supposed to be read-only for security reasons. Shared content between users should be dropped into a subfolder of the CSIDL_COMMON_APPDATA or CSIDL_COMMON_DOCUMENTS folder. Files unique to a user should go into a subfolder of either CSIDL_LOCAL_APPDATA or CSIDL_PERSONAL. And scratch data should ideally be in a folder created using the GetTempPath() Win32 API call, or using the System.IO.Path.GetTempFileName() .NET function, along with setting the file attribute to include FileAttributes.Temporary to improve performance. (It's actually kind of nifty...look it up.)

3. Customized performance for the hardware.

This is the big one. Right now, garbage collection responsibility is only split between cores on a multicore box if the server GC is installed. With a custom framework version, not only can they eliminate the need to redist the workstation GC, but they can also hardcode in the number of cores, assigned memory regions, etc. to speed performance.

Instead of having to worry about the proper processor optimizations for the JIT, they can focus on a single platform with a static memory configuration.

For the XNA Creator's Club subscribers, a GAC makes lots of sense (try to save HD space), but it can lead to potential security holes in XNA apps they want to ship to the world, so they can nuke the concept of a GAC and just require that all signed XNA apps either ship with the proper framework and library versions or just merge them all together using ILMerge.

Now again, there's a lot of supposition going here, but I'm trying to give Microsoft the benefit of the doubt. No doubt they've thought of a lot of this already.

(Update: 8/21, 8:53a: Fixed a couple of typos.)