INFO: The Windows 95 Rundll and Rundll32 Interface

ID: Q164787

The information in this article applies to:

Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows NT version 4.0 - Microsoft Windows 95

SUMMARY

Windows 95 contains two command-line utility programs named Rundll.exe and Rundll32.exe that allow you to invoke a function exported from a DLL, either 16-bit or 32-bit. However, Rundll and Rundll32 programs do not allow you to call any exported function from any DLL. For example, you can not use these utility programs to call the Win32 API (Application Programming Interface) calls exported from the system DLLs. The programs only allow you to call functions from a DLL that are explicitly written to be called by them. This article provides more details on the use of Rundll and Rundll32 programs under Windows NT and Windows 95. The Rundll and Rundll32 utility programs were originally designed only for internal use at Microsoft. But the functionality provided by them is sufficiently generic that they are now available for general use. Note that Windows NT 4.0 ships only with the Rundll32 utility program and supports only Rundll32.

MORE INFORMATION

Rundll vs. Rundll32

Rundll loads and runs 16-bit DLLs, whereas Rundll32 loads and runs 32-bit DLLs. If you pass the wrong type of DLL to Rundll or Rundll32, it may fail to run without indicating any error messages.

Rundll command line

The command line for Rundll is as follows:

   RUNDLL.EXE <dllname>,<entrypoint> <optional arguments>

An example is as follows:

   RUNDLL.EXE SETUPX.DLL,InstallHinfSection 132 C:\WINDOWS\INF\SHELL.INF

There are 3 issues to consider carefully in the above command line:

1. Rundll or Rundll32 search for the given DLL filename in the standard

   places (see the documentation for the LoadLibrary() function for
   details). It is recommended that you provide a full path to the DLL to
   ensure that the correct one is found. For best results, use the short
   file name instead of the long file name to ensure that no illegal
   characters will appear. Note in particular that this means a DLL in the
   "C:\Program Files" folder should be converted to its short name.

2. The <dllname> may not contain any spaces or commas or quotation marks.

   This is a limitation in the Rundll command line parser.

3. In the above command line, the comma (,) between the <dllname> and the

   <entrypont> function name is extremely important. If the comma
   separator is missing, Rundll or Rundll32 will fail without indicating
   any errors. In addition, there cannot be any white spaces in between
   the <dllname>, the comma, and the <entrypoint> function.

How Rundll Works

Rundll performs the following steps:

1. It parses the command line. 2. It loads the specified DLL via LoadLibrary(). 3. It obtains the address of the <entrypoint> function via

   GetProcAddress().

4. It calls the <entrypoint> function, passing the command line tail which

   is the <optional arguments>.

5. When the <entrypoint> function returns, Rundll.exe unloads the DLL

   and exits.

How to Write Your DLL

In your DLL, write the <entrypoint> function with the following prototype:

16-bit DLL:

  void FAR PASCAL __loadds
  EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);

32-bit DLL:

  void CALLBACK
  EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);

Again, there are 3 issues to consider with the EntryPoint function:

1. Obviously, the name "EntryPoint" should be replaced with the actual

   name of your entry point function.  Note that the Rundll32's entry
   point is completely unrelated to the DllEntryPoint function in a 32-bit
   DLL which handles process and thread attach/detach notifications.

2. The entry point function for Rundll32 must be defined with the _stdcall

   calling convention (CALLBACK defaults to using the _stdcall attribute).
   If the _stdcall attribute is missing, then the function defaults to
   _cdecl calling convention and then Rundll32 will terminate abnormally
   after calling the function.

3. Since you must declare the function with _stdcall calling convention as

   described above, it follows that the Visual C++ compiler will actually
   export it as _EntryPoint@16 if the DLL is written in C or will use
   further name decoration if the DLL is written in C++.  So, be careful
   to use the correctly exported name in the command line for Rundll or
   Rundll32.  If you want to avoid using decorated names, use a .def file
   and export the entry point function by name.  Please refer to the
   product documentation and the following article for further information
   on name decoration when using Visual C++ compilers:

     ARTICLE ID: Q140485
     TITLE     : Exporting PASCAL-Like Symbols in 32-bit DLLs

The parameters to the Rundll entry point are as follows:

   hwnd - window handle that should be used as the owner window for
          any windows your DLL creates
   hinst - your DLL's instance handle
   lpszCmdLine - ASCIIZ command line your DLL should parse
   nCmdShow - describes how your DLL's windows should be displayed

In the following example:

   RUNDLL.EXE SETUPX.DLL,InstallHinfSection 132 C:\WINDOWS\INF\SHELL.INF

Rundll would call the InstallHinfSection() entrypoint function in Setupx.dll and pass it the following parameters:

   hwnd = (parent window handle)
   hinst = HINSTANCE of SETUPX.DLL
   lpszCmdLine = "132 C:\WINDOWS\INF\SHELL.INF"
   nCmdShow = (whatever the nCmdShow was passed to CreateProcess)

Note that it is the <entrypoint> function (or InstallHinfSection() in the above example) that has to parse its own command line (the lpszCmdLine parameter above) and use the individual parameters as necessary. Rundll.exe parses only up to the optional arguments passed to its command line. The rest of the parsing is up to the <entrypoint> function.

Special Notes On Differences Between Windows 95 And Windows NT

On Windows NT, the behavior of Rundll32.exe is slightly different, in order to accommodate UNICODE command lines.

Windows NT first attempts to GetProcAddress for <EntryPoint>W. If this entry point is found, then the prototype is assumed to be:

   void CALLBACK
   EntryPointW(HWND hwnd, HINSTANCE hinst, LPWSTR lpszCmdLine,
               int nCmdShow);

This is the same as the ANSI EntryPoint, except that the lpszCmdLine parameter is now a UNICODE string.

If the <EntryPoint>W entry point is not found, then Windows NT will GetProcAddress for <entrypoint>A and for <entrypoint>. If either is found, then it is considered an ANSI entry point and is treated the same way as Windows 95. Therefore, if you want your DLL to run on Windows 95 with ANSI support and on Windows NT with UNICODE support, you should export two functions: EntryPointW and EntryPoint. On Windows NT, the EntryPointW function will be called with a UNICODE command line; on Windows 95, the EntryPoint function will be called with an ANSI Command line.

REFERENCES

For an example on the usage of Rundll, refer to the following article on how to launch a Control Panel Applet in Windows 95 using the Rundll command line utility:

   ARTICLE ID:Q135068
   TITLE     :How to Start a Control Panel Applet in Windows 95

Additional query words: win95 tools

Keywords          : kbprg kbtool kbusage kbnokeyword kbDLL kbKernBase kbGrpKernBase 
Version           : 4.0
Platform          : NT WINDOWS

Last Reviewed: March 29, 1997