The Dx9 SDKs ddraw.lib is strange(to me). This is the exports from dumpbin:

Exports

ordinal name

_DDGetAttachedSurfaceLcl@12
_DDInternalLock@8
_DDInternalUnlock@4
_DSoundHelp@12
_DirectDrawCreate@12
_DirectDrawCreateClipper@12
_DirectDrawCreateEx@16
_DirectDrawEnumerateA@8
_DirectDrawEnumerateExA@12
_DirectDrawEnumerateExW@12
_DirectDrawEnumerateW@8
_GetDDSurfaceLocal@12
_GetSurfaceFromDC@12

Thats it. Older ones have full style __imp__DirectDrawCreate@12 and the above style.
Is there anything different/special about the above style?

I've been fooling around with making my own jump table for the windoes API:


.data
JTBL TEXTEQU <dw 025ffh>;indirect jump

__imp__ExitProcess@4:
JTBL
dd offset _imp__ExitProcess@4

__imp__GetModuleHandleA@4:
JTBL
dd offset _imp__GetModuleHandleA@4

__imp__GetMessageA@16:
JTBL
dd offset _imp__GetMessageA@16

I doing the above for a reason beyond the scope of this post. Lets just say it works great.

As I write this I decided to look at the disassem for a call to _DirectDrawCreate@12:


DirectDrawCreate:
00401180 FF 25 00 20 40 00 jmp dword ptr [__imp__DirectDrawCreate@12 (402000h)]

It seems it puts the jmp in my code section 0x401000, whereas the API jmp table starts from 0x403000. A different section alltogether. Its been a long time since I last used jmp tables. Is there any difference to the linker if you have:

_DirectDrawCreate@12

or

__imp__DirectDrawCreate@12

Assuming the symbols exist in the lib of course.

Thanks.
Posted on 2003-10-12 11:40:34 by ThoughtCriminal
The .LIB file created for C-style DLLs (such as the core API) contains both entries.

Kernel32.lib, for example, might contain the equivalent of:

    .code

_GetCommandLine@0:
jmp [__imp__GetCommandLine@0]

.data
__imp__GetCommandLine@0 DWORD ? ; To be filled by linker
There is a huge difference between the two names - one is code, the other is data.

The linker probably won't care, but your code will. You don't want to jump to data, and you don't want to treat code as data (indirect jumps specify a data address).
Posted on 2003-10-13 22:26:54 by tenkey