How can I explicitly link to a .sys file on windows? MSDN says you can use the LoadLibrary() and the GetProcAddress() functions to basically explicitly link and access members of a dll. I can successfully use this to at least get a handle for an associated dll however when I try them with a .lib or a .sys they do not work or they return null. I can understand that it would not work with .lib maybe (even though it says library in the name) but I had read that .sys files were usually dlls.
if (0 == LoadLibraryA("videoprt.sys"))
{
printf("goodbye");
}
This will compile but the address returned will be zero for the .sys file, if I use a more typical windows dll it does not return zero. How do I link a .sys file so that I can access exported functions?
Related
When I register COM dll by running regsvr32 MyCOMdll.dll in CMD I see several entries created in registry, one of them is:
[HKEY_CLASSES_ROOT\MyCOMdll.MyClass\Clsid]
#="{DB402D5A-5584-4F68-A750-45D3E8133121}"
I'd like to understand where DB402D5A-5584-4F68-A750-45D3E8133121 comes from, initially I thought that GUID generated at point when you register this DLL, however I checked this at different environments and I see it has same value. It looks like these GUIDs are embedded into DLL, but I cannot confirm or find out at which point.
Context: I want to perform a "hot swap" of that COM, however it doesn't seem to be straightforward. I tried to update GUIDs in registry after I register new DLL, but getting error ClassFactory cannot supply requested class.
When you register a COM dll using regsvr32, CLSIDs are defined inside the dll.
In typical ATL COM project, these entries are specified in *.rgs files, and registry is updated based on that content. Of course, this is not the only way to do it and other toolsets and technologies do it in different way.
These CLSIDs are actually defined in the .idl file of the project (again, this is valid for ATL projects), and .rgs file must correctly match the values. The .idl file itself contains IDL definitions of all COM types in the library, and is used by MIDL compiler to generate the type library.
I'm trying to interact with a .dll which will allow me to receive information from a variety of devices (Eye Gaze to be specific). The .dll is called ETUDriver and can be found at http://www.sis.uta.fi/~csolsp/projects.php however it does not come with an accompanying .h file.
I am struggling to actually load, interact and invoke functions from the .dll. A manual is supplied but it is of no help whatsoever with regards to actually setting up the code to start it off. There are three accompanying example apps (with source code) but only two of these work and one of which is in C# so is not helpful. The one that works however loads up the .dll via MFC and this is not a viable option with my code (which is intended to be used with many other projects and as such can't enforce MFC or any other libraries that are not as standard to projects).
Essentially, within the .dll is a series of classes which I need to create within my code and invoke the relevant functions of that class.
I've tried to use HRESULT hr = CoInitialize(NULL);
hr = CoCreateInstance(__uuidof(ETUDSink), NULL, CLSCTX_INPROC, __uuidof(IETUDSink), (LPVOID*)&pETUDSink);
if(pETUDSink)
{
pETUDSink->Start();
} however it always returns an error saying that the class is not registered. I can't use MFC to call the relevant .rgs file and am completely stuck on how to get this to work otherwise.
Is there a given format to doing this that I am unaware of and has anyone had experience in using the ETUDriver (or is able to get it working in C++ without use of MFC)?
Thank you for any help you can provide on this subject :)
I am not familiar with the specific DLL in question, but it sounds like you did not register the DLL on the target machine. You can do this by running regsvr32.exe or by calling the DLL's exported DllRegisterServer function or by using side-by-side assemblies. You need to do register the DLL on each machine that needs to leverage the COM functionality within it, so when you distribute your application, make sure that your installer registers the DLL if you go the regsvr32.exe route.
You can use the #import directive in Microsoft Visual C++ to load the information contained within the DLL without using a header file or rewriting it yourself based on documentation.
I am trying to load a dll (it's not my dll) and it's written in C++
There are no exports to my knowledge, but it does what I need it to do once loaded.
assert(package.loadlib(dllfile,'')()
This throws an error, obv, "procedure not found" but the dll is still loaded, and works as intended.
if I call the above function a 2nd time, it crashes the client, so I need a checker of some sort.
my question is, is there a way to verify it's loaded?
In Lua 5.1 when using package.loadlib as the second argument you must specify the name of a function actually exported by the DLL. It is not important which, if you only need to force the Windows dynamic linker to load the DLL (that seems your case).
To discover such names you can use DependencyWalker (free tool). Open the DLL using depend.exe and look at the export function list panel (the first column has an E header label). Choose any function and use its name as the second argument (If it really doesn't have exported functions you are out of luck!). Try to choose a function labeled as C (not C++). C++ exported functions have mangled names that could cause problems.
For example, say you want to load kernel32.dll: using depend.exe you can discover that among all the exported functions there is one named AddAtomA (but any other C function would do). So you could use package.loadlib in this way:
assert( package.loadlib( "kernel32.dll", "AddAtomA" ) )
The assert call ensures that if the DLL cannot be loaded an error is issued.
To verify a DLL is actually loaded you can use ProcessExplorer (another free tool).
Make sure your script is running (you can put an io.read() statement in a suitable place to keep your script from terminating),
then open ProcessExplorer window,
select the process relative to your script (probably some lua.exe, but you can drag the "target" tool on ProcessExplorer toolbar to your script window to discover it)
and type ctrl-D.
A lower panel should appear showing all the DLLs that the selected process is using. Browse the list to see if your DLL is listed.
Hope this helps.
What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.
I built few open source binary/libraries and found that the binary/library is dependent on other libraries statically.I want it to link dynamically. This would allow my binaries be moved to any location and will be path independent. I mean if i export the Library path the binary should be able to locate the library and run successfully.
Write an interface header file containing signature declarations of all functions from required dependent libraries. Include it in your code.
Depending on requirement, use a platform specific loadlibrary function to load it, and then use getprocaddress like function to get the address of required function.
Use those addresses to invoke that function thereafter from your code
While compiling and linking make sure you dont statically link those dependent libraries.