LoadLibrary The LoadLibrary function maps the specified executable module into the address space of the calling process. HINSTANCE LoadLibrary( LPCTSTR lpLibFileName // address of filename of executable module );
Parameters lpLibFileName Pointer to a null-terminated string that names the executable module (either a .DLL or .EXE file). The name specified is the filename of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.DEF) file. If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). If the string does not specify a path, the function uses a standard search strategy to find the file. See the Res for more information. Return Values If the function succeeds, the return value is a handle to the module.If the function fails, the return value is NULL. To get extended error information, call GetLastError. Res LoadLibrary can be used to map a DLL module and return a handle that can be used in GetProcAddress to get the address of a DLL function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .EXE file to get a handle that can be used inFindResource orLoadResource. Do not use LoadLibrary to "run" a .EXE file. If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If the DLL's entry-point function does not return TRUE, LoadLibrary fails and returns NULL. It is not safe to call LoadLibrary from DllMain. For more information, see the Res section in DllMain. Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use — for example, in calling GetProcAddress. The other process must make its own call to LoadLibrary for the module before calling GetProcAddress. If no filename extension is specified in the lpLibFileName parameter, the default library extension .DLL is appended. However, the filename string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence: The directory from which the application loaded. The current directory. Windows 95 and Windows 98: The Windows system directory. Use theGetSystemDirectory function to get the path of this directory. Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM. The Windows directory. Use theGetWindowsDirectory function to get the path of this directory. The directories that are listed in the PATH environment variable. The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary or LoadLibraryEx. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread). Windows 95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. Windows CE: Two different modules cannot have the same filename, given that the extensions are different. These effectively have the same "module" name. For example, if LoadLibrary is made on "Sample.cpl", the operating system will not load Sample.cpl, but instead will again load Sample.dll. A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on "\\Windows\Sample.dll", and then LoadLibrary is called on "\\MyDir\Sample.dll", "\\Windows\Sample.dll" will simply be reloaded.A search path to the executable module cannot be specified. Unless the full path to the module is given, Windows CE will search the following path for the module: The root directory of the PC Card RAM expansion card, if one exists. The windows directory (\Windows). The root directory (\). QuickInfo Windows NT: Requires version 3.1 or later. Windows: Requires Windows 95 or later. Windows CE: Requires version 1.0 or later. Header: Declared in winbase.h. Import Library: Use kernel32.lib. Unicode: Implemented as Unicode and ANSI versions on Windows NT.See Also Dynamic-Link Libraries Overview, Dynamic-Link Library Functions, DllMain,FindResource, FreeLibrary, GetProcAddress,GetSystemDirectory,GetWindowsDirectory, LoadLibraryEx,LoadResource
弄进去应该没有用，word，excel，创建的对象是application对象，需要整个环境
弄进去应该没有用，word，excel，创建的对象是application对象，需要整个环境
那我要怎么做才可以啊？
1，你要是管理员权限
2，你右键选run as administrator
3,把uac关掉试试看
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
那不是证明了你缺少的引用来自VB么，你自己把所有的引用和引用的依赖文件打包过去不就好了么
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
那证明你缺少的文件来自VB，用VB自带的打包软件打包，然后按照，一般都不会有你说的问题
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
那证明你缺少的文件来自VB，用VB自带的打包软件打包，然后按照，一般都不会有你说的问题
机器上EXCEL版本不一样.
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
那证明你缺少的文件来自VB，用VB自带的打包软件打包，然后按照，一般都不会有你说的问题用VB自带的打包软件在Win7上安装过，还是一样的错误，不知道是不是Win7的权限问题还是什么？XP系统下周一去试一下
1，你要是管理员权限
2，你右键选run as administrator
3,把uac关掉这些你试验过了么
没有用，我在其他的XP系统与Win7系统都试过了，都是因为没有装VB软件，后来试了一台机子装上VB后就运行正常，请问我要怎么解决这个问题，不可能别人都要装上VB才能用吧？
那证明你缺少的文件来自VB，用VB自带的打包软件打包，然后按照，一般都不会有你说的问题问题依旧，不知道是不是我打包时有没有漏了步骤？能不能提供下打包详细过程与选项教程。
或者在depends.exe中运行让其捕获动态加载的ocx或dll
regsvr32 /s xxx.ocx或dll
注意：Win7下还要注意以管理员身份运行
注意：64位Windows下所有32位程序和dll、ocx啥的比如regsvr32.exe都在c:\windows\syswow64\目录下
win7下默认没有管理员权限, 所以无法注册相关dll和ocx 导致429错误
The LoadLibrary function maps the specified executable module into the address space of the calling process. HINSTANCE LoadLibrary(
LPCTSTR lpLibFileName // address of filename of executable module
);
Parameters
lpLibFileName
Pointer to a null-terminated string that names the executable module (either a .DLL or .EXE file). The name specified is the filename of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.DEF) file.
If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). If the string does not specify a path, the function uses a standard search strategy to find the file. See the Res for more information. Return Values
If the function succeeds, the return value is a handle to the module.If the function fails, the return value is NULL. To get extended error information, call GetLastError. Res
LoadLibrary can be used to map a DLL module and return a handle that can be used in GetProcAddress to get the address of a DLL function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .EXE file to get a handle that can be used inFindResource orLoadResource. Do not use LoadLibrary to "run" a .EXE file. If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If the DLL's entry-point function does not return TRUE, LoadLibrary fails and returns NULL. It is not safe to call LoadLibrary from DllMain. For more information, see the Res section in DllMain. Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use — for example, in calling GetProcAddress. The other process must make its own call to LoadLibrary for the module before calling GetProcAddress. If no filename extension is specified in the lpLibFileName parameter, the default library extension .DLL is appended. However, the filename string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence: The directory from which the application loaded.
The current directory.
Windows 95 and Windows 98: The Windows system directory. Use theGetSystemDirectory function to get the path of this directory.
Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
The Windows directory. Use theGetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.
The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary or LoadLibraryEx. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread). Windows 95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. Windows CE: Two different modules cannot have the same filename, given that the extensions are different. These effectively have the same "module" name. For example, if LoadLibrary is made on "Sample.cpl", the operating system will not load Sample.cpl, but instead will again load Sample.dll. A similar limitation exists for modules with the same name but residing in different directories. For example, if LoadLibrary is called on "\\Windows\Sample.dll", and then LoadLibrary is called on "\\MyDir\Sample.dll", "\\Windows\Sample.dll" will simply be reloaded.A search path to the executable module cannot be specified. Unless the full path to the module is given, Windows CE will search the following path for the module: The root directory of the PC Card RAM expansion card, if one exists.
The windows directory (\Windows).
The root directory (\).
QuickInfo
Windows NT: Requires version 3.1 or later.
Windows: Requires Windows 95 or later.
Windows CE: Requires version 1.0 or later.
Header: Declared in winbase.h.
Import Library: Use kernel32.lib.
Unicode: Implemented as Unicode and ANSI versions on Windows NT.See Also
Dynamic-Link Libraries Overview, Dynamic-Link Library Functions, DllMain,FindResource, FreeLibrary, GetProcAddress,GetSystemDirectory,GetWindowsDirectory, LoadLibraryEx,LoadResource