Stephan Bergmann wrote:
Hi all,
I am currently fiddling around with an OOo installation set from which
the URE has been extracted, see
<http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE>
for details.
On Unix/ELF, this already works reasonably well. I need a single
symbolic link from the base directory of the OOo-wo-URE installation to
the base directory of the URE installation. All the places where things
in OOo-wo-URE need to access things in URE are routed over this link:
- Executables and shared libraries in OOo-wo-URE find shared libraries
in URE they depend on via an RPATH (recorded in those executables and
shared libraries) that includes the link to the URE.
- The deployment variables URE_BIN_DIR (used in all other places in the
code where things in URE need to be accessed) and URE_BOOTSTRAP
(pointing at a fundamentalrc in OOo-wo-URE that contains essential
deployment variables to adapt the URE to the needs of OOo) are set in
the shell scripts soffice and unopkg (which should cover, via
indirections, most if not all of the executables that constitute the
"interface of OOo," see
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19840>).
However, I have problems imagining how I can do something similar on
Windows:
- An installed URE already announces its location in the Windows
registry at HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE. But, even if
all the code that needs to know this value can read it (e.g., we
introduce additional syntax so that the URE_BIN_DIR deployment variable
can be set to something like
"${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE:Path}"), one
ugly problem would remain: It would not be easy at all to install two
different pairs of URE and OOo-wo-URE on the same machine (which is of
utmost importance at least for developers, and somewhat easily solved in
the Unix scenario above---all you have to do is adjust the one symbolic
link per installed URE/OOo-wo-URE pair).
HKEY_CLASSES_ROOT is wrong. It's just a merged view of
HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes.
I guess HKEY_LOCAL_MACHINE is meant if OOo was deployed for all users.
Otherwise HKEY_CURRENT_USER is the right base key.
- Assuming that OOo-wo-URE does know where the URE is located, how can
executables and DLLs in OOo-wo-URE access the DLLs in URE they depend
on? Extend the PATH? DLL hooks Hennes is currently working on (would
that scale)?
Extending the PATH will only work if OOo isn't implicitly linked against
URE or if OOo uses a wrapper that extends the path so OOo can inherit it.
Using DLL hooks will scale as long as both OOo and URE are build with
DELAYLOAD DLL hoos.
- Are there any clever places to set the URE_BOOTSTRAP deployment
variable so that all executables in the "interface of OOo" are
guaranteed to have it set (for themselves and any other processes they
spawn, i.e., ideally as an environment variable)? The last resort would
be to make sure that next to each such executable named foo there is a
foo.ini that contains a definition for URE_BOOTSTRAP.
What Kay wrote is correct. Registry keys have a global context not bound
to an installation location. They may be bound to a version.
Input more than welcome,
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
