dll memory limits
Author
Hi,
Just wandered to know what are the memory access limitations of using a dll in an exe. is the exe getting access to all dll memory and vice-versa ?
Thanks,
Amadrias
In Win32
DLLs and EXEs don''t have memory
Processes have memory address space - the executable code and the DLL are mapped into the same process address space.
The only thing to be concerned with is memory allocations - and making sure you use the appropriate dynamic version of the run time library for both your EXEs and DLLs it will ensure that memory allocations go through the same common code.
DLLs and EXEs don''t have memory
Processes have memory address space - the executable code and the DLL are mapped into the same process address space.
The only thing to be concerned with is memory allocations - and making sure you use the appropriate dynamic version of the run time library for both your EXEs and DLLs it will ensure that memory allocations go through the same common code.
Project ->
Settings... ->
C/C++ tab ->
Category=Code Generation ->
Use run-time library:
The different versions of the C runtime library you can select there have *different* implementations of functions like malloc(), free() and operators like new and delete.
For example if you allocate memory in a function in the DLL using malloc() from the "Single Threaded" library (e.g. say your DLL uses that version) and free() the memory in a function in the .EXE using free() from the "Debug Multithreaded DLL" (e.g. say your .EXE uses that), then you''d very likely get a crash of some form (access violation, damage error, blue screen etc)
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
Settings... ->
C/C++ tab ->
Category=Code Generation ->
Use run-time library:
The different versions of the C runtime library you can select there have *different* implementations of functions like malloc(), free() and operators like new and delete.
For example if you allocate memory in a function in the DLL using malloc() from the "Single Threaded" library (e.g. say your DLL uses that version) and free() the memory in a function in the .EXE using free() from the "Debug Multithreaded DLL" (e.g. say your .EXE uses that), then you''d very likely get a crash of some form (access violation, damage error, blue screen etc)
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
Just one more question, I think you simon will be able to answer :
Imagine that my dll (multithreaded) is wrapping some static libraries functions (single threaded) into organized C++ classes and calls. I then want to use this dll into a win32 exe (if I understand what you told me correctly, it should also be multithreaded in order to share the same memory allocations).
My question is : are all the functions in the static library ans also all the global data well managed ?...
Thanks,
Amadrias
Imagine that my dll (multithreaded) is wrapping some static libraries functions (single threaded) into organized C++ classes and calls. I then want to use this dll into a win32 exe (if I understand what you told me correctly, it should also be multithreaded in order to share the same memory allocations).
My question is : are all the functions in the static library ans also all the global data well managed ?...
Thanks,
Amadrias
A DLL runs in proces. What that means is that the DLL will run inside your application mem space. I don''t know of any limit, or it is so high that no one ever worries about it. Also, windows does not always keep all the code for a binary loaded.
-----------------------------
The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.
-----------------------------
The sad thing about artificial intelligence is that it lacks artifice and therefore intelligence.
static libraries are linked directly to the excutable file at link time. thus the static library becomes part of the excutable. thus if the same static library is used in multiple executable there will be multiple copies of the same code.
dynamic libraries are linked to executables at run-time. what happens is when a program is loaded by Windows it checks for import descriptor tables. there will be one for each ".dll" needed by the application. if the ".dll" is not loaded Windows will load the ".dll" into memory. the ".dll" will have a export descriptor table with the names of all the functions it exports. Windows will fill this export descriptor table will the "real" (virtual or physical, i don''t remember) memory addresses of each function. if the ".dll" has already been loaded then there is no need to do this. when Windows loads the application it will fill the import descriptor with the memory addresses from the ".dll" export descriptor table. Windows can then apply "address fix-ups" using this import descriptor table.
if another application requests the ".dll" upon load Windows will use the same export descriptor table values to fill the import descriptor table of this new application.
hope this clears this up a bit peace.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
dynamic libraries are linked to executables at run-time. what happens is when a program is loaded by Windows it checks for import descriptor tables. there will be one for each ".dll" needed by the application. if the ".dll" is not loaded Windows will load the ".dll" into memory. the ".dll" will have a export descriptor table with the names of all the functions it exports. Windows will fill this export descriptor table will the "real" (virtual or physical, i don''t remember) memory addresses of each function. if the ".dll" has already been loaded then there is no need to do this. when Windows loads the application it will fill the import descriptor with the memory addresses from the ".dll" export descriptor table. Windows can then apply "address fix-ups" using this import descriptor table.
if another application requests the ".dll" upon load Windows will use the same export descriptor table values to fill the import descriptor table of this new application.
hope this clears this up a bit peace.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
jenova - all you said was true, but I''m not sure if it was the question Amadrias was asking...
Amadrias - I''m not sure what your question about ''well managed'' means
but the gist of it is - if you link a static library into a dll the binary image for that static library is copied into the DLL - which is then loaded into the process address space by the OS.
This is a somewhat uncommon occurance, however, if you link that static libary in both the DLL *AND* the EXE then there are two copies of that static library image.
In this case you should use a dynamic version of that library such that only one version is used.
The reason is that if they two get ''out of sync'' eg you rebuild the DLL with a different version of the static library but don''t rebuild the EXE you may run into some unexpected behavior
The general rule of thumb is if you have a library that multiple DLLs or a DLL and an EXE must share access to, then that library should be a DLL - only in rare circumstances should it explicitly NOT be a shared library.
hope this helps
Amadrias - I''m not sure what your question about ''well managed'' means
but the gist of it is - if you link a static library into a dll the binary image for that static library is copied into the DLL - which is then loaded into the process address space by the OS.
This is a somewhat uncommon occurance, however, if you link that static libary in both the DLL *AND* the EXE then there are two copies of that static library image.
In this case you should use a dynamic version of that library such that only one version is used.
The reason is that if they two get ''out of sync'' eg you rebuild the DLL with a different version of the static library but don''t rebuild the EXE you may run into some unexpected behavior
The general rule of thumb is if you have a library that multiple DLLs or a DLL and an EXE must share access to, then that library should be a DLL - only in rare circumstances should it explicitly NOT be a shared library.
hope this helps
Author
thanks everyone, it helped me a lot.
SteveC, you were totally right about my question :
What I have is the following :
PowerRender 3d engine (www.powerrender.com) is composed of different static libraries. This engine was developped using C code which I do not like very much. I then decided to wrap PR into C++ classes.
In order to use this wrapper in different games I am working on, I decided to put all these wrapping classes into a dll, the win 32 exes will call.
My main problem is that when I used the wrapping classes within my win 32 exe, it all runs perfectly.
But when I do the same within a dll, it seems that PowerRender (so, the static libraires) do not initialize correctly and I have a global structure that stores all the important things, that is not filled by the initialization routines...
That''s why I post this question here...
I have to check one or two things about the win32 exe in order to know if it loads PR on it or only within the dll.
Thanks,
Amadrias
SteveC, you were totally right about my question :
What I have is the following :
PowerRender 3d engine (www.powerrender.com) is composed of different static libraries. This engine was developped using C code which I do not like very much. I then decided to wrap PR into C++ classes.
In order to use this wrapper in different games I am working on, I decided to put all these wrapping classes into a dll, the win 32 exes will call.
My main problem is that when I used the wrapping classes within my win 32 exe, it all runs perfectly.
But when I do the same within a dll, it seems that PowerRender (so, the static libraires) do not initialize correctly and I have a global structure that stores all the important things, that is not filled by the initialization routines...
That''s why I post this question here...
I have to check one or two things about the win32 exe in order to know if it loads PR on it or only within the dll.
Thanks,
Amadrias
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
