What static library should I use to link against to use the NormalizeString() function?
In contrast with most functions documented on MSDN, the static library required to use the function is not declared. I tried using the name derived from the DLL: normaliz.lib and it successfully linked, but then I get a pop-up at runtime saying Normalization.dll could not be found on my computer and the process is shut down.
As pointer out by Hans Passant, the correct import library is normaliz.lib. It seems there was some problem in my setup.
I was using Windows SDK v6.0A. After switching to Windows SDK v7.0A, my problems stopped.
The link at the bottom-ish of the page you linked states that the download contains implib and dll resources. You probably have to manifest the dll, or at least put it into PATH.
Related
I'm trying to load GetStagedPackageOrigin WinAPI dynamically using LoadLibrary and GetProcAddress so that my app could also run on Windows 7. So according to documentation that API is supposed to be imported from Kernel32.dll, but in reality (in my Windows 10 v1709) it is not.
I was able to find it in Kernelbase.dll instead:
So I'm wondering, can I dynamically load it from Kernelbase.dll instead?
this definitely bug in documentation. if we call (test on win10)
GetProcAddress(GetModuleHandle(L"kernel32"), "GetStagedPackageOrigin");
we got 0 - this mean that this api not exported or forwarded from kernel32.dll
but if call
GetProcAddress(GetModuleHandle(L"kernelbase"), "GetStagedPackageOrigin");
we got it real address.
next - when I search in latest sdk libs - I not found GetStagedPackageOrigin in kernel32.lib too. only one lib containing this symbol - OneCoreUap.lib umbrella library - and marked it exported from api-ms-win-appmodel-runtime-l1-1-1.dll .this dll resolved in runtime to kernel.appcore.dll. implementation - simply jump to kernelbase.GetStagedPackageOrigin
so most correct I think try import this api from api-ms-win-appmodel-runtime-l1-1-1.dll
very strange appraisal for my look :) with so simply question
anybody can easy test this simply code on win8.1, win10
GetProcAddress(LoadLibrary(L"kernel32"), "GetStagedPackageOrigin");//fail
GetProcAddress(LoadLibrary(L"kernelbase"), "GetStagedPackageOrigin");//ok
GetProcAddress(LoadLibrary(L"kernel.appcore.dll"), "GetStagedPackageOrigin");//ok
GetProcAddress(LoadLibrary(L"api-ms-win-appmodel-runtime-l1-1-1"), "GetStagedPackageOrigin");//ok
and view that by fact GetStagedPackageOrigin not exported from kernel32.dll. this is simply fact.
about lib file - i have no win8.1 sdk under hand, but i search this api in 10.x sdk version through lib files - and i found that this api implemented only in OneCoreUap.lib (not this symbol in kernel32.lib). and OneCoreUap.lib say that this api ix exported by api-ms-win-appmodel-runtime-l1-1-1.dll. so if we link with this lib - we by fact will be try import this api with api-ms-win-appmodel-runtime-l1-1-1.dll (this name will be hardcoded in our pe file). so we need or link with OneCoreUap.lib (i advice add it at the end of lib list) or direct call GetProcAddress(LoadLibrary(L"api-ms-win-appmodel-runtime-l1-1-1"), "GetStagedPackageOrigin");.
and can note that which header files use - absolute not related to question at all. if somebody not agree with this - can i ask - which lib need use - please concrete answer. and from which dll - please concrete dll name application will be use when use this lib (this dll name will be hardcoded in pe import table)
I would certainly not bind it to the versioned api-ms-win-appmodel-runtime-l1-1-1.dll , but the two generic ones. kernelbase or kernel.appcore.
The versions are visual studio/ucrt version specific.
Using dependency walker I noticed some apps that definitely use Direct3D 11, but only link to Direct3D 9's library dll.
Do I gain something by linking? Would there be any benefit in using LoadLibrary?
Why might I choose one method over the other?
As I think, if you link DLL statically to your application you will not be able to even start the application if any DLL is missing. In case of manual LoadLibrary the application can start, check DLL availability and write message to log, show a good error description to user or even use another DLL set, e.g. another version of DLLs with different names instead of newest ones.
I have a VB6 program which tries to run a DLL written in C#.
This DLL has a COM interface so I can create an object of a class in it with "CreateObject".
The problem is that it runs and works well when I run it from the VB6 IDE, but when I make an EXE and try to run it, it throws the exception:
"Automation error. The system cannot find the file specified (-2147024894)."
Why is it happening and how can i solve it?
Look at Project, References in the IDE and look which dll or ocx file belongs to the object you are referencing with CreateObject (the Object Manager might also help to find out).
This dll file must be available when the exe is compiled, too. Usually, you need to have it registered with regsvr32.exe.
A technique I use to figure issues of this type is to open the add reference dialog in Visual Basic 6. I scroll the list of available COM Libraries and see if the problem DLL is listed. If it is then CreateObject should work, you should be able to assign it do a variant variant and use late binding to access it's members.
In addition try temporally set a reference to the variable and instead of using CreateObject use the = New and see what error messages, if any, it gives you. Generally I found them to be more informative then the ones thrown by CreateObject.
Finally it would help if you post the reason why you are choosing to use CreateObject instead of setting of a reference. If the DLL is a known object that will be continually used by the program then a reference should be set and early binding generally used.
Finally it may be that the error is resulting from a dependency of the C# COM DLL not the DLL itself. If for example I was to take a Com Library and properly register it but it relies on the COM Library Widget2000 and it NOT registered then it will throw the automation error. Especially if you are testing the EXE in it's installed environment and not the environment in which you complied it.
For example suppose I have a CAD program written in VB6 and I have source tree that begins with MyCAD. THe exe is in MyCAD/MainEXE and the shape library is in MyCAD/ShapeLibrary. I run the IDE everything is fine. Then I make my setup and goto my test machine and install it and it error on the creation of shapelibrary.
The first thing I would do it check if MainEXE will run straight out of the MainEXE directory of my source tree. That test will eliminate whether it is a install issue or a quirk of the IDE vs complied version. Then I would look at the setup and see what not being registered. Also look at either the source for the C# library or the setup for the library and see what dependencies it needs. Since it a complied COM DLL you should be able to use a dependency walker tool to see what COM references it needs. Finally make sure the correct version of the .NET framework is installed.
If you are compiling the C# DLL on your test machine - make sure you have ticked the register for COM Interop setting. If you are not compiling on the same machine you need to run RegAsm with the /codebase option.
try compiling it as an installer and include the dll/com that you use in the compilation of the installer package so that the dll/com that you use will be include in the compilation of your exe.., and install it in the windows not just copy past it.
I have an application that uses the winInet classes - #include <afxinet.h> and the wininet.dll
I would like to statically link the WinInet function calls in my application as well as the dll, so I followed these steps. I then copied the wininet.dll into my project directory, as I read here.
Upon building I get the following error - wininet.dll : fatal error LNK1136: invalid or corrupt file
My first question is:
-Am I correctly doing what I think is statically linking function calls and the dll?
-If so, why is the dll corrupt with this setup, but works without these changes?
Any help is appreciated. Thank You.
"Static Linking" is the process of including the code in your application. By nature, a DLL is a dynamic link library and therefore no, including the DLL in the directory of your application is not static linking - it remains dynamic. The reason for placing it in the directory of the application is so that the application can find it without the need for install.
I don't suppose it is the DLL that is "corrupt" - I suspect you are attempting to static link the DLL into the application which cannot happen. You need instead to include the correct .lib file, whatever that is, in the additional libraries to link with and ensure that the lib file you link with is not the DLL exports package for wininet.dll
You shouldn't link directly against the DLL. Instead, link against the corresponding import library (should be Wininet.lib). The DLL still needs to be accessible to your application at runtime, of course. The .lib file is needed by the linker to setup proper linkage to the DLL.
Am I correctly doing what I think is statically linking function calls and the dll?
What you're doing is usually called dynamic linkage (more or less dynamic ..), but its (afaik) the only way to go for Windows System APIs. 'Static' linkage would embed the Wininet code directly into your executable, with no need for an external DLL.
When you link with a DLL, there is a corresponding LIB file to use to set up the correct linkage to the functions. For an example, if you are using a USER32.DLL and KERNEL32.DLL, it's corresponding LIBs that needs to be linked would be USER32.LIB and KERNEL32.LIB.
Sometimes it is not so obvious, you can double check by looking at the MSDN for the function in question, when you scroll down towards the bottom of that page it will tell you what library to link with, for an example, look at the Win32API's CreateProcess, as you look at the bottom of the page, it tells you what is the library to use, in this case it's KERNEL32.LIB.
You just referenced a DLL during the linker phase which the linker could not understand the DLL as it is already a compiled library and hence the linker complained that it was "corrupt".
Change that to WinInet.LIB and all should be ok.
Hope this helps,
Best regards,
Tom.
Which headers should I not use if I don't want my program to be linked with any of msvc*.dll ?
At the moment my application uses:
kernel32
user32
shell32
msvcp90
msvcr90
I want to get rid of the bottom two files. I don't mind if I will have to rewrite certain aspects of the program.
Because I know if you code in C and then link it won't link any msvc's
I believe you have to change the way the CRT is linked into your program. I think for that you have to change the C++->Code Generation->Runtime-Library to the static version. This is for Visual Studio 2005, don't know about newer versions.
Those libraries contain the C++ runtime - heap management and other stuff hard to get rid from.
You could link the C++ statically instead - use "C++ -> Code Generation -> Runtime Library" setting. Then you will not need those .dll files. However this is not the recommended way - if a vulnerability is found in the C++ runtime you'll have to recompile and reship your program.
Static link is the right answer. A related bit of advice is to use depends.exe to see what functions your exe is actually hitting in the dependent dlls. Those dependencies might be due to explicit use on your part or due to CRT implementation that you don't explicitly invoke.