XSelect 0.9 Big thanks to the earlier developers of this program for releasing source!!!!! The old version almost fit my needs perfectly. (The main issue I had was reliance on configuration files that weren't copiable to unmodded systems from within the official MS Dashboard. This is now remedied.) What is this? A program that can run other Xbox executables. It seems this was originally created to be the fastest interface to launch several different (dashboard) programs, and remember a default. What is so good about this program? It is less than 35% of the size of the Evolution-X RemoteX dashboard, and less than 20% of the filesize of Evo-X RemoteX if XBEPack is used. Other dashboards are even larger: This is 12%-ish of UnleashX's size. This can be non-interactive and ignored except for when it is useful. An Xbox controller can be used to find any file to execute, even one buried deeply in nested sub-directories, without any pre-made config files. (Advantages over Evo-X RemoteX, not the single-file UnleashX.) These, and its speed of use, are the strong points. XSelect also has a password feature (which may be unique, if not very useful). Example uses of this are included below. What is the biggest downside of this program, compared to similar programs? No included FTP server (one reason this is < 35% of Evo-X's size). No other super-fancy features: It's nice to have other dashboards too. How to handle problems: Error 21: This has to do with signature checking. Try loading another BIOS using a mod chip's feature or using a correctly-signed Phoenix BIOX Loader w/ XBEDump. Research the issue elsewhere. Another error: Research the issue elsewhere. Learn how to make your own Xbox executables, and modify the source code to this program. New features: Lots! More than a dozen substantial new changes. Easy to use on any Xbox without earlier needing to put text file on it * Configuration files are not needed to execute any file on your hard drive. Earlier versions could be configured within XSelect only to run *.XBE's in root directories * Config files (now unnecessary, but nice for convenience) are now copiable from within Microsoft's dashboard. Any known configuration files in the old E:\UDATA\01010001 location get copied to the 0123456789ABC subdirectory. Icons and titles are made as needed so saves are valid Important Improvements * G: (LBA48) support (I think. Since the only hard drive in my Xbox is the one Microsoft put there, F: and G: support hasn't been tested by me. Basically, I expanded on logic used by F:, so the code recognizes G: as a valid possible drive letter, and assumed the custom KERNEL and/or BIOS takes care of any very fancy LBA48 code.) Other Improvements/Fixes: * The Applications Menu can be configured within the program. * Configuration files may be loaded from where XSelect is. Now multiple copies of XSelect can use multiple configs. * Smaller, 256K executable.(bcl.sf.net's Data compression used.) * For speed, removed unnecessary call to Sleep(2000) command. This speed up is more than 250 times as good as what the 7ms internal data decompression is bad for speed. (The developer of 0.9 had no troubles pressing buttons during allotted time with this intentional pause gone) * Improved reliability (I hope :) ), works on formtted drive as E:\UDATA is not assumed to pre-exist. (UNTESTED, maybe old code somehow worked fine in these conditions.) * QuickPick Applications now runs program from the list of Apps, not the Dashboards list. This may solve problems from when LoadAppSlots was called instead of LoadDashSlots. * Displays directions when assigning programs (yay!) and on init * Setup of programs now recognizes more programs. Recognition support for Phoenix BIOS Loader and UnleashX added. Also, any programs without support built into XSelect, but with an embedded XBE title, will now show that. * GUI now chops super-long filenames (uses ellipsis ("...")) if it would otherwise cause menu unreadability. (This is mainly evident when using multi-level subdirectories, but E:\WWWWWWWWWWWWWWWWWWWWWWWWWWW.XBE made trouble.) * QuickPick Dash and QuickPick App are now on main configuration menu, so program can be easily run after it is set up. * Screen dimmer became saver: It can dim repeatedly and totally blanks if dims enough times. Menus now also dim. * Many new config files supported for use with new abilities. * Can use file maintanance scripts (text list of files stored in supported filenames). 'twas easier to code than to use Cosmetic/Informational (Developer preference, not so much a feature): * When showing message and needing input, program suggests input * Program saving will pause on message letting you know it saved * Reboot option now renamed to Error 21, since that's what it really does on a retail BIOS. (This does reboot with some alternate BIOSes, just like any other Error 21.) Evolution-X RemoteX's In Game Reset (IGR) acts on E21. * The program now calls itself XSelect *everywhere*. References to X-Select(or) refer to old versions. Inconsistencies were in 0.6. 0.9's name follows file system's limits. Documentation Improvements: * Documented interaction w/ other controllers (Gamepad 2, KeyB) * Some documentation was only included in the source archive of X-Select 0.6, but the important information is now included in the main archive. * Documentation formatted to 78 columns * Documented information on modifying the *.XBE file. This ver passes all of XBEDump's tests (no false negatives). It seems that's just since VS6/an older XDK was used. * Documentation is provided to help other developers make a working XBE file from the source. (Relies on MS XDK.) The Visual Studio .NET (7.0) project files are not included like they were in 0.6. These files didn't work in VS6, nor VS .NET 2003 (7.1) which converted badly (into a Windows, not an Xbox, project). Instead, documentation is provided to help with any XDK/VS ver. Other Changes: * Internationalization may be in a less ideal state than earlier versions. The developer of this version is less well versed with some modern Int'l-aware methods of coding. For instance, references to _T() may have been removed, LPCTSTRs were made or converted to on an as-needed basis w/o knowing reasons behind the choice of that filetype. (Ah, the good ol' days of char *) * Many code changes. Now uses STL (part of recent Visual Studio releases) and BCL (external library). Due to support for G: (LBA48 drives) and data compression, several files have been updated. MessageBox() has been renamed (so it can be searched for separate from RenderM'Box). New functions added, some old functions have merged. Functions may not be listed at top of files. (Seemed better to release program early than worry about that) History/Future: 0.9: This version was created by a new developer, different from X-Select 0.6 (who were new developers who gave the application a new name, different from older developer(s) who made X-Selector 0.5). The developer who made 0.9 will probably not make any further changes to this program, and does not suggest that this person is now in charge of this program's development. The reason for the 0.9 (rather than 0.61 or 0.7) version change is because there has been substantial updating, and the program is now very near the quality one would expect for a 1.0 product. There are no known problems, and almost every good thing that was thought of but planned to NOT make it into this version, did make it into this release. The main reasons I'm not calling this 1.0 are because some things are just untested (like the whole program, but especially if LBA48 G: works), and I didn't want to take the honor away from the program's original creators before trying to find out if they yet have some plans of their own for a 1.0 release. Earlier versions were numbered appropriately. Version 0.6 was in many ways half done, such as not yet having support to set up the Applications slots in-program. It is good not to have a ton of updates and massive new features and not always be under 1.0. The developer of version 0.9 may release a new, slightly improved version and call it 1.0. Just don't count on it. Older history: 0.6: * Name Change ("the new authors will be taking over, wanted to change the name"). Once "X-Selector", this is now named "X-Select". * Time Check performed on bootup to avoid hassles if the Xbox's clock resets (happens after a long period with power disconnected). * Boot to DVD option added. * Signed w/ Font Exploit's signature. 0.5: First release Why use this program? 1. It seems this was originally created to be the fastest interface to launch several different programs. It's even less input needed than Evolution-X RemoteX, where you just scroll to an option and push 1 button. 2. This program does its default thing without manual intervention, so it can be placed early in a chain of execution and then pretty much forgotten about (much like Phoenix BIOS Loader, which executes a BIOS, which then runs a dashboard). However, manual intervention is possible for dealing with unexpected problems. XSelect is easily signable with XBEDump so you can run this program before Phoenix BIOS Loader and the alternative dashboard of choice (likely with the built-in FTP server). This way if more complex apps have problems (incompatbility on another Xbox, or buggy new version), older versions can be found (manually if needed) and run. Restoring an old boot sequence (if testing a new hack that doesn't work) may be eaier when old FTP server/PBL are in tact. 3. On my system, I'd rather run UnleashX with a built in file manager, but there are times when a person cannot easily choose the location(s) where the executed code may reside, such as the original unsigned code that is executed from a saved game location, a dashboard hack, or an alternate BIOS. Having lots of copies of XSelect uses less disk space than lots of copies of a larger program, which is especially important if distributing a package on a memory unit (a "memory card"), and useful to keep distribution file sizes low. 4. Password protection can be used if you put this program by all possible entry points. (However, some entry points may not be so easy to block. If you run the Microsoft dashboard, a saved game exploit can be copied over this program, and any Boot To DVD Drive option could allow for code to come from a disc, and any mod chip's FTP server may be able to overwrite this file.) Who made what? Basically, much of the code is Microsoft's (Direct3D). Much of the underlying code for handling graphics and launching a program and some basic menu support was handled by the developers of versions 0.5/0.6. Much of the rest of the functionality, such as hard drive searching code, doubling the amount of menus and configuration files, interal data compression, and so on, was handled by the developer of 0.9. Although a lot of the code is by the developer of version 0.9, ver 0.9 wouldn't have existed if it wasn't for the excellent idea to release source. Many thanks to the developers of versions 0.5 / 0.6 for this! Logical things (possibly easy things) that could be implemented next: (Not that the most recent developer is promising to do any of these.) Determine why program does not find files in the current directory during Evolution-X RemoteX's ID_No_D_Mount. Test the use of hard drive partitions beyond E: (F:, G:, etc.) (Note: XDK documentation says F:-M: should be the mem units (cards), so partitions after E: should be N:-W:) Use XDK Save Game XFindFirstSaveGame(), XCreateSaveGame(), and similar functions, rather than a made up directory. Note: That may make config file locations variable. The reason this wasn't pursued earlier: It seems that these functions would save data to a random-ish place under E:\UDATA\01010001\. Then code would have to be added to locate what directory was used (which isn't necessarily a bad thing), but worse yet, a user would not be able to easiliy know what directory under E:\UDATA\01010001, if there are 2 valid possibilities or more, gets used. = harder manual text file editing. XBE would be a few K larger without compressed icons. Achieving and keeping XSelect under 256K was hard. Would uncompressed icons show up in Avalaunch, though? On start, display files in the QuickDash menu, along with what buttons will run them, and then look for controller input. This way people can earlier see what is set up. Allow user to have more options on where to find files. (Current order: directory where XSelect resides, then E:\UDATA\01010001\0123456789ABC. Allow user to choose any other directory, or load a directories text file. Allow multiple menus (somewhat supported now, having both the Dashboards menu and the Applications menu, but allow for easier creation of them so a programmer, or even a user, can easily add more). Some progress on this was made in 0.9 (the menus share more code rather than having it duplicated). Loading any file as a possible menu (the last option listed) would be the easiest quick way to add this. Super-basic support for this is added in 0.9 since XSelect can now use different configuration files (based on different directories). Multiple button input (like a password entry) as a possibility to allow for more programs (possibly kinda synonymous with the idea of multiple menus stated above). Better handling of using ellipsis. Allow for scrolling, or at least some user configuration so that any part of any filename/description can be seen if the user selects the right width options. Make it so that the more of the description (up to all of it) can be seen if this can be done at no cost to how much filename is shown. Support reading other fonts, either from the actual dashboard or perhaps with XPR files that UnleashX puts under E:\UDATA\93115330\. XboxDings.xpr has nice sprites of buttons which would make for prettier in-program help. More rigorous error checking. (A perfect program would check the memory stack to ensure there is enough memory for each function call, something C/C++ (and so the XDK) wasn't designed to easily allow for. So: Infeasible.) Add FTP server? (XBFileZilla?) This would eliminate the need for 700K Evolution-X RemoteX for tight distributions. (Or maybe, to minimize file size, this should NOT be done, and FTP servers should be separate.) Other things that older developers suggested would be in future versions: "Understanding more dashboard types" (This probably referred to just recognizing more dash- boards by program ID, and naming them using the 3 or 4 letter name codes. This has been done a bit, but of course any new dashboard can cause more work on this.) "Add ability to tell versions of recognized dashboards." (This probably referred to version numbers. That might need to be unique for each dash. So, also neverending) "Include ability to configure Applications Slots"(Done in 0.9) "Modify launch procedure to have dashboards launch as TRUE dashboards (undocumented calls)" (What's this?) Small 3-D "bug" instead of boring text when X-Selector is waiting for user decision on startup. (Note: This would have a bad side to it, by making the file larger, and the program's small file size is 1 of its greatest characteristics. However,it seems there's already graphical support using DirectX (to display a message box, and measure the pixel width of a string when rendered in a font), so the file size increase may be negligible.) Suggestion: Don't try to hold your breath until these things are further implemented by earlier developers. Prior to this writing, it had been eight and a half months since the release before 0.9. Notes on modifying the XBE file: * XBEDumper 0.5-BETA tests the file for validity, and reports errors. Don't believe XBEDump. The XBE header really "is a valid header for the Xbox kernel) (see http://cvs.xbox-linux.org/viewcvs.py/xbox-linux/ cromwell/boot_xbe/xbeboot.S?rev=1.10 ), even if it isn't decodable by other apps such as XBEDump. In fact, I have (thanks to Visual Studio making *.EXE files that CXBE can convert) made a *.XBE file that passes XBEDump's integrity check, but then XBEPack crashes on it. Just ignore XBEDump's validity checks. * XBEPack can shrink the file to less than half of its regular size. Great! The one downside: The program can't be successfully executed from some (many) environments, including: Evolution-X RemoteX's launch menu (using the game pad), UnleashX, 007: Agent Under Fire exploit save game, hard drive audio copying dashboard exploit, and more. Oddly enough, it does work from Evolution-X RemoteX when using the raw "execute" literal QUOTe. Y? Running XSelect from another environment that doesn't work causes a freeze until restart of Xbox. Note: XBEPack 0.2 comes for WinNT (I guess) and Linux executable. It worked in WinXP but not Win98SE. * XBEDumpable, so you can make it signed for font or audio hacks * By default, signed with XBEDump -habibi (audio hack). (Last version was signed for font hack by default.) Controllers: XSelect 0.9 has been tested using multiple controllers. Any standard Xbox controller in any of the controller ports will act just like one plugged into the first port. The controllers do not need to be plugged into the port when the program starts (but if there is not a controller in any port than expect the default dash to be loaded). You can even press and hold the Left Trigger on 1 controller and the Right Trigger on another to get to the configuration menu. Keyboards aren't recognized. Directions (mostly copied from old version): - 8 Dashboard selections, assignable to a button on the game controller. - Because of issues with the input routines, you must press the gamepad button when the brief message pops up on the screen. (Sorry, tried to do it differently, but the gamepad refused to see buttons pressed before the app is running) - Right-Trigger, by itself, brings up the Dash Quick-Pick menu, allowing you to quickly select the 'default' dashboard. - Left-Trigger, by itself, brings up the application Quick-Pick menu, for fast selection of your top games or apps. - Left-Trigger and Right-Trigger at same time bring up configuration menu. - Without input, Boots the last dashboard selected with Right-Trigger+