Article ID: 164787 - View products that this article applies to.
This article was previously published under Q164787
Microsoft Windows 95, Windows 98, and Windows Millennium Edition (Me) 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 the Windows operating systems listed above.
MIcrosoft Windows NT 4.0, Windows 2000, and Windows XP ship with only Rundll32. There is no support for Rundll (the Win16 utility) on either platform.
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.
Rundll vs. Rundll32Rundll 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 lineThe command line for Rundll is as follows:
An example is as follows:
There are 3 issues to consider carefully in the above command line:
How Rundll WorksRundll performs the following steps:
How to Write Your DLLIn your DLL, write the <entrypoint> function with the following prototype:
Again, there are 3 issues to consider with the EntryPoint function:
In the following example:
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
Rundll would call the InstallHinfSection() entrypoint function in Setupx.dll and pass it the following parameters:
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.
hwnd = (parent window handle) hinst = HINSTANCE of SETUPX.DLL lpszCmdLine = "132 C:\WINDOWS\INF\SHELL.INF" nCmdShow = (whatever the nCmdShow was passed to CreateProcess)
Special Notes On Differences Between Windows 95 And Windows NTOn Windows NT, Windows 2000, and Windows XP 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:
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/98/Me. Therefore, if you want your DLL to run on Windows 95 with ANSI support and on Windows NT/2000/XP with UNICODE support, you should export two functions: EntryPointW and EntryPoint. On Windows NT/2000/Me, the EntryPointW function will be called with a UNICODE command line; on Windows 95/98/Me, the EntryPoint function will be called with an ANSI Command line.
Article ID: 164787 - Last Review: November 21, 2006 - Revision: 4.4