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.
Related
I've been building a library to interact with one of my databases at work and everything is working fine. But when I open a new script and begin to use the library, it always freaks out when I try to use query expressions on the database. They work when I send them to F# interactive but the intellisense fails, drawing red lines under everything. Why is this? I would like my own dll to be the only thing a user would need to reference for a script.
System.Data.Linq is a reference in my dll file and I've set its Copy Local property to True to no avail. Other than that I haven't the faintest clue of what could be wrong.
What you're showing in the screenshot is evidently an F# script (an .fsx file). Since the code that tries to access the table is in the script file, it is the script file that needs a reference to System.Data.Linq. The fact that your AIXSupport.dll library has the reference does not help: references do not "transfer" like that.
Simply add this one at the beginning of the script:
#r "System.Data.Linq"
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 have a vb6 program that needs to use MSOLAP80.dll to display its pivot tables properly. But because MSOLAP90.dll has some compatibility issues with this I cannot use MSOLAP90.dll and still have the pivot tables display.
I have registered MSOLAP90.dll and then registered MSOLAP80.dll again and everything seems to be fine. I however don't know if both are actually registered or if MSOLAP80.dll is the only one registered, because I have no reference point as to what is new in MSOLAP90.dll. Is it possible that both are registered and the program is just using MSOLAP80.dll and if there are programs that need MSOLAP90.dll then it will know to use that one?
I guess I am just confused about how registering DLL's work and if it is possible to have both of these registered at the same time. Can somebody help with an explanation?
If you want to know for sure which one is registered, you can:
Look at the References dialogue for a type library which matches your DLLs' paths.
Open up RegEdit, and search for MSOLAP80.DLL or MSOLAP90.DLL (uncheck "Match whole string only").
If you find references for both DLLs, then you are safe because you can bind to a specific version. If you find a reference to the wrong DLL, then unregister the wrong one, and register the right one.
COM originall only allowed one version of a set of CLSIDs (which uniquely identify classes), IIDs (which uniquely identify classes' interfaces) at any one time. It is possible to have more than one reference to a LIBID (which identifies a type library - a resource embedded in the DLLL) but they have to have different versions.
From Windows XP onwards, it became possible to do side by side DLL access in which an executable can access a specific version of a DLL, overriding the value in the registry. You need to embed or have a .manifest file in the same folder as the EXE file.
Unfortunately, the documentation for this seems to have disappeared from MSDN, and is only referred to by a couple of Knowledge Base articles:
http://support.microsoft.com/kb/828629
http://support.microsoft.com/kb/843524
I'm trying to create an D application which uses a (third party) COM .dll so I can scrape a text box of another application so I can sound an error when a certain string shows up.
However the third party doesn't provide .lib, .def or .h files that go with the dll (atleast with the free trial version). I can create the .lib file with the implib tool but I don't see any of the library's functions in the created .lib.
Their (visual c++) samples use the #import directive to link it in however that is of no use for me ...
On a side note how can I get the proper interfaces (in a .di with boilerplate that does the linking) of the dll automatically? I ask so the correctness of the linkage doesn't depend on my (likely to be incorrect) translation of the functions. They do have a webpage which gives all functions but the object model is a bit chaotic to say the least.
From what I know, COM libraries only expose a few functions, required to (un)register the library and to create objects.
You can however view the interfaces and functions in a COM .dll using the OLE/COM Object Viewer. It seems it might be able to output header files (.h). Afterwards, maybe you could use htod as a starting point to converting everything to D interfaces.
The DMD distribution seems to include a .COM sample (chello.d, dclient.d, dserver.d), and at first glance it doesn't look like it would require any LIBs explicitly.
Unfortunately, I've never actually used COM in D, so I can't advise any further. I hope this helps in some way.
While I have yet to actually do COM work myself, I am trying to revive Juno over on Github/he-the-great. Part of the project is tlbimpd which is what will output a D file from a DLL.
I've tested the examples and successfully run tlbimpd. Please do try things out for your use and submit any issues.
I disassemled a game's DLL and want to insert some code.
I need asm code to call another DLL in the current directory(I'm on Windows).
The background is, that I want to be able to execute custom code in my DLL,
but I can't load the DLL. So my idea was to load the DLL via modified game DLL.
There may be a function in the game which gives me the current directory path the DLL's are but I think I won't find it.
The calls you are looking for are LoadLibrary, which will search in a selection of places including the current directory for the DLL and then load it, then GetProcAddress.
If the DLL makes any other Win32 calls it is probably already linked against kernel32.dll, so that's all you need to do.
It is arguable as to whether modifying the DLL or using DLL injection is faster in terms of how long it takes to write the code since you're going to have to reverse engineer anyway, however, one advantage of pure DLL injection is that all existing code remains unmodified in terms of the installation, making these modifications easier to undo should the user wish to "unpatch" whatever you are doing.
Microsoft Detours comes with setdll.exe and withdll.exe, those utilities will let you start an exe with a custom dll file.