Is it possible to have a DLL without a DLLMain function? What impact would that have, or does it render the DLL unusable?
Sure, it is possible to have a DLL without a DLLMain. But it won't be same as a normal DLL.
As an example, Resource DLLs do not need to have code.
In Visual Studio you can have the /NOENTRY option so the linker doesn't complain about missing references.
From all specification point of view, the file is a complete DLL.
Yes you can load a DLL library with resources only, for this purpose use LoadLibraryEx() with LOAD_LIBRARY_AS_IMAGE_RESOURCE.
Related
I have an executable that looks for a particular DLL. I have changed the source for DLL and recompiled it (written and recompiled in VB6). Once I replace the DLL, the executable hits a runtime error when it gets to using that particular DLL. Works ok when I recompile the executable.
So my question is, with same DLL path, same name, and virtually identical DLLs, why does the executable need to be recompiled?
This is driving me bananas so any thoughts would be appreciated. Thanks, Callum.
A VB6 (or any COM) DLL has unique IDs for itself and its public interfaces, if you recompile these can change and any existing code bound to the old IDs fails.
Tldr; Tick "Binary Compatibility" in the DLL's project options & select the old working DLL as the thing to maintain compatibility with & recompile.
Detailed explanation: I keep hearing about DLL hell - what is this?
I need to make some exe file to load my DLL at startup...
What is the easiest way to do it?
I need this exactly, no any injectors or starters.
I though about adding one more code section into exe, rewriting to there entry point logic and placing DLL loading code, then NOPing original entry point and calling my custom made entry point function. Will this work?
Are there any other easer ways?
I also thinking about changing one of system dll name in hex editor to name of my DLL. Will this work? If my dll then load that replaced system dll?
Any thoughts?
Adding it to the PE's import table should be enough. Woodman's lists a few tools which can do it:
http://www.woodmann.com/collaborative/tools/index.php/Category:Import_Editors
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.
I get the following exception when showing a form:
InvalidOperationException was unhandled
Mixed mode assembly is build against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
alt text http://img69.imageshack.us/img69/2599/captureya.png
Dont really know why this isnt working. Any help?
I haven't seen the code for LoginForm. But I think you need to set an app.config flag to fall back to .NET 2.0 era bindings...
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
First, what's a mixed mode assembly? A
mixed mode assembly is an assembly
that contains both managed (CIL) and
unmanaged (machine language) code.
Consequently, they are not portable to
other CPU instruction sets, just like
normal C and C++ programs and
libraries.
Next, why use them? The primary
purpose for mixed mode assemblies is
as "glue", to e.g. use a C++ library
class as a base class of a managed
class. This allows the managed class
to extend unmanaged methods, allowing
the managed code to be polymorphic
with respect to existing unmanaged
functions. This is extremely useful in
many contexts. However, as something
like this involves extending a C++
class, it requires that the compiler
know all about the C++ compiler ABI
(name mangling, virtual function table
generation and placement, exception
behavior), and thus effectively
requires native code. If the base
class is within a separate .dll, this
will also require that the mixed mode
assembly list the native .dll as a
dependency, so that the native library
is also loaded when the assembly is
loaded.
The other thing that mixed mode
assemblies support is the ability to
export new C functions so that other
programs can LoadLibrary() the
assembly and GetProcAddress the
exported C function.
Both of these capabilities require
that the shared library loader for the
platform support Portable Executable
(PE) files, as assemblies are PE
files. If the shared library loader
supports PE files, then the loader can
ensure that when the assembly is
loaded, all listed dependent libraries
are also loaded (case 1), or that
native apps will be able to load the
assembly as if it were a native DLL
and resolve DLL entry points against
it.
Source
I had this issue, tried the answer above and it did not work.
After much reading and trial and error and not finding anything that worked I noticed that I had both imported the Mysql dlls and added them in properties. After I removed the import statements it worked.
I know it was removing the import statements because I tested between every change I tried.
Hope that helps somebody.
I am getting error,
ActiveX component can't create object.
Actually I have VB6 DLLs where business logic resides and I am calling that DLL function in my VB.NET application, all DLLs are dependent on other DLLs. I am getting the error from one of the DLLs
Any ideas?
Usually that error points to a COM dll that is not registered. You need to look at the chain of calls and find out which COM components you need and make sure they are available. Process Monitor (from sysinternals) may help you find it when it reads from the registry and can't find it.
Four common causes are:
1. You do not have a required TLB or ActiveX DLL/OCX file
2. A TLB or ActiveX DLL/OCX needed by the project is present but not registered on your system
3. The VB runtimes are an earlier version than the one you need to run the project
4. A required TLB or ActiveX DLL/OCX file is corrupt
Do you have access to the troublesome DLL source code?
Also check permissions. The user account that the vb.net application is running under will need permissions to be able to create the vb6 dll
Process Monitor will definately help find the missing DLL, but frequently the task can be achieved more quickly with Dependency Walker.