#### Archived

This topic is now archived and is closed to further replies.

# Entry-Point inside a DLL

This topic is 5572 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Sup? Does anybody know how... of it's possible... to have a program's entry point inside one of it's DLLs? For example, when making a Windows App, you use WinMain. This is the entry point that the windows libraries give you... the actual main function is buried deep within Windows DLLs. I'm trying to do the same thing with my engine. I want to put WinMain inside the engine DLL, and have a call from inside that DLL to a function such as UpdateGame() which will be the game's loop. Simplified Example... In the DLL:-
WinMain()
{
InitTheEngine();
while (1)
{
UpdateEngine();
UpdateGame();
}
} 
In the Game files:-
UpdateGame()
{
} 
Understand? :o/ I can add a WinMain function or DllMain function to my DLL okay, but unless the Exe has an entry point of it's own I get "LNK1561: entry point must be defined". Can I tell my App that the Entry-Point is in my DLL? NB: I'm using Windows .NET Hopefully there are some good brains out there! :D --- Ben Bradley Warning: May Contain Traces of Nut [edited by - BBradley on June 18, 2003 6:52:13 PM]

##### Share on other sites
Truely... i think it is impossible because linker want WinMain or DllMain.
But did You try to create WinMain (DllMain) prototype in your code ?

[edited by - estor on June 18, 2003 7:06:49 PM]

##### Share on other sites
quote:
the actual main function is buried deep within Windows DLLs.

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

the default entry point set by the linker for non-console Window''s exes is WinMainCRTStartup. this is a function which is statically linked into the exe, not dynamically. this is the function that references WinMain.

quote:
Original post by Estor
Truely... i think it is impossible because linker want WinMain or DllMain.

this is also an incorrect statement. it''s not the linker that wants these entries, but rather the functions that the linker uses as default entry points that want these entries. if you override the default entry point thend these functions are no longer required.

so, can this be done? yes and yes, but.

it''s no problem to stick a WinMain into a dll and have that function called as the entry point to the app. the problem is how then do you get to the app? from my experience with this there is no way (that i could come up with anyway) to get a valid address for the exe''s function that you wanted to use as an entry point. there was nothing i could do at compile and/or link-time to specify an exe entry point within the dll. 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.

ultimately what i ended up doing was hardcoding the address of the exe''s entry point as specified by its linker .map output flie (from the Rva+Base column for the function that i was using as the entry point), into the dll as a FARPROC. calling that FARPROC then allowed entry into the exe and everything behaved as normal from there; i could even run through both the dll and the exe''s execution using the debugger. the only other problem i ran into was that the hInstance passed into the dll''s WinMain was in fact the base address of the exe''s image, not the dlls. but calling GetModuleHandle for the dll''s filename retrieved the correct address.

so, if you can come up with some way to not have to hardcode the exe entry point''s address, i''d love to hear about it. but, long story short, yes it''s doable.

##### Share on other sites
blah, all that and i forgot to tell you how to make the WinMain in the dll usable.

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.

##### Share on other sites
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 (assuming you allow mods to be created) are a dll and to use them you run the standard game EXE (so you won''t need a seperate shortcut for each game etc cuz the exe can dynamically reload whatever DLL you want to play)

##### Share on other sites
quote:

the default entry point set by the linker for non-console Window''s exes is WinMainCRTStartup. this is a function which is statically linked into the exe, not dynamically. this is the function that references WinMain.

Actually, it is part of the runtime, so if you link the runtime statically, it''s statically linked, if you use (for example) the multithreaded runtime DLL, it''s a DLL...

quote:

this is also an incorrect statement. it''s not the linker that wants these entries, but rather the functions that the linker uses as default entry points that want these entries. if you override the default entry point thend these functions are no longer required.

Well, the linker wants mainCRTStartup or other, which is specified by (iirc) the /ENTRY linker flag. You can define them yourself, but since they do quite few things (most likely compiler dependent, but for VC++ for example it does call global variable constructors, set up the heap, etc) you''d have to basically copy everything to get the same as a normal environment... which is not required in order to make a working app (you are not forced to link with the runtime either). Also, the source of those CRT entry points comes with VC++, just like the other parts of the runtime (it''s in crt0.c or something like that, as far as I remember).

##### Share on other sites
quote:
Original post by mputters
Actually, it is part of the runtime, so if you link the runtime statically, it''s statically linked, if you use (for example) the multithreaded runtime DLL, it''s a DLL...

uhmm, sorry, but i disagree. if you look at a linker map i think you will find that the entry point is in crtexew.obj and is always statically linked. this is further verified by using Dependency Walker to see what references are unresolved. i don''t believe _WinMainCRTStartup will be in the msvcrt.dll list.
quote:

Well, the linker wants mainCRTStartup or other, which is specified by (iirc) the /ENTRY linker flag. You can define them yourself, but since they do quite few things (most likely compiler dependent, but for VC++ for example it does call global variable constructors, set up the heap, etc) you''d have to basically copy everything to get the same as a normal environment... which is not required in order to make a working app (you are not forced to link with the runtime either). Also, the source of those CRT entry points comes with VC++, just like the other parts of the runtime (it''s in crt0.c or something like that, as far as I remember).

i''m sorry, was there a point in there? it''s early so i probably missed it.

##### Share on other sites
I''m in a cafe and don''t have VC++ on this laptop, so can''t check ;p (and no, I won''t bother downloading dependency walker). As for the second part of the answer, 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).

##### Share on other sites
hi dalleboy. if you look at a linker map for any MFC app you''ll find that the exe contains WinMain. it comes from the mfc42 lib but it''s statically linked into the exe. this function then calls the AfxWinMain function which is in the mfc42.dll.

1. 1
2. 2
Rutin
21
3. 3
4. 4
frob
16
5. 5

• 9
• 12
• 9
• 33
• 13
• ### Forum Statistics

• Total Topics
632593
• Total Posts
3007271

×