The interesting question a while back [WayBack] The Initialization-Block of a unit that is part of a package. Is it run as part of DLLMain? – Alexander Benikowski – Google+ has a simple TL;DR answer: “it depends” on the actual usage of those units.
Way more elaborate, as I dislike language stuff that you need to track down by trial and error what is actually used:
Well, seems so(in our case). Rootcall which triggers the initialization is:
ntdll.ldrLoadDLL
I did not mention, that the BPL is used by a DLL(DLL links against package) which means the package is loaded/initialized by the Os when theDLLMainruns. Odd combination but that seems to be the culprit here.David Heffernan
Yes, it is triggered fromDllMain. And yes, this has massive consequences for what can and cannot be done in initialization sections.Alexander Benikowski
+David Heffernan in my case. When a packages unit is already initialized by being used from an Exe(which links to the Package), it is not from within aDLLMain.
In my case, both the Application and the dll it loads, both link to the same package. But the unit in question is unused until the DLL is loaded.Uwe Raabe
The docs forInitializePackagesay it calls theinitializationparts of all contained units in the package – not only the used ones.David Heffernan
+Alexander Benikowski In that scenario we have load time linking and I guess the package framework handles it differently.David Millington
Related: don’t forget thatclassconstructors anddestructors effectively run in theinitializationandfinalizationsections too. Restrictions or side effects apply there too. docwiki.embarcadero.com – Methods (Delphi) – RAD StudioStefan Glienke
+Uwe Raabe Which is not being done when you use it as runtime package. Only initialization sections from unit being used are being run. This caused us several problems in the past where 2 modules (A being the host application exe and B being some DLL that gets loaded at a later point via LoadLibrary) were using a runtime package but only B used a particular unit from the package which caused the initialization code for that unit being executed when B was loaded and hence being executed in the context of thedllmainof B.The usual solution is then to put those units into some dummy unit forcing the initialization of that unit to be run in A.
Another solution according to your statement could be to call
InitializePackageon all the used runtime packages – and there the question is: couldn’t the RTL do that somehow?+Stefan Glienke I am not sure if that is desirable when done unconditionally. Even when compiled with packages I wouldn’t expect units to be initialized which aren’t actually used. That would perhaps change the behavior of the application depending on whether it is compile with runtime packages or without.
The case is different with dynamic loaded packages. The units in there are obviously not directly used in the first place. As no one can know which units of such a package are used or not, initializing all of them seems like a viable decision.
Of course there will be situations where your proposed behavior might come in handy, but I doubt that this will be a fit for all.
Source: The Initialization-Block of a unit that is part of a package. Is it run as pa…
Related:
- [WayBack] Delphi 2007: SysUtils.InitializePackage Function
- [WayBack] Delphi 2007: SysUtils.LoadPackage Function
- [Archive.is] Methods – RAD Studio 2010: Class Constructors (they were introduced in Delphi 2010)
- [WayBack] Don’t use standard library/CRT functions in static initializers/DllMain! – Aymeric on Software
- [WayBack] c++ – Is it ok to wait in DllMain (PROCESS_DETATCH) as long as its not forever? – Stack Overflow
- [WayBack] c++ – Usage limitations during the DllMain Attach and Detach process – Stack Overflow
- [WayBack] Application deadlock while calling a CAPI function within DllMain – Windows SDK Support Team Blog
- WayBack: Deadlock Detection on lock hierarchies
- [WayBack] Some reasons not to do anything scary in your DllMain – The Old New Thing
- [WayBack] Another reason not to do anything scary in your DllMain: Inadvertent deadlock – The Old New Thing
- [WayBack] Does creating a thread from DllMain deadlock or doesn’t it? – The Old New Thing
- [WayBack] A process shutdown puzzle – The Old New Thing
- [WayBack] The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification – The Old New Thing
- [WayBack] How you might be loading a DLL during DLL_PROCESS_DETACH without even realizing it – The Old New Thing
- [WayBack] When DLL_PROCESS_DETACH tells you that the process is exiting, your best bet is just to return without doing anything – The Old New Thing
- [WayBack] If only DLLs can get DllMain notifications, how can an EXE receive a notification when a thread is created (for example)? – The Old New Thing
- [WayBack] Some reasons not to do anything scary in your DllMain, part 3 – The Old New Thing
- [WayBack] What is this inconsistent heap state that MSDN warns me about during DLL_PROCESS_DETACH? – The Old New Thing
- Windows Vista/7/8/… hangs for Windows Common dialogs when your COM initialisation is wrong
- Solution for “Why do I get a ‘LoaderLock’ Error when debugging my Managed DirectX application” (The ZBuffer)
–jeroen
The Wiert Corner - irregular stream of stuff 