Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: XE8 Enterprise, #pragma startup weirdness



Permlink Replies: 3 - Last Post: Jul 23, 2017 11:42 PM Last Post By: Jan Dijkstra
Jan Dijkstra

Posts: 206
Registered: 11/4/99
XE8 Enterprise, #pragma startup weirdness
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 20, 2017 5:46 AM
I have made four packages. In three of these, I have an initialisation routine that I want to start using #pragma startup. The trouble is, only one of these #pragma startup instructions is working reliably.

The one in my first package (which allocates internal storage space and exports a bunch of manipulation routines) works as you would expect. It gets called, and does it's startup initialisation.

The one in my second and third package calls into the manipulation routines as exported by the first package. But here, the #pragma startup is not working. So I added a dummy function (which does nothing of interest) and call this dummy from the design time registration routine.

That makes it work .. in the IDE. When I generate an executable (using runtime packages for all of these), the #pragma startup in the first package is still executed as expected, but the one in the second package doesn't get called. So I move the call to the dummy function to the package/dll initialisation routine _libmain, and call it when reason == DLL_PROCESS_ATTACH, and remove the calls from the design time package registration routine. Again, it works in the IDE. But it still will not work for an application that's using this second package.

The _libmain routine in the second and third package gets called when my application starts, but the #pragma startup routine still will not execute.

What's going on here, and what must I do in order to get #pragma startup to work correctly ?
Jan Dijkstra

Posts: 206
Registered: 11/4/99
Re: XE8 Enterprise, #pragma startup weirdness
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 21, 2017 1:14 AM   in response to: Jan Dijkstra in response to: Jan Dijkstra
It gets weirder still.

After a lot of fooling around with the source files in the packages that contain these #pragma startups (mainly to add/remove calls to ::MessageBox in order to trace what happens), I first got the second package working, in that it's startup routine would get executed. After a while (and a lot of frustration) I briefly even got the third package working.

Until I did a build on the design time package that references all these runtime packages. Now it stopped working again. Seems the linker has a mind of it's own in deciding when and when not to honor #pragma startup instructions.
Alex Belo

Posts: 626
Registered: 10/8/06
Re: XE8 Enterprise, #pragma startup weirdness
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 21, 2017 9:06 AM   in response to: Jan Dijkstra in response to: Jan Dijkstra
Jan Dijkstra wrote:

What's going on here

Pragma startup had problems.

Searching for "pragma startup" in (old archived) QC returns this issue
(I have no idea if it is relevant ot your case):


Report No: 110071 Status: Open
#pragma startup does not work correctly
http://qc.embarcadero.com/wc/qcmain.aspx?d=110071

When using three #pragma startup in three .cpp files the priority
parameter is ignored! Forum discussion for my specific problem here:
https://forums.embarcadero.com/thread.jspa?messageID=503729

It is also reproducible with C++Builder 6 (at least with an old project
I have). It is solved by some workaround a user suggested, but the main
problem still exists! The idea is that a function with a high priority
(0 = high; 254 = low) is called before one function with a lower
priority.

According to this fact we expect the following order of function calls:

1st : #pragma startup initFunc3 100
2nd : #pragma startup initFunc2 101
3rd : #pragma startup initFunc1 102


But actual calling order is:

1st : #pragma startup initFunc1 102
2nd : #pragma startup initFunc2 101
3rd : #pragma startup initFunc3 100


...and this is the complete opposite of the expected behaviour.
If you change the priority parameters, recompile and test (not just
once but 2 to 3 times) the order of the function calls will never
change. It is always the same order, regardless which priority
parameter is given.

I found out the behaviour is influenced by
#pragma package(smart_init)

In the documentation it says so. I removed all #pragma
package(smart_init) in my units. Now startup is executed in correct
order!
It was more a lucky guess to read about #pragma package.

So at least the #pragma startup docsection should be updated and tell
the user that it is affected by #pragma package! That would have spared
me a lot of trouble.


Unfortunately old QC and many old NG posts are not available on embt
site.

From my archive:

https://forums.embarcadero.com/thread.jspa?messageID=519354&tstart=0#519354

From: "Jean-Marie Babet" <bbabet at codegear dot com>
Subject: Re: CBuilder #pragma startup does not work correct

I just wanted to add that using #pragma startup/exit without a
specified
priority is not recommended, specially since there was a bug in bcc32
that we hesitated to fixing but opted not to replicate in bcc64:
although the documentation has for years said that unspecified
priorities default to 100, that has not been the case: bcc32 assigned
the priority of 30 (or there about? I cannot recall exactly) to exit
routines with unspecified priorities. And there was code that relied on
this bug: for example, an exit routine with unspecified priority was
expected to run after the main form shuts down (which occurs in
__ExitVCL, assigned a priority of #31). As I said, we opted not to
replicate this bug in bcc64. Unspecified exit routines will run at #100
there. So leaving the priority off means that the routine is invoked
after the main form shuts down on WIN32 but before on WIN64 :(

I highly recommend to you be explicit about the priority#. We might not
change bcc32's current behaviour but if/when bcc32 moves to the same FE
as bcc64, I'm sure we will not bring over that bug.


what must I do

Play with #pragma package(smart_init) ?..
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Pragma_package

--
Alex
Jan Dijkstra

Posts: 206
Registered: 11/4/99
Re: XE8 Enterprise, #pragma startup weirdness
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 23, 2017 11:42 PM   in response to: Alex Belo in response to: Alex Belo
Alex Belo wrote:
Jan Dijkstra wrote:

What's going on here

Pragma startup had problems.

Searching for "pragma startup" in (old archived) QC returns this issue
(I have no idea if it is relevant ot your case):

Report No: 110071 Status: Open
#pragma startup does not work correctly
http://qc.embarcadero.com/wc/qcmain.aspx?d=110071

When using three #pragma startup in three .cpp files the priority
parameter is ignored! Forum discussion for my specific problem here:
https://forums.embarcadero.com/thread.jspa?messageID=503729

It is also reproducible with C++Builder 6 (at least with an old project
I have). It is solved by some workaround a user suggested, but the main
problem still exists! The idea is that a function with a high priority
(0 = high; 254 = low) is called before one function with a lower
priority.

According to this fact we expect the following order of function calls:

1st : #pragma startup initFunc3 100
2nd : #pragma startup initFunc2 101
3rd : #pragma startup initFunc1 102


But actual calling order is:

1st : #pragma startup initFunc1 102
2nd : #pragma startup initFunc2 101
3rd : #pragma startup initFunc3 100
--------

Alex

Unfortunately, it's not relevant.

My problem is not that the routines aren't called in the expected order. My problem is that they're not called at all.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02