Issue 101244 - Windows: move all DLLs into brand program directory
Summary: Windows: move all DLLs into brand program directory
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m46
Hardware: PC Windows, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: joerg.skottke
QA Contact: issues@framework
: 96132 101570 (view as issue list)
Depends on:
Reported: 2009-04-21 14:48 UTC by Stephan Bergmann
Modified: 2009-10-09 08:11 UTC (History)
1 user (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2009-04-21 14:48:59 UTC
Unlike on other platforms, spreading DLLs across the three layers has no real
benefits on Windows (and was mainly done for consistency across platforms), but
instead on the one hand causes problems (like issue 94226) and on the other hand
degrades performance (see
Comment 1 Stephan Bergmann 2009-04-21 14:49:55 UTC
Comment 2 Stephan Bergmann 2009-05-06 09:23:47 UTC
Issue 101570 is probably another problem similar to issue 94226 (with ICU
instead of libxml2) that could eventually be solved by this change.
Comment 3 Olaf Felka 2009-05-07 09:51:22 UTC
*** Issue 101570 has been marked as a duplicate of this issue. ***
Comment 4 Stephan Bergmann 2009-05-08 12:39:49 UTC
fixed on cws/sb110 (only moving DLLs from Basis layer, not from URE layer, to
avoid incompatible changes to OOo's external interface); relevant commits:
r271682: read configmgr ini file explicitly from $OOO_BASE_DIR/program (instead
of next to configmgr dynamic library)
r271683: take odbcconfig.exe explicitly from $OOO_BASE_DIR/program (instead of
implicitly next to some dynamic library)
r271684: take senddoc.exe explicitly from $OOO_BASE_DIR/program (instead of
implicitly next to some dynamic library)
r271685 take legacy_binfilters.rdb explicitly from $OOO_BASE_DIR/program
(instead of implicitly next to some dynamic library); cleaned up dead code
r271686 support NativeServicesURLPrefix on individual files; to implement that,
changed meaning of global unomaxservices
r271702 hardwire Python dynamic libraries and script files into base layer (even
if other dynamic libraries will move to brand layer on Windows), mainly because
the pyuno dynamic library is both linked against from other dynamic libraries
( and accessed via "import pyuno" from Python scripts
r271703 for performance reasons, on Windows move DLLs from basis to brand layer
(i.e., next to executables); consequently eliminated some library duplications
across the layers; adapted various code to the move
r271712 after DLLs have been moved from basis to brand layer on Windows, code
that used SvtPathOptions::GetModulePath to located libraries had to be adapted
Comment 5 Stephan Bergmann 2009-06-22 11:09:48 UTC
*** Issue 96132 has been marked as a duplicate of this issue. ***
Comment 6 Stephan Bergmann 2009-07-24 10:46:31 UTC
@jsk:  Please verifiy that
- on Windows, almost all DLLs from basis-layer program directory have moved to
brand-layer program directory;
- there are no regressions on Windows resulting from the move (esp. in code that
is triggered from outside, like system integration or Mozilla integration, or
triggers outside code, like mail merge).
- on other platforms, nothing has changed (the libraries are still in the
basis-layer program directory, and there are no regressions).
Comment 7 joerg.skottke 2009-08-13 14:03:17 UTC
Mail Merge -> Test E-Mail settings is broken.
Comment 8 joerg.skottke 2009-08-13 14:40:57 UTC
Setting back to fixed - i managed to unveil a logic error in the user interface
which will certainly harm one in a billion users.
Comment 9 joerg.skottke 2009-08-13 14:41:32 UTC
Comment 10 joerg.skottke 2009-10-09 08:11:46 UTC