Stephan Bergmann wrote:
[...]
The interesting thing, however, is that if I re-build this test scenario
from scratch, with a main.exe and first.dll and second.dll
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built "by
hand" (without many of the switches used in the OOo build env.)---then
it works! I then do not even need the MS runtime libs in the
C:\TEST\sub directory, the process starts happily with the runtime libs
just in the C:\TEST directory next to the executable, and the re-thrown
exception is caught.
So, maybe there is still hope, if we can identify the critical
difference in the build environments for the two scenarios, and adapt
the OOo build env. correspondingly...
The magic difference appears to be the way the Windows SDK mt tool is
called to include XXX.dll.manifest in XXX.dll itself. The OOo build
environment uses a resource_id of 2 (i.e.,
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, cf. WinUser.h in the Windows SDK),
while I used the default (CREATEPROCESS_MANIFEST_RESOURCE_ID, defined as
1). There appears to be no particular reason to use 2 in
solenv/inc/tg_shl.mk:1.98 and following revisions (and
solenv/inc/_tg_shl.mk generated from it), so I am now doing a DEV300m11
wntmsci12.pro OOo built with those places changed to the default, hoping
that the resulting application will work fine. (However, the sad truth
is that such a build takes on the magnitude of days rather than hours
for me, so it will be some time before we know for sure...)
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
