Matthias Huetsch wrote:
> Hi Stephan,
>
> Stephan Bergmann wrote:
>> Folks,
>>
>> On CWS sb71 it turned out we need to move code on
Windows from sal
>> DllMain to global main. Hennes just did that and
added two symbols to
>> the sal API (sal_initialize, sal_deinitialize).
>
> As a side note: Though I do understand why these
changes are necessary,
> may I still regard them as "ugly" (IMHO, of
course)?
Dead ugly I consider them, too, but probably for another
reason than you
do: They are an incompatible change. (A Windows executable
compiled
against old sal and run against new sal will neither execute
sal's
initialization code in sal's DllMain---it has been removed
from
there---nor execute sal_initialize---that call is inline in
main.h, so
old code does not get it. There hopefully are ca. zero
Windows
executables built on URE out there in the wild, so we
hopefully get away
with this.)
In hindsight, when the need to call *some* initialization
(osl_setCommandArgs) from main got catered for in
sal/inc/sal/main.h:1.4
it would have been better to once-and-for-all cater for *any
future*
initialization needs, by introducing sal_initialize right
from the
start, and calling osl_setCommandArgs from within
sal_initialize. (And
we cannot now move the call to osl_setCommandArgs from main
to
sal_initialze, for those compatibility reasons.)
A further thought: Do we need sal_deinitialize (only called
when
sal_main[with_args] returns normally) or would it be better
to execute
any necessary deinitialization through atexit (thus also
called when
calling exit)? I would tend to think we should use atexit
instead of
sal_deinitialize, but the above paragraph suggests that we
probably
should be non-conservative in adding hooks into main.h?
Again, opinions
anyone?
[...]
>> If the former, we could and should make
sal_[de]initialize "URE private"
>> symbols (that are publicly exported from sal, but
not intended to be
>> explicitly called from client code), move them in
>> sal/util/sal.map:1.58.12.3 from section UDK_3.7 to
section PRIVATE_1.1,
>> and probably rename them to
sal_detail_[de]initialize (to match the
>> naming convention of the symbols already present in
section PRIVATE_1.0).
>
> With a "yes" to the first question, this is
also "Yes", please make them
> private.
Yes, will do.
-Stephan
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe porting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org
|