Entry-Point inside a DLL

Started by
10 comments, last by BBradley 20 years, 10 months ago
Hallo.

First off this was my first post to this board, so I'm pretty chuffed with the level of attention. Thank you.

So, in order of appearance...

quote:i'm curious as to how you came about this piece of information? because i believe it is incorrect.


I read it in "Advanced 3D Game Programming in Direct X 8.0" Page 9. :o) Won't argue on where the entry point actually is, cos I don't know (I always thought WinMainCRTStartup was called by the hidden main... :o/ ).

quote:the problem is how then do you get to the app?


I plan to cross that bridge when I come to it! :o/

quote:ultimately what i ended up doing was hardcoding the address of the exe's entry point as specified by its linker .map output flie


Correct me here if I am wrong, but wouldn't this mean that the DLL would need to be rebuilt for each EXE. Unless of course, each EXE's entry point is the same place every time, but this I assume this isn't the case, (especially since the EXE entry point isn't a "real" entry point). If this was the case it would defeat my purpose, and so like you say I would have to find 'some way to not have to hardcode the exe entry point's address'. But I am not at that stage yet....

quote:all you do is add the dll's lib as part of the exe's object/library module's list. you also need to make sure that the dll's WinMain function is exported so that the loader can resolve the address at runtime.


This was my initial thought but it refuses to work. If I use __declspec(ddlexport) before Winmain it tells me
C2375: 'WinMain' : redefinition; different linkage. Using a DEF file compiles and links without a blip, but it won't run say the file is not a valid Win32 application. Any ideas where I might be fluffing up?

quote:It seems more logical to make the engine itself the exe and make the game specific code the DLL, much like was done in half-life and I believe several other FPS. That way any mods...


I gave this some thought, but my engine is somewhere between being an actual engine and a set of utilities - although it would make sense to, you won't have to use every part of the engine if you want to do some things your own way. In it's reuse I expect it to be used to make complete new games rather than mods.

quote:it was to clarify on the reason why there are those CRT functions and what they do, in case he might want to write his own (in his DLL, for example).


It's an idea, but I wouldn't go that far. :o) This problem isn't life or death for my project. At the moment I have a Winmain function in my EXE which simply passes Winmain's arguments, and a pointer to UpdateGame() to the DLL, and the DLL takes over. Since that Winmain function is doing very little I thought it might be possible to remove it. This would tidy up the engine user's interface.



[edited by - BBradley on June 19, 2003 4:16:40 PM]
__________________Ben Bradley
Advertisement
quote:conversely, there was nothing i could "legitimately" do to get the exe''s entry point at runtime. by legitimately i mean via some sort of normal way such as calling GetModuleHandle to retrieve the base address for the exe''s image followed by calling GetProcAddress to retrieve the offset from that base address to the exe''s entry point.

No problem - you can read the PE header:
base = GetModuleHandle (= 0x400000)
PE header = base + (u32 at base + 0x3c)
entry point = base + (u32 at PE header + 24 + 16)
or use ImageNtHeader.
E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3

This topic is closed to new replies.

Advertisement