OSDev.org

.

bontanu wrote:The DLL "import libs" contain information about the function names and parameters/calling conventions for the functions inside an DLL but they do not contain any kind of code other than a small stub for a jump to IAT.

Well, no. Just function names and what looks like ordinal numbers (even though they are all off by exactly two), the rest is just blanks:

IF you would have LOOKED you would have noticed that the import LIB contains 2 symbols for each function. One of them refers to the E8 xx xx xx xx smaller call to an intermediate table that contains the JMP [IAT.Dll.FUnction] aka FF 25 xx xx xx xx. This one is "more indirect but smaller because E8 xx xx xx xx is only 5 bytes and this adds when you call many APIs from an DLL.

I did, and as shown above, only the jmp [relocation] exists. There's no second object containing your apparent function either.

Point was, if you have the .lib file, you have the .dll file. (That holds for crosscompiling as well since mingw and co use .a files, and you will want GNU because VS doesn't run too wel outside its native habitat). And all the other advantages of .lib files are nullified if you mix versions anyway: now you need to make sure that both the .dll, .lib and .h match, while you could only need the .dll and .h to match. And if you do enable mangling in DLLs, the linker can still give your errors when you do something stupid. Just that MS doesn't do it doesn't mean everybody shouldn't do it.

I did, and as shown above, only the jmp [relocation] exists. There's no second object containing your apparent function either.

No, he is referring to how those symbols are called. For the function CancelDC, there is a symbol _CancelDC@4, which is used as a direct call target, and a symbol __imp__CancelDC@4, which is used as an indirect target. The first symbol resides in an object module, which contains an indirect call to the second symbol. The second symbol is not defined in an object module, but in something called an AR import header. This maps the linker symbol __imp__CancelDC@4 to the the exported entry CancelDC from gdi32.dll. In the final executable, __imp__CancelDC@4 refers to an entry in the Import Address Table, which is filled in by Windows as the executable is being loaded.

If you only have the DLL file, you have no way of knowing which symbols correspond to which exported entries. The CancelDC function could have been exported as CancelDC, _CancelDC@4, HaltAndCatchFire, or with no name at all (only an ordinal).

The import library you are looking at is incorrect or designed for a different compiler. CancelDC appears to have been defined as cdecl instead of __stdcall, as it is missing the parameter count.

As for header files: It would be overkill to have the linker try to parse C header files to figure out what calling conventions are used. The source might not even have been written in C.

It is Visual Studio's original gdi32.lib, and it works as intended - I even used it last week despite my averse against MS crap.

As for header files: It would be overkill to have the linker try to parse C header files to figure out what calling conventions are used. The source might not even have been written in C.

Nonsense. That's what name mangling is for: the compiler gives the linker the function signature on a silver platter.

The rest of the argument (same goes for most previous posts) is basically about why MS' broken ABI makes things so complicated. If all exports were referenced by their mangled name, there's less DLL hell, less things to keep synchronized with another, and type safety for free. In case you wonder, a lib doesn't do that: if you change the .lib but don't update the dll, your code will link and then miserably fail. In fact the only thing that's enforced by this system is that the .lib matches the .h, and not that the final .dll used matches the .h

There is actually a "good" reason why DLLs export unmangled names: to make GetProcAddress work sanely. Of course, the side effects are arguably worse.

There would, of course, be obvious solutions to this:

• Export all symbols mangled. No need for import libraries; but GetProcAddress becomes awkward
• Don't mangle symbols, and instead annotate them with the calling convention information. This obviously would be the best of both worlds: parameter checking and GetProcAddress is sane
• Stick to one calling convention. You know, like everybody else does

The mess is particularly inexcusable on AMD64, where there is only one calling convention in use (on each platform).

However... whats done is done. MS platforms are stuck with what they have now.

bontanu wrote:.

I really dislike it when people delete the contents of their posts. I'm not certain about what I think I know about Windows dll/lib files but I am fairly certain as this mental model has helped me so far. I would have liked to know what the contents of your second post were...