Designed for Windows Logo Program
"Designed for Windows" Logo Program
The logo program is an optional certification that allows you to affix the "Designed for Windows" logo on your box. This is much more important for kid's titles or other mass market games than hard core titles. The reason being that if my Mom were shopping for games and she had two essentially identical candidates in front of her, she'd probably choose the game that was designed for Windows.
There is an extensive feature checklist that your game must pass to be eligible for the logo program. While most of the list is a no-brainer, there are a few line items that will make you go "You're kidding, right?" The entire testing document with details of all the test cases is up on MSDN (www.microsoft.com/winlogo/). It's a whopping 105 pages long. I briefly thought about including it in this book in the hopes my editor wouldn't notice the extra pages, but in the end a summary of the checklist and a discussion of the tricky items seemed more appropriate.
The numbers designation "T#.#" is Microsoft's code for tests related to a general test requirement, and "TC#.#.#" denotes a specific test case.
There are tests for general compliancy as well as tests specific to games. We'll cover the tests for all Windows applications first:
| T1.1 | Perform primary functionality and maintain stability |
| TC1.1.1 | Does the application perform its primary functions and maintain stability during functionality testing? |
| |
| TC1.1.2 | Does the application remain stable when a mouse with more than three buttons was used? |
| |
| TC1.1.3 | Does the application use the user's temporary folder for temporary files? |
| TC1.1.3.1 | Does the application store its temporary files only in the user's temporary folder during installation? |
| |
| TC1.1.3.2 | Does the application store its temporary files only in the user's temporary folder during functionality testing? |
| |
| TC1.1.4 | Does the application not crash or lose data when presented with long path, file and printer names? |
| TC1.1.4.1 | Does the application maintain stability when a file is saved by drilling down through the "User1 LFNPath1" path in User1's "My Documents" folder? |
| |
| TC1.1.4.2 | Does the application maintain stability when a file is saved by entering the full "User1 LFNPath2" path? |
| |
| TC1.1.4.3 | Does the application maintain stability when a file is saved using a long file name? |
| |
| TC1.1.4.4 | Does the application maintain stability when a file is opened by drilling down through the "User1 LFNPath1" path in User1's "My Documents" folder? |
| |
| TC1.1.4.5 | Does the application maintain stability when a file is opened by entering the full "User1 LFNPath2" path? |
| |
| TC1.1.4.6 | Does the application maintain stability when a file is opened using a long file name? |
| |
| TC1.1.4.7 | Does the application maintain stability when printing to a printer with a long name? |
| |
| TC1.1.5 | Does the application perform primary functionality and maintain stability on a dual-processor computer? |
| TC1.1.6 | Does the application not crash when devices it uses are not installed? |
| TC1.1.6.1 | Does the application maintain stability when printing if no printer is installed? |
| |
| TC1.1.6.2 | Does the application maintain stability when attempting to use devices that are not installed? |
| |
| TC1.1.7 | Does the application switch the system's display mode back to the previous color mode, if application automatically changes to 256-color mode when it runs? |
| |
One of the first tests to raise your eyebrows is TC1.1.3, where your game should locate temporary files. This is where your registry key, discussed a few pages back, comes in handy. Use the Win32 GetTempPath() API to get the root of the temporary directory, and add your registry key to create a unique space within the temporary directory to create your files.
Since your registry key is probably a few slashes deep, you'll need a function to parse through the path name and make sure the directory tree exists. Here's a function that starts at the temporary directory and creates the directory tree:
void MakeTempDirectory(CString &tempDirectory) { TCHAR buffer[MAX_PATH]; GetTempPath(MAX_PATH, buffer); CString tempDirectory = buffer; tempDirectory += "\\"; tempDirectory += GAME_APP_DIRECTORY; if (0xffffffff == GetFileAttributes(tempDirectory)) { // Ok - we have to go make a new directory to store temporary data. CString current = buffer; CString myAppData = GAME_APP_DIRECTORY; CString token; do { int left = myAppData.Find('\\'); if (left==-1) { token = myAppData; myAppData = _T(""); } else { assert(myAppData.GetLength()>=left); token = myAppData.Left(left); myAppData = myAppData.Right(myAppData.GetLength()-(left+1)); } if (token.GetLength()) { current += "\\"; current += token; if (false == CreateDirectory(current, NULL)) { int error = GetLastError(); if (error != ERROR_ALREADY_EXISTS) { return false; } } } } while (myAppData.GetLength()); } tempDirectory += _T("\\"); } The next set of tests, TC1.1.4 concern long file and printer names. Don't let this test fool you into thinking that you can get rid of 8.3 filenames in your application. It turns out that there are some older CD-ROM drivers that still cannot handle long files names on the CD. This is likely going to go away in 2003 or 2004 completely, and is probably already such a small percentage you don't have to be overly concerned. Still, it's a good thing to know.
| Best Practice | If you're curious about long file name compatibility and you don't have a huge budget for doing hardware surveys, take a look at CD's coming out of Microsoft. When they start using long filenames on their CDs and DVDs it's probably safe for you to do so. |
Test TC1.1.5 is a serious concern for games, since games are usually multithreaded applications. If you ever thought that debugging multithreaded apps on a single processor computer was tough, try it on a multi-processor box. Check the Debugging chapter for more tips on finding nasty bugs like that.
Test TC1.1.6 is also a concern for games. Your game must fail elegantly if it doesn't find the joystick, mouse, or sound card that it needs. Users can easily disable hardware with the device settings dialog box, which is effectively the same thing as physically removing the hardware.
TC1.1.7 is handled by DirectX if you use it. If you use another graphics API you should always restore the player's display to the setting your game detected when it started.
| T1.2 | Any kernel-mode drivers that the application installs must pass verification testing on Windows†XP |
| TC1.2.1 | Do all related kernel-mode drivers pass testing as Windows†XP loaded them? |
| |
| TC1.2.2 | Do all related kernel-mode drivers pass functionality testing with standard kernel testing enabled? |
| |
| TC1.2.3 | Do all related kernel-mode drivers pass low-resources simulation testing? |
| |
| T1.3 | Any device or filter drivers included with the application must pass Windows HCT testing |
| TC1.3.1 | Are proofs of WHQL testing attached to the submission for all required drivers? |
| |
| TC1.3.2 | Do no warnings appear about unsigned drivers during testing? |
| |
I don't know about you, but I've never written a kernel-mode driver or device driver and don't intend to. Most, if not all, games fall in this category so we don't have to worry about T1.2 and T1.3.
| T1.4 | Perform Windows version checking correctly |
| TC1.4.1 | Does the application install correctly under current and future versions of Windows? |
| |
| TC1.4.2 | Does the application perform all functionality tests correctly under current and future versions of Windows? |
| |
Test T1.4 is absolutely hilarious. How in the name of Albert Einstein can I know if my game will properly install and function under all future versions of Windows? Actually, this is probably concerning any Windows operating system currently in beta test, and has little or nothing to do with Windows 3000.
| T1.5 | Support Fast User Switching |
| TC1.5.1 | Does the application properly support Fast User Switching? |
| |
| TC1.5.2 | Does the application properly support Remote Desktop? |
| |
| TC1.5.3 | If the application installs a replacement GINA, does the GINA propely support Remote Desktop? |
| |
Fast user task switching is a serious concern for games. There are two things your game should be able to do to support fast user task switching: run minimized and run multiple copies of itself. The last one might seem weird, since most games detect their own window and simply bring themselves to the front. I'm talking about opening game files in a read-only sharable mode so that two users on the same box can open your game without a weird file sharing failure.
If your game stores user save game files in the users Application Data directory, required by test T3.1, you should be fine.
| T1.6 | Support new visual styles |
| TC1.6 | Does the application pass all functionality tests with a Windows†XP theme applied? |
| |
This is one place games get special dispensation from adhering with logo compliance: Games write their own interface that has nothing to do with Windows styles or themes. You can ignore this rule to the extent that you don't provide Windows-looking components that are deceiving, such as an "X" button in the upper right hand corner of your game that brings up a help window instead of closing your game.
| T1.7 | Support switching between tasks |
| TC1.7.1 | Does the application display normally and not lose data when focus is switched among other applications with Alt+Tab? |
| |
| TC1.7.2 | Does the application display normally and not lose data when Windows logo key and the taskbar are used to switch among applications? |
| |
| TC1.7.3 | Does the Windows Security dialog box or the Task Manager display normally and can the application be cancelled or closed without losing data? |
| |
This is where most games fall flat on their face, if they run in full-screen and windowed modes. It's critical to handle WM_ACTIVATE and check your DirectX surfaces for loss. If you do that correctly, your game will pass these tests.
| T2.1 | Do not attempt to replace files protected by Windows File Protection |
| TC2.1 | Does the installation finish without any Windows File Protection messages appearing? |
| |
This install requirement is pretty easy to pass, just make sure that any special game DLLs don't collide with other DLLs in the Windows System32 directory.
| T2.2 | Migrate from earlier versions of Windows |
| TC2.2.1 | Does the application successfully migrate from Windows†98 to Windows†XP Home Edition? |
| |
| TC2.2.2 | Does the application successfully migrate from Windows†Me to Windows†XP Home Edition? |
| |
| TC2.2.3 | Does the application successfully migrate from Windows†98 to Windows†XP Professional? |
| |
| TC2.2.4 | Does the application successfully migrate from Windows†Me to Windows†XP Professional? |
| |
| TC2.2.5 | Does the application successfully migrate from Windows†NT†4.0 Workstation to Windows†XP Professional? |
| |
| TC2.2.6 | Does the application successfully migrate from Windows†2000 Professional to Windows†XP Professional? |
| |
I don't know of any games that support migration. In fact there are plenty of legacy games that failed after Windows XP was installed due to the security measures on the Program Files directory.
| T2.3 | Do not overwrite non-proprietary files with older versions |
| TC2.3.1 | Does the application not overwrite non-proprietary files with older versions? |
| |
| TC2.3.2 | Do all application executable files have file version, product name and company name information? |
| |
The take-away from this test is make sure all your game files have embedded version information. This is trivial for game EXEs and DLLs—just insert a version resource, and make sure your install program respects the old version by installing the new one in a parallel directory. It shouldn't just whack the old files. This is also handled if you use the registry key to locate your game in the Program Files directory. The two versions can safely coexist because they'll be installed in two different directories.
| T2.4 | Do not require a reboot inappropriately |
| TC2.4.1 | Does the installation finish without requiring a reboot? |
| |
| TC2.4.2 | Can all Test Framework testing be completed without application requiring a reboot? |
| |
I know install programs love rebooting the machine, especially older install programs. If you use the most recent version of your installer, you should be fine.
| T2.5 | Install to Program Files by default |
| TC2.5 | Does the application offer a default installation folder under "E:\ProgramFiles?" |
| |
Duh. That's pretty easy.
| T2.6 | Install any shared files that are not side-by-side to the correct locations |
| TC2.6 | Does the application install shared files only to correct locations? |
| |
That test seems a little cryptic. Here are more details from the logo compliancy document, describing the location of shared files:
|
The docs make it clear that shared files are files common to more than one application your company makes. This would be true for a common game engine DLL.
| T2.7 | Support Add or Remove Programs properly |
| TC2.7.1 | Does installation add an uninstall to the Add or Remove Programs utility? |
| |
| TC2.7.2 | Does uninstalling application as Owner remove and leave all the correct files and registry settings? |
| |
| TC2.7.3 | Does uninstalling application as User1 either degrade gracefully or both remove and leave all the correct files and registry settings? |
| |
| TC2.7.4 | Can the application be reinstalled after uninstalling it? |
| |
| T2.8 | Support "All Users" installations |
| TC2.8.1 | Does the application default to an "all users" installation or provide an "all users" installation as an option when installed by Owner? |
| |
| TC2.8.2 | Does the application default to an "all users" installation or provide an "all users" installation as an option when installed by User1? |
| |
If you use the latest install programs you'll be automatically covered for T2.7 and T2.8.
| T2.9 | Support Autorun for CDs and DVDs |
| TC2.9.1 | Does the application's installer start by way of Autorun? |
| |
| TC2.9.2 | Does the application's installer correctly detect that application is already installed and avoid restarting the installation? |
| |
Autorun has been part of the operating system since Windows 95. If you're unsure about how to make this work, you can find it on MSDN. It's a relatively trivial matter to get autorun to work, but there is a nice trick you can employ: The Autorun should launch a program that detects if your game has already been installed. If it has, it should launch your game. Otherwise, it should launch your install program.
| T3.1 | Default to the correct location for storing user-created data |
| TC3.1.1 | Does the application offer a correct location for opening User1's user-created data? |
| |
| TC3.1.2 | Does the application offer a correct location for saving User1's user-created data? |
| q | Pass The application uses a correct default location. |
| q | Fail The application used an incorrect default location. Record the full path the application used. |
| TC3.1.3 | Does the application offer a correct location for opening User2's user-created data? |
| |
| TC3.1.4 | Does the application offer a correct location for saving User2's user-created data? |
| |
This is without a doubt the most significant change for Windows XP, because if your game ignores this requirement it will likely fail under Windows XP Home. There's a Win32 API that finds this directory for you:
// set the players data directory TCHAR playerDataPath[MAX_PATH]; if (SHGetSpecialFolderPath(m_hWnd,playerDataPath,CSIDL_APPDATA, true))) { // you've found the players data directory! } This call should be placed in your game initialization code after the main window has been created but before your first player data files are opened. These files aren't your game maps or sound files, rather they are your save game files or user options settings.
| T3.2 | Classify and store application data correctly |
| TC3.2.1 | Does the application store less than 128K of application data in the registry for User1? |
| |
| TC3.2.2 | Does the application store configuration data for User1 only in acceptable folders? |
| |
That test seems pretty obvious. Clearly large save game files belong in the user's application data directory, not the registry.
| T3.3 | Deal gracefully with access-denied scenarios |
| TC3.3.1 | Does the application prevent User1 from saving to the Windows system folder, E:\Windows? |
| |
| TC3.3.2 | Does the application prevent User1 from modifying documents owned by User2? |
| |
| TC3.3.3 | Does the application prevent User1 from modifying system-wide settings? |
| |
| TC3.3.4 | Does the application's installer either allow User1 to install application or degrade gracefully if the installation fails? |
| |
| T3.4 | Support running as a Limited User |
| TC3.4 | Does the application support running as User1, a Limited User? |
| |
Tests T3.3 and T3.4 are all related to access-denied situations where your install program or your game is attempting to do something it shouldn't. An interesting "ahh-ha" in T3.4 is found when you recall that most programmers run their computers as an administrator or debugger user, which has much broader access rights as other users. When your game has one of those, "It crashes in QA but is completely "unreproducable" on the programmer's machine." For problems like this, you should look closely at the user access rights.
"Optimized for Games"
The tests for games cover additional install criteria as well as tests for audio, video and network support. If you look on MSDN, you'll find a vague reference to the tests that Microsoft will expect your game to pass, but absolutely no details. Since I worked with Microsoft, I had an early version of the test details, which I'll present here. Most of the tests are pretty self-explanatory, so if I have nothing to say about them I'll simply move on to something worth discussing. I hate it when books simply restate something to restate it. Again, I won't bother telling you something you already know.
| S1.1 | General Game Playing Experience |
| S1.1.1 | The application should make sensible default choices for three-dimensional (3-D) device, resolution, and color depth without asking the user. |
| S1.1.2 | The game should use LoadLibrary or CoCreateInstance to give itself the option of failing more gracefully instead of displaying the system "missing DLL" dialog box. |
| S1.1.3 | If the game uses the LoadLibrary function to load any system components (that is, Microsoft Direct3D , Microsoft DirectInput , and so forth), do not hard-code paths. |
| S1.1.4 | The game should perform its basic operational functions over at least four hours without any problems. The game must still function after crossing the date change barrier. |
| S1.1.5 | If any system components that the game relies upon change then another first-run analysis of the computer should be performed. For example, when a new input device or display adapter is installed another analysis should be executed. |
Test S1.1.1 deals with selecting the default game options based on the players computer and installed hardware. You would pass this test if you detected a multiple monitor setup and picked the best display for your game without asking the player. The last test, S1.1.5 is somewhat related: If the hardware configuration changes, your game should detect it, and fix the settings to make the best user experience possible. This means a player can go out and upgrade their box, maybe installing the latest video card from NVidia or something, and your game should notice the difference.
S1.1.2 and S1.1.3 are just common sense, really. I wonder why these tests are included in the games specific section and not included for the nominal logo tests ?
The test for stability over four hours, and over the date change is a good one, although I wonder if Sony and Nintendo have such lax requirements. Four hours isn't that long. I'd hate to buy a hard drive with a mean time between failure measured in the single digits, wouldn't you? If I were you, I'd take stability tests a lot longer than four hours.
| S1.2 | Do Not Install or Depend on 16-bit Files: The application should not crash or fail to execute on 32-bit edition Windows XP because of a dependency on 16-bit code. The application must not read install or depend on 16-bit files. |
| S1.3 | Do not write to Config,sys, Autoexec.bat, Win.ini, or System.ini files: The application must not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys on any Windows operating system. |
Tests S1.2 and S1.3 make sure you've moved your game into the modern age. Back in the day game programmers had no problem putting crazy stuff into autoexec.bat, config.sys, and Windows INI files. If you are reading this and you have no idea what these files are, good for you. You're already ahead of the game. If your curious about them, find a computer museum and boot up a Windows 3.1 box.
| S1.4 | Provide both manual and automatic install options: Near the start of installation (after any option license agreement), provide the user with the option of selecting either Automatic or Manual installation. The Automatic installation will make as many logical choices as possible for the user. The Manual installation may take the user to another dialog box where the user can choose any number of installation types: custom, typical, minimal, and so on. |
This is a really good idea, since many games have the possibility of installing different levels of game data on the player's hard drive, trading hard drive space for performance or level of detail in the game.
| S1.5 | Allow installation termination: The user should be able to cancel out of an installation at any time before the installation completes. For each dialog box of this install process, make sure that your application can stop the installation. |
Again, another test that should probably be in the general tests for all applications, and not games. Still, this feature is a good common sense item to put in your install program.
| S1.6 | Running from CD or DVD |
| S1.6.1 | If the game requires a CD or DVD for game play even with the game fully installed on the hard drive, launching the game from the Start menu\Games folder should display an "Insert CD or DVD" message if the CD or DVD is not in the drive. When the CD or DVD is inserted, then the game should continue to run without requiring the user to restart the game. |
| S1.6.2 | The game must be able to be played on a different CD or DVD drive than the one from which it was installed. |
| S1.6.3 | The game must work even in situations where Red Book audio is not available for a particular drive (for example, external drives). |
Test S1.6.1 is satisfied by the code discussed in the WM_DEVICECHANGE section earlier in this chapter. S1.6.2 needs a little more work. Here's how to search the computer for the marker file:
enum CDPOLL_ENUM { POLL_SUCCESSFUL, NO_CD_ROM_FOUND, NO_CD_DRIVE_FOUND }; CDPOLL_ENUM PollForCD(const _TCHAR *markerFilePath) { CDPOLL_ENUM result = NO_CD_DRIVE_FOUND; /* Assume failure. */ unsigned int drive_type = DRIVE_UNKNOWN; int drive; _TCHAR path[_MAX_PATH]; _TCHAR current_directory[_MAX_PATH]; FILE *test_file = NULL; int Current_Drive_Index = 0; /* Save current drive. */ GetCurrentDirectory( _MAX_PATH, current_directory ); Current_Drive_Index = _getdrive(); /* Set this to -1 for easy error checking. */ int iCDDriveIndex = -1; /* If we can switch to the drive, it exists. */ for( drive = 3; drive <= 26; drive++ ) { if( 0 == _chdrive( drive ) ) { GetCurrentDirectory( _MAX_PATH, path ); drive_type = GetDriveType( path ); if( (drive_type == DRIVE_CDROM) #ifdef _DEBUG || (drive_type == DRIVE_FIXED) || (drive_type == DRIVE_REMOVABLE) || (drive_type == DRIVE_REMOTE) #endif ) { iCDDriveIndex = drive; /* Found the drive, now look for the CD-ROM. */ result = NO_CD_ROM_FOUND; _TCHAR buffer[_MAX_PATH]; _tcscpy(buffer, path); _tcscat(buffer, markerFilePath); if (0 FFFFFFFF == GetFileAttributes(buffer)) { int a = GetLastError(); result = NO_CD_ROM_FOUND; } else { result = POLL_SUCCESSFUL; break; } } } } /* Restore original drive.*/ _chdrive( Current_Drive_Index ); SetCurrentDirectory(current_directory); if (result == POLL_SUCCESSFUL) { m_CDPath.Format(_T("%c:\\"), iCDDriveIndex + 'A' - 1); } #ifdef _DEBUG return POLL_SUCCESSFUL; #else return result; #endif } You would call this code in a while loop, with a message box or some other game dialog:
while (PollForCD(searchFile) != POLL_SUCCESSFUL) { // Bring up a dialog box and ask the player to find their CD. }
| S1.7 | Games must be rated: The game must be rated by and adhere to guidelines specified by the Entertainment Software Ratings Board (ESRB) if the game is to be distributed in North America and by the appropriate ratings for the country in which the game is distributed. |
I often wonder what it would be like to play with a copy of Microsoft Word that had an ESRB rating for adults only. I would probably be less productive.
| S1.8 | 3-D and Graphics Support |
| S1.8.1 | If the game uses Direct3D, it should be the default method for displaying graphics. |
| S1.8.2 | If the game employs 3-D graphics and runs in full-screen mode, all screen resolutions enabled in the game should be supported by the computer. If it runs in windowed mode, it should properly handle a range of resolutions. A friendly error dialog box must appear for any resolution that is not supported. |
| S1.8.3 | The game must not rely on the presence of Microsoft DirectX color-keyed textures. Alpha channels and true-color textures are strongly preferred, and products must not crash simply because the hardware does not support the obsolete methods. |
| S1.8.4 | The game must not rely on the presence of DirectX palette textures. Alpha channels and true-color textures are strongly preferred, and products must not crash simply because the hardware does not support the obsolete methods. |
| S1.8.5 | The game must not use retained mode or the ramp-mode rasterizer. |
| S1.8.6 | If the product employs 3-D graphics, it should support hardware acceleration. |
| S1.8.7 | If the game supports 3-D graphics hardware acceleration then it must support cards from at least 2 chipset manufacturers. |
| S1.8.8 | If the game uses Microsoft DirectDraw , it must not use device-independent bitmap (DIB) sections or other legacy methods. |
| S1.8.9 | If the game changes the resolution or colors to play the game in full-screen mode, it must restore the original resolution and color depth when the game exits. |
| S1.8.10 | The game must not rely on Hardware Cursor Support. |
The first test in this and the next two test groups cracks me up. In order to get blessing from Microsoft you have to prefer Microsoft's technology. I'm not sure what I think about that exactly, but I'm not the one setting the rules.
Test S1.8.2 is directly related to the full-screen and windowed mode discussion at the beginning of this chapter.
Concerning S1.8.5, These old rasterizers refer to pre-DirectX 8 technologies. If the test was rewritten it would probably refer to the reference rasterizer, which is written to display accuracy instead of speed. This and the remaining tests fall into that "Duh, sure..." category.
| S1.9 | Audio Support |
| S1.9.1 | If the game uses Microsoft DirectSound , it should be the default method for providing sound. |
| S1.9.2 | The game should use the DirectSound API to handle all calls and not call the cards directly to use specific features of specific cards. |
| S1.9.3 | On systems with more than two audio output channels, audio must emanate from appropriate speakers. For games that use 3-D audio, this means that sounds should pan around the listener using all available speakers. For games that do not use 3-D audio, audio may, but need not, emanate from the rear speakers. |
| S1.9.4 | The game must not disturb volume settings. If the game can adjust its audio volume, settings must be unchanged on exiting the Windows Volume Control. |
| S1.9.5 | If audio is not essential to the operation of the game, it must run on a computer without a sound card installed. |
Again, tests S1.9.1 and S1.9.2 show a little chauvinism regarding other technologies, but that doesn't surprise anyone does it?
| S1.10 | Device Support |
| S1.10.1 | If the game uses Directlnput, it should be the default method for input. |
| S1.10.2 | The game must support game playing devices on more than ID1. Game playing devices on ID2 or higher must be supported. |
| S1.10.3 | A method should be provided for the user to easily select which device he or she wants to use to play a game (that is, switching from one joystick to another or from a joystick to the keyboard and mouse). |
| S1.10.4 | On platforms that support multiple keyboards, the game must work properly when there are two keyboards plugged into the system. Because the limitation on the number of keys pressed simultaneously is normally a hardware limitation, it can be overcome by using multiple keyboards. The game must not crash, stop responding, or lose data when multiple keyboards are used to cause more simultaneously pressed keys to be reported than would be possible with one keyboard. |
| S1.10.5 | The game must not fail when used with mice with more than three-mouse buttons. |
Test S1.10.4 implies that a platform with multiple keyboards exists. I haven't seen it, and even if I saw it I'm not sure I'd believe it. Perhaps I can have a different font setting for each keyboard? I guess it would be cool to have a machine with two different language keyboards; but alas I don't speak or read Japanese.
| S1.11 | Network Support |
| S1.11.1 | If the game has an online component, it should recognize when it is in its offline state. For example, the game must not spend minutes trying to reach an unreachable master server. |
| S1.11.2 | All non-working networking options should be detected and disabled from the list of choices presented to the user. |
| S1.11.3 | During lengthy network transactions, the user should be able to cancel operations at any time. |
Do you notice something missing from the network tests? DirectPlay! Again, that cracks me up. This is most likely due to the fact that there are a few networked-enabled Microsoft games that don't use DirectPlay. I won't point them out.
- ERP Systems Impact on Organizations
- Enterprise Application Integration: New Solutions for a Solved Problem or a Challenging Research Field?
- The Effects of an Enterprise Resource Planning System (ERP) Implementation on Job Characteristics – A Study using the Hackman and Oldham Job Characteristics Model
- Intrinsic and Contextual Data Quality: The Effect of Media and Personal Involvement
- Relevance and Micro-Relevance for the Professional as Determinants of IT-Diffusion and IT-Use in Healthcare