Summary
Microsoft Windows 95, Windows 98, and Windows Millennium Edition (me) contain two command line utilities: rundll.exe and rundll32.exe, they can be used to call functions exported from 16-bit or 32-bit DLL. However, using the rundll and rundll32 programs cannot call any function exported from any DLL. For example, you cannot use these two utilities to call Win32 APIs (application programming interfaces) exported from system DLL. These two programs only allow you to call the functions exported from the DLL and explicitly written for the two programs. This article describes in detail how to use rundll and rundll32 programs in the Windows operating system listed above.
Microsoft Windows NT 4.0, Windows 2000, and Windows XP are released with only rundll32. These platforms do not support rundll (Win16 utility.
The rundll and rundll32 utilities were initially designed for use only within Microsoft. However, they provide very common functions, so they are currently available in general. Note that only the rundll32 utility is attached to Windows NT 4.0 and only rundll32 is supported.
More information
Comparison between rundll and rundll32
Rundll loads and runs 16-bit DLL while rundll32 loads and runs 32-bit DLL. If you pass an incorrect DLL type to rundll or rundll32, it may not run and will not display any error messages.
Rundll command line
The command line of rundll is as follows: rundll. EXE <dllname>, <entrypoint> <optional arguments>
Example: rundll. EXE setupx. dll, installhinfsection 132 C:/Windows/INF/shell. inf
In the preceding command line, there are three issues that need to be carefully considered: 1. rundll or rundll32 searches for the given DLL file name in the standard location (see the documentation on the loadlibrary () function for details ). We recommend that you provide the complete dll path to ensure that the required DLL is located. For the best results, use a short file name instead of a long file name to ensure that no invalid characters appear. Note that this means that the DLL in the "C:/Program Files" folder should be converted to a short name.
2. <dllname> cannot contain any spaces, commas, or quotation marks. This is a limitation of the rundll command line analyzer.
3. In the preceding command line, the comma (,) between the <dllname> and <entrypont> function names is extremely important. If the comma Delimiter is missing, rundll or rundll32 will fail without any errors. In addition, there cannot be any blank space between the <dllname>, comma, and <entrypoint> functions.
How rundll works
Rundll: 1. Analyze the command line.
2. It loads the specified DLL through loadlibrary.
3. It obtains the address of the <entrypoint> function through getprocaddress.
4. It calls the <entrypoint> function and passes it as the end of the <optional arguments> command line.
5. When <entrypoint> uninstall returns, rundll.exe uninstalls the DLL and exits.
How to compile DLL
In your DLL, use the following prototype to compile the <entrypoint> function:
16-bit dll:
Void far Pascal _ loadds
Entrypoint (hwnd, hinstance hinst, lpstr lpsz1_line, int ncmdshow );
32-bit dll: void callback
Entrypoint (hwnd, hinstance hinst, lpstr lpsz1_line, int ncmdshow );
Similarly, the entrypoint function has three problems to consider: 1. Obviously, the "entrypoint" name should be replaced with the actual name of your entry point function. Note that the entry point of rundll32 has nothing to do with the dllentrypoint function in the 32-bit DLL. The latter processes the process and thread connection/separation notifications.
2. The entry point function of rundll32 must be defined using the _ stdcall call Convention (callback uses the _ stdcall attribute by default ). If the _ stdcall attribute is missing, the function uses the _ cdecl call Convention by default, and rundll32 terminates abnormally after calling the function.
3. because you must declare the function using the _ stdcall call Convention described above, if the DLL is written in C language, the visual C ++ compiler will export the function to _ entrypoint @ 16; if the DLL is written in C ++, the visual C ++ compiler will further use the name. Therefore, be sure to use the exported name in the command line of rundll or rundll32. If you want to avoid modifying the name, use the. Def file and export the entry and exit functions by name. When using the Visual C ++ compiler, refer to the product documentation and the following articles for more information on name modification:
| Reference |
| Exporting Pascal-like symbols in 32-bit DLLs Summary There is no _ Pascal keyword in the 32-bit editions of Visual C ++. instead the windef. h header file has Pascal defined as _ stdcall. this creates the correct style calling convention for the function (the called function cleans up the stack) But decorates the function name differently. so, when _ declspec (dllexport) is used (in. DLL file, for example), the decorated name is exported instead of the desired Pascal style name, which is undecorated and all uppercase. More information Pascal name decoration is simply the undecorated symbol name in uppercase letters. _ stdcall name decoration prefixes the symbol name with an underscore (_) and appends the symbol with an at sign (@) character followed by the number of bytes in the argument list (the required stack space ). so, the function when declared as: int _ stdcall func (int A, double B) Is decorated as: _ FUNC @ 12 The C calling convention (_ cdecl) decorates the name as _ FUNC. Whereas the desired Pascal style name is func. To get the decorated name set the generate mapfile option in the linker General Category setting. Use of _ declspec (dllexport) Does the following :&# 8226; if the function is exported with C calling convention (_ cdecl), It strips the leading underscore (_) when the name is exported. & #8226; if the function being exported does not use the C calling convention (for example, _ stdcall), it exports the decorated name. So to simulate Pascal name decoration and calling conventions, you must have the "called function stack clean-up" provided by using _ stdcall and the undecorated uppercase name. Because there is no way to override who does the stack clean up, you must use _ stdcall. to undecorate names with _ stdcall, you must specify them by using aliases in the exports section of. def file. this is shown below for the following function declaration: int _ stdcall myfunc (int A, double B ); Void _ stdcall initcode (void ); In the. Def file: exports Myfunc = _ myfunc @ 12 Initcode = _ initcode @ 0 For. DLL files to be called by programs written in the 32-bit versions of Visual Basic (versions 4.0 and above), the alias technique shown in this article is needed in. def file. if alias is done in the Visual BASIC Program, use of aliasing in. def file is not necessary. it can be done on the Visual BASIC program by adding an alias clause to the declare statement as shown here: declare function myfunc lib "dlllibname" alias "_ myfunc @ 12 "(...) As integer The complete syntax for the Visual Basic declare statement follows: [Public | private] declare function name lib "Libname" [alias "aliasname"] [([Arglist])] [as type] References For more information, query the msdn compact disc using these keywords: VB alias DLL |
The parameters of the rundll entry point are as follows: hwnd-window handle, which should be used for any windows created by your DLL
Owner window
Hinst-instance handle of your DLL
Lpszcmdline-The asciiz command line that your dll should analyze
Ncmdshow-describe how to display your DLL window
In the following example: rundll. EXE setupx. dll, installhinfsection 132 C:/Windows/INF/shell. inf
Rundll will call the installhinfsection () entry point function in setupx. dll and pass the following parameter to it: hwnd = (parent window handle)
Hinst = hinstance of setupx. dll
Lpszw.line = "132 C:/Windows/INF/shell. inf"
Ncmdshow = (any ncmdshow passed to CreateProcess)
Note that the <entrypoint> function (installhinfsection () in the preceding example) must analyze its own command line (the preceding lpszcmdline parameter) and use individual parameters when necessary. Rundll.exe can only analyze the optional parameters of the command line passed to it. The <entrypoint> function performs other analysis tasks.
Special notes on differences between Windows 95 and Windows NT
In Windows NT, Windows 2000, and Windows XP, The rundll32.exe behavior is slightly different to adapt to the Unicode command line.
Windows NT first tries to call getprocaddress for <entrypoint> W to obtain its address. If this entry point is found, it is assumed that the prototype is void callback.
Entrypointw (hwnd, hinstance hinst, lpwstr lpsz1_line,
Int ncmdshow );
This is the same as ANSI entrypoint, except that the lpszcmdline parameter is now a unicode string.
If the <entrypoint> W entry point is not found, Windows NT calls getprocaddress for <entrypoint> A and <entrypoint> to obtain its address. If neither address is found, the endpoint is considered as an ANSI endpoint and processed as in Windows 95/98/ME. Therefore, if you want your DLL to run in Windows 95 with ANSI support and Windows NT/2000/XP with Unicode support, you should export the following two functions: entrypointw and entrypoint. In Windows NT/2000/me, use the Unicode command line to call the entrypointw function. In Windows 95/98/me, use the ANSI command line to call the entrypoint function.