Beyond creating a dll with all the same functions with the same interface and calling conventions, does the replacement dll need to exactly duplicate the export map including ordinal numbers of the original as well? So that not only explicit loading via GetProcAddress works, but implicit linking as well?
(edit: this is an unmanaged, c/c++ windows dll I'm talking about, not .net)
You will need to mimic every export that any other client is using, you don't need to mimic "dead" exports that no one is using. You need to keep the ordinals only if other clients are linked by using ordinal instead of export name (which is quite rare).
There a is something that you need to keep in mind: If the dll contains C++ classes and it is not using extern "C" then you need to maintain binary comparability, meaning the classes in the replacement dll needs to have the same fields in the same order as the original classes. If your using interfaces that you need to keep the vtable with the same arguments for each method.
Related
I have dumped a Windows SDK .lib file (kernel32.lib) with DUMPBIN, the output show me that there are two "versions" for every API name, for example:
_imp_ExitProcess#4
and
_ExitProcess#4
So, why there are two of the same with different name mangling? .
Let say i want to call ExitProcess from NASM, wich of them should i use when declare EXTERN?, mi practice shows me that i can call any of them but i don't know which one is the "correct" or the "prefered" to stick with it.
I think the _imp_ version is meant to be used with __declspec(dllimport) on Visual C++ compilers to prevent potential conflicts with code in the same module.
You're not supposed to use that fact explicitly in your code -- just use the original function, i.e. _ExitProcess#4.
I am wondering if extern "C" is a must or not?
Only if you want to call your code from C (or a different C++ compiler, which you should treat like C).
It is to disable name-mangling.
See this article on the C++ FAQ: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
No, you use extern "C" to provide a C-linkage to your C++ functions, so they won't be 'decorated' like normal C++ functions and to allow them to be called from C (or Objective-C).
Function decoration is used to implement the C++ function overloading feature and gives each variation of the function a different signature while allowing the developer to use the name he assigned.
Your C++ functions will be exported automatically by simply not using the static keyword. However if you have implemented your C++ functions within a Windows DLL it's necessary to use the declspec dllexport/dllimport keywords to access them externally.
Use of extern "C" switches off name mangling. If you don't do this you may make if hard for a client of your DLL to import your symbols.
Remember that different C++ compilers have different name mangling rules and so your mangled exported names may differ from the names used on import.
However, since it is wrong to import a class from a DLL if you are using a different compiler than that used for the DLL, this is rather a moot point.
So, if you are exporting classes (usually a bad idea anyway) it is easier to leave mangling on. Otherwise switch it off with extern "C".
Some inBuilt functions in Vba can be called with or without its class. Which one is better to use?
When calling a Sub/Function
vba.Format(date,"yy-MM-dd")
'or
Format(date,"yy-MM-dd")
Also when dimensioning a variable, the class might or might not be used. In this case, which would be better?
Dim xmlDoc As MSXML2.DOMDocument60
'or
Dim xmlDoc As DOMDocument60
I tend to use the class and name just in case someone has defined a function/Sub/type that could bring conflicts. But how about performance? When having a great amount of codes and procedures, could one or the other have an impact on performance/speed?
Is there any other aspect to take in account when deciding whether to use one form or the other?
If I am understanding you correctly, and if my understanding of VBA is correct, then it doesn't make much difference in terms of performance whether you qualify the property or method with the library prefix. I don't think it is necessary to qualify the objects referenced within the vba library (If you are indeed working in a vba environment, as opposed to say .net using interop), but when you set external references (such as MSXML2, or Scripting), it might be beneficial to fully qualify the function reference for clarity.
Using the fully qualified name can improve clarity (in some cases). A year down the road, when someone else goes to maintain your code, it can be helful for them to recognize that certain functions are defined in a referenced library (such as MSXML2). Also, in cases where the referenced library contains a function with the same name as either the vba library, or another library set as a reference, you will need to qualify the function name.
Fully qualifying function names from referenced libraries is probably good practice. While the vba library is ALSO set as a reference from within a vba application, my take would be that is the one library you DON'T need to qualify.
Note that using fully qualified names DOES mean some extra typing. Since you app is written in vba, using vba.Function would be semi-redundant. But for referenced libraries, you need to choose between clarity/maintainability, and ease of typing (I have subscribed to the school that says "write the code in a way that will benefit the next person who has to deal with it" before making it "easier" for myself to write.
I've been looking recently into creating a new native language. I understand the (very) basics of the PE format and I've grabbed an assembler with a fairly kind interface off the webs, which I've successfully used to implement some simple functions. But I've run into a problem using functions from a library. The only way that I've called library functions from a dynamically compiled function previously is to pass in the function pointer manually- something I can't do if I create PE files and execute them in their own process. Now, I'm not planning on using the CRT, but I will need access to the Win API to implement my own standard libraries. How do I generate a reference to a WinAPI function so that the PE loader will patch it up?
You need to write an import table. It's basically a list of function names that you wish to use in your application. It's pointed to by the PE header. The loader loads the DLL files into the process memory space for you, finds the requested function in their export table and leaves the address for it in the import table. You then usually dereference that and jmp there.
Check out Izelion's assembly tutorial for the full details and for asm examples.
How about starting by emitting C instead of assembly? Then writing directly to ASM is just an optimization.
I'm not being facetious: most compilers turn out some kind of intermediate code before the final native code pass.
I realize you're trying to get away from all the null-delmited rigmarole, but you'll need that for the WinAPI functions anyway.
Re-reading your question: you do realize that you can get the WinAPI function addresses by calling LoadLibrary(), then calling GetProcAddress(), and then setting up the call...right?
If you want to see how to bootstrap this from pure assembly: the old SDKs had ASM sample code, probably the new ones still do. If they don't, the DDK will.
What is the correct way to use GetProcAddress() on a 32 bit DLL? On win32, there are three calling conventions, cdecl, stdcall and fastcall. If the function in the DLL is foo they will decorate the name in the following ways _foo, _foo#N and #foo#N.
But if the author of the dll has used a .def file, then the exported name will be changed to just "foo" without any decoration.
This spells trouble for me because if I want to load foo from a dll that is using stdcall, should I use the decorated name:
void *h = LoadLibraryEx(L"foo.dll", NULL, 0);
GetProcAddres((HMODULE)h, L"_foo#16");
Or the undecorated one:
void *h = LoadLibraryEx(L"foo.dll", NULL, 0);
GetProcAddres((HMODULE)h, L"foo");
? Should I guess? I've looked at lots of 32 bit DLL files (stdcall and cdecl) and they all seem to export the undecorated name. But can you assume that is always the case?
There's really no shortcut or definitive rule here. You have to know the name of the function. The normal scenario is that you know at compile time the name of the function. In which case it does not matter whether the exported name is mangled, decorated, or indeed completely unrelated to the semantic name. Functions can be exported without names, by ordinal. Again, you need to know how the function was exported.
If you are presented with a header file for a library, and want to link to it with explicit linking (LoadLibrary/GetProcAddress) then you will need to find out the names of the function. Use a tool like dumpbin or Dependency Walker to do that.
Now, the other scenario which might lead to you asking the question is that you don't know the name at compile time. For instance, the name is provided by the user of your program in one way or another. Again, it is quite reasonable to require the user to know the exported name of the function.
Finally, you can parse the PE meta data for the executable file to enumerate its exported function. This will give you a list of exported function names, and exported function ordinals. This is what tools like dumpbin and Dependency Walker do.
If __declspec(dllexport) is used during compilation and __declspec(dllimport) in header file, as well as extern "c", then you do not need to decorate those functions. The __declspec helps in using the undecorated names, but function overloads, namespaces, and classes still require same way to distinguish them.
Usually, object oriented functions are exported using function ordinals instead of their decorated names. Cast the ordinal as (char*)(unsigned short)ordinal, thus, GetProcAddress(module, (char*)(unsigned short)ordinal);
Edit: while most of Windows use UTF-16, GetProcAddress uses UTF-8, so it cannot use a wide character string.
GetProcAddress(module, L"foo") is identical to GetProcAddress(module, "f");