This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

September 1998

Microsoft Systems Journal Homepage

Download sep98Win32.exe (6KB)

Jeffrey Richter wrote Advanced Windows, Third Edition (Microsoft Press, 1998) and Windows 95: A Developer's Guide (M&T Books, 1995). Jeff is a consultant and teaches Win32 programming courses (http://www.jeffreyrichter.com.

Q When I insert a disc into my CD-ROM drive, the system automatically runs the application on the disc. Can you explain how Windows® does this and how my application can take advantage of this feature? Also, is there a way to disable it?

Kristin Trace

A Starting with Windows 95, Microsoft introduced a new technology called AutoPlay that makes working with CD-ROMs a little easier for the user. The CD-ROM device driver that comes with the system is notified when the user inserts a disc into the CD-ROM drive. When the driver receives this notification, it tells the system, which immediately looks in the root directory of the CD-ROM disc for a file called AUTORUN.INF.
      AUTORUN.INF is an ASCII text file that you should create if you are distributing your application on a CD-ROM disc. Here is what the AUTORUN.INF file looks like: 


 [autorun]
 Open=CmdLine
 Icon=IconPathName, IconIndex
 
 Shell\Option1=MenuOptionString1
 Shell\Option1\Command=CmdLineOption1
 
 Shell\Option2=MenuOptionString2
 Shell\Option2\Command=CmdLineOption2
 •
 •
 •
 Shell=OptionDefault
The Open=CmdLine field is a command line (which may include arguments) that will be executed by the system when the disc is inserted. If you specify a path before any EXE file, that path is relative to the root directory of the CD-ROM disc.
      The application that you execute should be small in size, should load quickly, and should present itself to the user very quickly. In addition, you should not just start copying files over to the user's hard disk. If possible, design your application so that it can run entirely off the CD-ROM disc.
      The IconPathName identifies the path (relative to the root of the CD-ROM disc) and file name of a file that contains an icon. This file can be an ICO, BMP, EXE, or DLL file. You can use the IconIndex field to specify which icon to use from the file if it contains more than one icon. The shell uses this icon when it displays the CD-ROM drive. Figure 1 shows the My Computer folder open with an AutoPlay CD-ROM disc installed (drive E:).
Figure 1 AutoRun Icon in Action
Figure 1 AutoRun Icon in Action

      When the user double-clicks on the icon in the folder or selects the Open option from the File menu, CmdLine is executed. It is also possible to create additional menu options on the File menu. The Shell\Optionn lines in the AUTORUN.INF file tell the shell which menu options to add. For example, if you want to add a menu option that allows the user to read a notes file that comes with your application, create the AUTORUN.INF file like this: 

 [autorun]
 Open=MyApp.exe
 Icon=MyApp.exe, 0
 
 Shell\ReadMe=Read &Me First
 Shell\ReadMe\Command=Notepad.exe Readme.Txt
You can have as many menu options as you like, but you should keep the number to a minimum so that the user is not overwhelmed.
      The last field, Shell=OptionDefault, allows you to specify which menu option should be executed if the user double-clicks on the icon. You set this field to Option1, Option2, or any other option that you have added to the AUTORUN.INF file. Normally, the Open command is the default menu option.
      The original AutoPlay architects were not thinking about Windows NT®; if they were, they would have considered CPU platforms other than the Intel x86. If you create an AUTORUN.INF file and name an Intel x86 Win32® EXE file in the CmdLine field, the application will not be able to execute at all when using Windows NT on non-Intel platforms. So, when Windows NT 4.0 shipped with AutoPlay, Microsoft had to enhance the architecture a little bit. On Windows NT, the shell looks for a section named 

 [autorun.CPUName]
where CPUName is either mips, alpha, or ppc. (Note that Windows NT 5.0 is not expected to support the MIPS and PowerPC platforms.) If the shell doesn't find an appropriately named section, it just uses whatever is found in the standard [autorun] section.
      Some users do not like the AutoPlay feature and they can choose to disable it. There are three ways to do this. First, if the user holds down the Shift key while inserting a CD-ROM disc, the system will not execute the default option. Second, the user can display the My Computer property sheet, select the Device Manager tab and then display properties for a particular CD-ROM drive (see Figure 2). The "Auto insert notification" option turns CD-ROM disc insertion detection on or off.
Figure 2 Disabling AutoPlay
Figure 2 Disabling AutoPlay

      Third, the user can make a change to a registry value. AutoPlay detection is determined by the following key: 

 HKEY_CURRENT_USER\Software\Microsoft\
 Windows\CurrentVersion\Policies\Explorer
Under this key, is the following value: 

 NoDriveTypeAutoRun = 95 00 00 00
This value is a single 32-bit number. When Windows is installed, the default value is 0x00000095. Only the low bits, 0 through 7, are used. The remaining bits are reserved and should always be set to 0. Each of the low 7 bits corresponds to a possible return value from the GetDriveType function. This function returns one of the values listed in Figure 3.
      A value of 0x00000095 is the same as 10010101 binary. This means that bits 0, 2, 4, and 7 are turned on. The bits that are turned on represent the drive types for which AutoPlay is disabled. In this example, AutoPlay is disabled for unknown drives, removable drives, remote drives, and some undefined types of drives. One thing to note is that on Windows NT you must log off and log on again for this AutoPlay registry change to take effect. On Windows 95, the change takes effect immediately upon changing the registry value.
      When the My Computer folder refreshes its pane, it examines these bits. If AutoPlay is enabled, Windows Explorer checks for an AUTORUN.INF file and, if the file exists, the specified icon is displayed. In addition, Windows Explorer will show any menu options specified in the file. When I am targeting a CD-ROM disc, I always turn some of these bits off so that I can test my AUTORUN.INF file without having to burn a CD-ROM disc first.
      In addition to a user wanting to cancel AutoPlay, a developer may want to disable this feature in an app. A simple example is a setup program that requires the user to insert a CD-ROM disc that contains its own AUTORUN.INF file. Or, say a full-screen game is running and you don't want to take the user out of the experience while swapping CD-ROM discs. In cases like these, you'll definitely want to set up your app to disable AutoPlay.
      On Windows NT 4.0 and Windows 98, Microsoft modified the shell so that it broadcasts a registered string message, QueryCancelAutoPlay, before it automatically opens an AutoPlay CD-ROM. If any application responds with a 1 to this message, the shell does not autoplay the CD-ROM. But if all applications return 0, the CD-ROM is autoplayed. The sample code in Figure 4 demonstrates the use of this new message.

Q The following code first opens a file for exclusive access and then attempts to reopen the file for read/write access: 


 HANDLE hfileExclusive =
 CreateFile("\\\\Server\\SomeFile.txt", GENERIC_READ |    
            GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, 0, NULL);
 DWORD dwTime = GetTickCount();
 HANDLE hfileShared = 
 CreateFile("\\\\Server\\SomeFile.txt", GENERIC_READ |
            GENERIC_WRITE,
            FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
            OPEN_ALWAYS, 0, NULL);
 dwTime = GetTickCount() - dwTime;
 // Why is dwTime about 1000 milliseconds (1 second)??
 •
 •
 •
I know that the second call to CreateFile should fail, but what I don't understand is why it seems to take a full second for it to fail if the file I'm opening is maintained on a network server.

A When a client machine requests that a file be opened on a server, the server opens the file and the response is returned to the client. However, if the open fails, the server uses two registry values to control what it should do. Both of these values are under the following subkey: 


 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
LanmanServer\Parameters
The first value, SharingViolationRetries, indicates the number of times that the server will automatically retry the open operation when a sharing violation is detected. The second value, SharingViolationDelay, indicates the number of milliseconds the server waits between each retry.
      The purpose of these values is to minimize the client/server network traffic when the client continuously tries to open a file when it detects sharing violations. If either value is too low, then the next try is also likely to fail; if the values are too high, then the client machine waits longer before getting a response from the server. When Windows NT is installed, these values default to 5 and 200, respectively, which explains the one-second delay that you are experiencing.

Q A user can enter a modal menu loop by pressing F10, pressing Alt+(menu mnemonic), or clicking on a popup menu item. In my application, I need to force Windows out of this modal menu state. Is there some way I can do this? I also need this to work for menus displayed using the TrackPopupMenu function.

A Oh great; this is an easy one. All you have to do to get out of the modal menu loop is send a WM_CANCELMODE message to the window owning the menu. Just to test this out, I wrote the following piece of code: 


 #include <windows.h>
 
 void main () {
 
     while (TRUE) {
         Sleep(5000);
         SendMessage(HWND_BROADCAST, WM_CANCELMODE, 0, 0);
     }
 }
I always run this code in the debugger so that I can stop it when I'm done testing. This code is very simple: every five seconds it wakes up and sends a WM_CANCELMODE message to every top-level window in the system. If you are in menu mode for either a window menu or a popup menu, the mode is cancelled. Note that the previous code is just for testing purposes. The WM_CANCELMODE message also cancels scroll bar loops and mouse captures, so you don't want to keep this application running very long.

Have a question about programming in Win32? Send your questions via email to Jeffrey Richter from his website at http://www.jeffreyrichter.com.

From the September 1998 issue of Microsoft Systems Journal.