Re: [dev] Windows: Help needed

[Stephan Bergmann]

Liyuan(Internet) wrote:
- 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).


if we can add variable URE_VERSION(e.g. 1.1 ,1.2)  so that the URE_BIN_DIR deployment variable 
can be set to something like 
 "${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE/1.1:Path}" and different ooo use the different version ure.


That would still not address the problem of two OOo-wo-URE installations 
using almost identical (i.e., same URE_VERSION) URE installations.  To 
quote from an earlier post of mine:  "I am talking about scenarios where 
I want to have two separate installations of OOo-wo-URE/URE pairs 
available over a period of time (e.g., one for developing cross-cutting 
feature A and the other for developing another cross-cutting feature B 
in parallel)."


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Hennes Rohling wrote:

Kay Ramme - Sun Germany - Hamburg wrote:

Stephan,

Stephan Bergmann wrote:


Again:  If I have two instances A and B of an application installed, 
and want to have a per-installation deployment variable C for that 
application stored in the registry, what would the involved registry 
keys have to look like for instance A to have C with value D and 
instance B to have C with value E?
Good question, somehow the registry keys for A and B have to be 
different. Actually I don't know, how this is conceptually solved, 
e.g. what is going to happen if I install OOo two times. Probably the 
second installation just overwrites the keys of the first, if so, I 
think we don't need to solve something which is not solved by Windows 
itself.


Anyway, putting some more thoughts into this, I think the perfect 
solution would be, to specify the to be used URE in the registry of 
the active (the last) installation, comparable to all other registry 
entries created for a particular OOo installation. The deployment 
parameters than just reference the registry entries, in case someone 
wants to change the URE for a particular installation he / she

* may either change the registry entry for the active installation, or
* directly the deployment parameter of a particular installation.



Yes, very good aproach. Again...for a good example of how the registry 
keys should look like is to install different version of a JRE.


I'm still not convinced we all talk about the same thing here.  There 
are three things involved:


1  Installed UREs should advertise their locations, so that clients can 
find them.  That is (and should be) done by writing into the registry. 
(And fits Hennes' analogy with the JRE.)


2  At installation time, OOo-wo-URE needs to find a URE installation it 
can use.  That should probably be done by reading from the registry the 
data written at (1).


3  An OOo-wo-URE installation needs to keep persistent the information 
obtained at (2).  As discussed, the registry is not a good place for 
that (as different OOo-wo-URE installations could interfere by storing 
their private data at the same location within the registry).  A better 
place probably is some data file within the OOo-wo-URE installation 
(similar to the symbolic ure-link in the Unix case).  (If I get Kay 
right, in a sense, he wants to by default evaluate that persistently 
stored information late rather than early, so that the stored 
information still references the registry key under which the latest URE 
advertised its location, rather than resolving that reference once at 
OOo-wo-URE--installation-time and storing a concrete path to a URE. 
This has the advantage that later on replacing the current URE with a 
better one *at a different location* is transparent for the OOo-wo-URE 
clients.)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Hennes Rohling wrote:

Stephan Bergmann wrote:

Hennes Rohling wrote:

Stephan Bergmann wrote:

[...]

I was talking from the consumer's point of view:  If a consumer wants 
to find out the location of the default URE in that consumer's 
context, it will query HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE.  
That either internally redirects to HKEY_CURRENT_USER (in case the 
consumer's context has a per-user URE override) or 
HKEY_LOCAL_MACHINE.  That's my understanding of Windows registry at 
least.




The typical Windows "consumer" does not change registry keys directly 
without some kind of front end ;-) But if he does he mostly know the 
differences of the root keys. Furthermore HKEY_CLASSES_ROOT is just a 
view not a real key. Reading from that key results in the effective data 
for the current user but the results of writing to that key depends on 
whether there are two similar keys in the two registry trees and whether 
the user has access right to write to HKEY_LOCAL_MACHINE...things become 
a little bit confusing.


Grr, it seems we are talking past each other here.  With "consumer" I 
meant some (software) instance that reads the registry key (in contrast 
to a "producer" that writes the key).  And the consumer sees the 
HKEY_CLASSES_ROOT view and does not care whether the producer wrote to 
HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE.


[...]

Why do the URE DLLs need delayload hooks, too?



Because otherwise the DLL hooks won't scale. If f.e. sc680mi.dll from 
OOo is linked against cppu3.dll which is linked against sal3.dll and 
cppu3.dll and sal3.dll resides in an URE directory different from OOo's 
directory then sc680mi.dll will find cppu3.dll but sal3.dll will not be 
found as only sc680mi.dll comes with a delay load stub that may override 
the runtime linker search path.


Ah, the DLLs that cppu3.dll depends on are not searched for next to 
cppu3.dll in the default case where cppu3.dll does not have delayload hooks?


What I meant with "implicit" was using osl_loadModule or LoadLibrary. 
Otherwise you will always need some kind of stub or wrapper because you 
can't get rid of the console on windows OS when using some kind of 
script (BAT, CMD) to set the PATH.


Not sure I get you here.  The following would work, right?  soffice.exe 
does not link against any URE DLLs and executes soffice.bin with a PATH 
that is extended with the URE bin directory.  And similar for all other 
top-level executables in the OOo-wo-URE tree.  (Today soffice.exe links 
against uwinapi.dll, which is also a---private---part of URE, so 
something would need to be done about that.)


[...]
I don't exactly understand what the goal of the approach is. Assuming 
there are two installations of the same application (I'm talking about 
OOo) you might run into trouble beside the issue of finding the 
installation private URE anyway. F.e. the pipe name used to pass 
arguments to an already running office currently consist of 
(version+user path+user id) but not the install path (All platforms, not 
only Windows).


"user path" being the path of the OOo user installation?  I would assume 
that two different OOo installations would use different user 
installations, so the pipe names would be different in such a scenario. 
 (My goal is to be able to have two almost identical OOo installations 
on one machine, e.g., when working in parallel on two different CWS.)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Liyuan\(Internet\)]

- Original Message - 
From: "Stephan Bergmann" <[EMAIL PROTECTED]>
Newsgroups: openoffice.dev
To: 
Sent: Wednesday, May 09, 2007 9:57 PM
Subject: [dev] Windows: Help needed


> 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).

if we can add variable URE_VERSION(e.g. 1.1 ,1.2)  so that the URE_BIN_DIR 
deployment variable 
can be set to something like 
 "${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE/1.1:Path}" and 
different ooo use the different version ure.


> - 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)?
> 
> - 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.
> 
> Input more than welcome,
> -Stephan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Hennes Rohling]

Kay Ramme - Sun Germany - Hamburg wrote:

Stephan,

Stephan Bergmann wrote:


Again:  If I have two instances A and B of an application installed, 
and want to have a per-installation deployment variable C for that 
application stored in the registry, what would the involved registry 
keys have to look like for instance A to have C with value D and 
instance B to have C with value E?
Good question, somehow the registry keys for A and B have to be 
different. Actually I don't know, how this is conceptually solved, e.g. 
what is going to happen if I install OOo two times. Probably the second 
installation just overwrites the keys of the first, if so, I think we 
don't need to solve something which is not solved by Windows itself.


Anyway, putting some more thoughts into this, I think the perfect 
solution would be, to specify the to be used URE in the registry of the 
active (the last) installation, comparable to all other registry entries 
created for a particular OOo installation. The deployment parameters 
than just reference the registry entries, in case someone wants to 
change the URE for a particular installation he / she

* may either change the registry entry for the active installation, or
* directly the deployment parameter of a particular installation.



Yes, very good aproach. Again...for a good example of how the registry 
keys should look like is to install different version of a JRE.


A caveat would be if the deployment parameters would look like the 
current bootstrap parameters because the delay load hook has to use the 
code the expand the variables and this can only be achieved with static 
linking (otherwise you'll get circular dependencies) what would increase 
the size of all DLLs.


Maybe it is possible to mix using delay load stubs and PATH environment 
variable so that only OOo's bootstrap code has to be linked with "delay 
load" using a stub that retrieves the URE path and sets the PATH for the 
process. I don't know if this will work.-..this would require some testing.


- Hennes

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Hennes Rohling]

Stephan Bergmann wrote:

Hennes Rohling wrote:

Stephan Bergmann wrote:

[...]

I was talking from the consumer's point of view:  If a consumer wants to 
find out the location of the default URE in that consumer's context, it 
will query HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE.  That either 
internally redirects to HKEY_CURRENT_USER (in case the consumer's 
context has a per-user URE override) or HKEY_LOCAL_MACHINE.  That's my 
understanding of Windows registry at least.




The typical Windows "consumer" does not change registry keys directly 
without some kind of front end ;-) But if he does he mostly know the 
differences of the root keys. Furthermore HKEY_CLASSES_ROOT is just a 
view not a real key. Reading from that key results in the effective data 
for the current user but the results of writing to that key depends on 
whether there are two similar keys in the two registry trees and whether 
the user has access right to write to HKEY_LOCAL_MACHINE...things become 
a little bit confusing.


A good example how registry keys should be used for retrieving the path 
of a runtime environment from the registry is Java.


- 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.


What do you mean with "implicitly linked?"

Using DLL hooks will scale as long as both OOo and URE are build with 
DELAYLOAD DLL hoos.


Why do the URE DLLs need delayload hooks, too?



Because otherwise the DLL hooks won't scale. If f.e. sc680mi.dll from 
OOo is linked against cppu3.dll which is linked against sal3.dll and 
cppu3.dll and sal3.dll resides in an URE directory different from OOo's 
directory then sc680mi.dll will find cppu3.dll but sal3.dll will not be 
found as only sc680mi.dll comes with a delay load stub that may override 
the runtime linker search path.


What I meant with "implicit" was using osl_loadModule or LoadLibrary. 
Otherwise you will always need some kind of stub or wrapper because you 
can't get rid of the console on windows OS when using some kind of 
script (BAT, CMD) to set the PATH.


- 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.


So, they are not useful to store information private to one specific 
application installation, right?


If the application installation does does not come with a version number 
exclusive for that installation - No.


If the information should be private to the installation it should 
reside inside the installation. If the information is private to a 
certain version of an application the registry is a good place.


I don't exactly understand what the goal of the approach is. Assuming 
there are two installations of the same application (I'm talking about 
OOo) you might run into trouble beside the issue of finding the 
installation private URE anyway. F.e. the pipe name used to pass 
arguments to an already running office currently consist of 
(version+user path+user id) but not the install path (All platforms, not 
only Windows).


- Hennes

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Kay Ramme - Sun Germany - Hamburg]

Stephan,

Stephan Bergmann wrote:


Again:  If I have two instances A and B of an application installed, and 
want to have a per-installation deployment variable C for that 
application stored in the registry, what would the involved registry 
keys have to look like for instance A to have C with value D and 
instance B to have C with value E?
Good question, somehow the registry keys for A and B have to be 
different. Actually I don't know, how this is conceptually solved, e.g. 
what is going to happen if I install OOo two times. Probably the second 
installation just overwrites the keys of the first, if so, I think we 
don't need to solve something which is not solved by Windows itself.


Anyway, putting some more thoughts into this, I think the perfect 
solution would be, to specify the to be used URE in the registry of the 
active (the last) installation, comparable to all other registry entries 
created for a particular OOo installation. The deployment parameters 
than just reference the registry entries, in case someone wants to 
change the URE for a particular installation he / she

* may either change the registry entry for the active installation, or
* directly the deployment parameter of a particular installation.



-Stephan


Regards

  Kay

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Oliver Braun]

Hi Stephan,

Stephan Bergmann wrote:

[..]
- 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.


I don't understand what you need the symbolic link for:

exported interfaces usually reside at a fixed location (be it below 
/usr for bundled or /opt for unbundled packages).


The symbolic link neatly takes care of those situations where "usually" 
does not fit.  (Also, it is what Sun's Linker and Libraries Guide 
recommends under "Dependencies Between Unbundled Products.")


Does "unbundled" here mean "not bundled with the OS" or "not bundled with each 
other" ?




For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which 
was invented for that purpose (I consider it a bug that we still use 
it in our start script).


I am not talking about one-shot manual overrides.  I am talking about 
scenarios where I want to have two separate installations of 
OOo-wo-URE/URE pairs available over a period of time (e.g., one for 
developing cross-cutting feature A and the other for developing another 
cross-cutting feature B in parallel).




You can get the same thing from using an alternate root when installing the 
packages.


This all boils down to the question whether it makes sense to change the prefix 
of the URE to a non default location A, while choosing a different prefix B for 
OOo within the very same root.


If we want to support this, we will also need to adapt the symbolic link to the 
correct destination during package installation of OOo w/o URE ..


Don't get me wrong, I just try to lower the barriers for the Windows solution by 
 avoiding "easy to have on Unix" kind of over-engineering.




[...]


If the runtime linker was able to find libuno_sal.so, we already know 
URE_BIN_DIR, don't we ? Why do we have to double that information in 
the shell scripts ?


Right now, URE_BIN_DIR is convenient for not breaking the normal OOo: 
desktop/source/deployment/registry/component/dp_component.cxx:1.16.10.2 
calls the uno executable via "$URE_BIN_DIR/uno".  If it used 
"$ORIGIN/../ure-link/bin/uno" instead, we would need to introduce a 
directory and symbolic link ure-link/bin -> ../program into the normal 
OOo.  But, yes, this decision should be re-evaluated before normal OOo 
is finally replaced by OOo-wo-URE.


My idea was more to use osl_getModuleURLFromFunctionAddress in the 
rtl::Bootstrap code to "calculate" the value at runtime.


Regards,
Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Hennes Rohling wrote:

Stephan Bergmann wrote:

[...]
- 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.


I was talking from the consumer's point of view:  If a consumer wants to 
find out the location of the default URE in that consumer's context, it 
will query HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE.  That either 
internally redirects to HKEY_CURRENT_USER (in case the consumer's 
context has a per-user URE override) or HKEY_LOCAL_MACHINE.  That's my 
understanding of Windows registry at least.


- 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.


What do you mean with "implicitly linked?"

Using DLL hooks will scale as long as both OOo and URE are build with 
DELAYLOAD DLL hoos.


Why do the URE DLLs need delayload hooks, too?

- 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.


So, they are not useful to store information private to one specific 
application installation, right?


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Hennes Rohling]

Stephan Bergmann wrote:

Hi all,

I am currently fiddling around with an OOo installation set from which 
the URE has been extracted, see 
 
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 
).


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]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Kay Ramme - Sun Germany - Hamburg wrote:
have this information (i.e., the location of its underlying URE) 
available at runtime.  And third, it should be easy for the user to 
change that information, to at least be able to (a) at installation 
time  combine the OOo-wo-URE with an arbitrary URE (not necessarily 
"the machine's default URE"), and (b) later on move around the 
installation locations of the OOo-wo-URE or its underlying URE, or both.
My understanding of windows registry entries is, that they actually 
serve (or at least partly do so) the same purpose as the deployment 
parameters. In the sense, that if a user wants to change the URE to be 
used by a particular office installation, he/she would change a registry 
entry of that installation for that reason.


and

Not sure about OOo storing its deployment data in the registry.  What 
would the keys look like?  What about having two instances of OOo 
installed that are "sufficiently similar" from a code-base point of 
view (i.e., would probably both use the same keys), but nevertheless 
shall have different deployment data?
You certainly would need different registry entries for different 
installations, while having one global entry pointing to the "default" 
installation.


Again:  If I have two instances A and B of an application installed, and 
want to have a per-installation deployment variable C for that 
application stored in the registry, what would the involved registry 
keys have to look like for instance A to have C with value D and 
instance B to have C with value E?


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Oliver Braun wrote:

Hi Stephan,

please find my comments inline:

Stephan Bergmann wrote:

[..]
- 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.


I don't understand what you need the symbolic link for:

exported interfaces usually reside at a fixed location (be it below /usr 
for bundled or /opt for unbundled packages).


The symbolic link neatly takes care of those situations where "usually" 
does not fit.  (Also, it is what Sun's Linker and Libraries Guide 
recommends under "Dependencies Between Unbundled Products.")


For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which 
was invented for that purpose (I consider it a bug that we still use it 
in our start script).


I am not talking about one-shot manual overrides.  I am talking about 
scenarios where I want to have two separate installations of 
OOo-wo-URE/URE pairs available over a period of time (e.g., one for 
developing cross-cutting feature A and the other for developing another 
cross-cutting feature B in parallel).


[...]
- 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 
).


If the runtime linker was able to find libuno_sal.so, we already know 
URE_BIN_DIR, don't we ? Why do we have to double that information in the 
shell scripts ?


Right now, URE_BIN_DIR is convenient for not breaking the normal OOo: 
desktop/source/deployment/registry/component/dp_component.cxx:1.16.10.2 
calls the uno executable via "$URE_BIN_DIR/uno".  If it used 
"$ORIGIN/../ure-link/bin/uno" instead, we would need to introduce a 
directory and symbolic link ure-link/bin -> ../program into the normal 
OOo.  But, yes, this decision should be re-evaluated before normal OOo 
is finally replaced by OOo-wo-URE.


Please give some examples what entries will be in URE_BOOTSTRAP and why 
they can't be in let's say "sofficerc".


Please search for "fundamentalrc" and "URE_MORE_TYPES" in 
.


-Stephan

[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Stephan Bergmann wrote:

Caolan McNamara wrote:

On Thu, 2007-05-10 at 10:52 +0200, Oliver Braun wrote:

Caolan McNamara wrote:

I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
into is that with the current layout at least we do need it so that
third party uno components spawned by OOo which are deployed
into /uno_packages/ can link against the /path/to/ooo/program
libraries :-(
If spawned in process, I would expect those libraries to already be 
mapped into memory. And for out-of-process components we could adapt 
the launcher to set LD_LIBRARY_PATH appropriately.


FWIW http://dba.openoffice.org/drivers/postgresql/ is an example. Post
installation without LD_LIBRARY_PATH it won't appear in the base
downdown "connect to an existing database" list, with LD_LIBRARY_PATH it
will.


Interesting, sounds like a bug, will have a look.




-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Caolan McNamara wrote:

On Thu, 2007-05-10 at 10:52 +0200, Oliver Braun wrote:

Caolan McNamara wrote:

I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
into is that with the current layout at least we do need it so that
third party uno components spawned by OOo which are deployed
into /uno_packages/ can link against the /path/to/ooo/program
libraries :-(
If spawned in process, I would expect those libraries to already be mapped into 
memory. And for out-of-process components we could adapt the launcher to set 
LD_LIBRARY_PATH appropriately.


FWIW http://dba.openoffice.org/drivers/postgresql/ is an example. Post
installation without LD_LIBRARY_PATH it won't appear in the base
downdown "connect to an existing database" list, with LD_LIBRARY_PATH it
will.


Interesting, sounds like a bug, will have a look.

As Oliver already said, in-process component libraries can expect the 
necessary libraries to be already available.  ("http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE";>URE 
README states: “C++ UNO components run from within the uno executable 
can depend on an environment in which the public C++ UNO runtime dynamic 
libraries (cppu, cppuhelper, sal, salhelper, stlport) are already 
available (that is, on Linux x86, Solaris x86, and Solaris SPARC, a 
component dynamic library need not make sure that the UNO runtime 
dynamic libraries it needs can be found on its RPATH).” The question is 
whether this should also pertain to UNO components or arbitrary other 
libraries started from elsewhere.  I think it should at least 
also pertain to OOo extensions executing within OOo.)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Caolan McNamara]

On Thu, 2007-05-10 at 10:52 +0200, Oliver Braun wrote:
> Caolan McNamara wrote:
> > I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
> > have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
> > into is that with the current layout at least we do need it so that
> > third party uno components spawned by OOo which are deployed
> > into /uno_packages/ can link against the /path/to/ooo/program
> > libraries :-(
> 
> If spawned in process, I would expect those libraries to already be mapped 
> into 
> memory. And for out-of-process components we could adapt the launcher to set 
> LD_LIBRARY_PATH appropriately.

FWIW http://dba.openoffice.org/drivers/postgresql/ is an example. Post
installation without LD_LIBRARY_PATH it won't appear in the base
downdown "connect to an existing database" list, with LD_LIBRARY_PATH it
will.

C.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Oliver Braun]

Caolan McNamara wrote:

I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
into is that with the current layout at least we do need it so that
third party uno components spawned by OOo which are deployed
into /uno_packages/ can link against the /path/to/ooo/program
libraries :-(


If spawned in process, I would expect those libraries to already be mapped into 
memory. And for out-of-process components we could adapt the launcher to set 
LD_LIBRARY_PATH appropriately.


Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Kay Ramme - Sun Germany - Hamburg]

Hi Stephan,

Stephan Bergmann wrote:

Kay Ramme - Sun Germany - Hamburg wrote:
[...]
Anyway, even using the mentioned registry entry does not seem to 
achieve what you want to achieve, as this registry entry is globally 
unique and does not belong to the office installation. So, what you 
actually want, is an OOo installation specific entry, which points to 
the to be used URE.


No, not necessarily.  (If OOo-wo-URE wants to store a pointer to its 
underlying URE, it need not use the registry at all.)  Let me rephrase 
my thoughts:

Sure :-)


There are three steps involved.  First, when OOo-wo-URE is installed, it 
needs an installed URE, so that needs to be found somehow (and 
HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE pointing at "the machine's 
default URE" might come in handy here).  Second, OOo-wo-URE needs to 

Yes, agreed, that's what I meant.
have this information (i.e., the location of its underlying URE) 
available at runtime.  And third, it should be easy for the user to 
change that information, to at least be able to (a) at installation time 
 combine the OOo-wo-URE with an arbitrary URE (not necessarily "the 
machine's default URE"), and (b) later on move around the installation 
locations of the OOo-wo-URE or its underlying URE, or both.
My understanding of windows registry entries is, that they actually 
serve (or at least partly do so) the same purpose as the deployment 
parameters. In the sense, that if a user wants to change the URE to be 
used by a particular office installation, he/she would change a registry 
entry of that installation for that reason.


Anyway, we certainly can say, that registry entries are just for finding 
particular installations, with the consequence, that we would only 
_reference_ the HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE somehow. 
If we do that centrally, like in bootstrap.ini, we would ensure that 
only a single place needs to be changed to switch from one URE to 
another. So, I am not sure yet, how to solve the binary stuff etc., may 
be Hennes customer loader thing can do look up through the appropriate 
bootstrap variable? Unfortunately this may lead to bootstrapping 
problems because of cycle dependencies (the office libraries needing to 
find the bootstrap parameters to resolve the boostrap parameters).


By the way, if we put that whole thing from its head to its feed, 
basically registering the office services into a particular URE 
installation, the above problems seem to vanish ... ;-)


AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an 
OOo installation specific registry entry, and, as you already 
suggested, to introduce .ini files for all executables, so the latter 
may be avoided by seamless integration/support of windows registry 
entries into the deployment parameter approach.


Not sure about OOo storing its deployment data in the registry.  What 
would the keys look like?  What about having two instances of OOo 
installed that are "sufficiently similar" from a code-base point of view 
(i.e., would probably both use the same keys), but nevertheless shall 
have different deployment data?
You certainly would need different registry entries for different 
installations, while having one global entry pointing to the "default" 
installation.


-Stephan


 Kay

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Caolan McNamara]

On Thu, 2007-05-10 at 09:30 +0200, Oliver Braun wrote:

> For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which was 
> invented for that purpose (I consider it a bug that we still use it in our 
> start 
> script).

I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
into is that with the current layout at least we do need it so that
third party uno components spawned by OOo which are deployed
into /uno_packages/ can link against the /path/to/ooo/program
libraries :-(

C.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Oliver Braun]

Hi Stephan,

please find my comments inline:

Stephan Bergmann wrote:

[..]
- 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.


I don't understand what you need the symbolic link for:

exported interfaces usually reside at a fixed location (be it below /usr for 
bundled or /opt for unbundled packages).


For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which was 
invented for that purpose (I consider it a bug that we still use it in our start 
script).


Even if you want to keep the URE reference relative, you still do not need the 
symbolic link.


- 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 
).


If the runtime linker was able to find libuno_sal.so, we already know 
URE_BIN_DIR, don't we ? Why do we have to double that information in the shell 
scripts ?


Please give some examples what entries will be in URE_BOOTSTRAP and why they 
can't be in let's say "sofficerc".




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).



As stated above, one does not necessary need symbolic links to address the debug 
problem on Unix.


The canonical way to achieve this on Windows I believe is to extend the PATH 
variable by default (or install into the system32 directory) and copy debug 
versions aside the executable where they will be preferred.


Regards,
Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Stephan Bergmann]

Kay Ramme - Sun Germany - Hamburg wrote:
[...]
Anyway, even using the mentioned registry entry does not seem to achieve 
what you want to achieve, as this registry entry is globally unique and 
does not belong to the office installation. So, what you actually want, 
is an OOo installation specific entry, which points to the to be used URE.


No, not necessarily.  (If OOo-wo-URE wants to store a pointer to its 
underlying URE, it need not use the registry at all.)  Let me rephrase 
my thoughts:


There are three steps involved.  First, when OOo-wo-URE is installed, it 
needs an installed URE, so that needs to be found somehow (and 
HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE pointing at "the machine's 
default URE" might come in handy here).  Second, OOo-wo-URE needs to 
have this information (i.e., the location of its underlying URE) 
available at runtime.  And third, it should be easy for the user to 
change that information, to at least be able to (a) at installation time 
 combine the OOo-wo-URE with an arbitrary URE (not necessarily "the 
machine's default URE"), and (b) later on move around the installation 
locations of the OOo-wo-URE or its underlying URE, or both.


AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an OOo 
installation specific registry entry, and, as you already suggested, to 
introduce .ini files for all executables, so the latter may be avoided 
by seamless integration/support of windows registry entries into the 
deployment parameter approach.


Not sure about OOo storing its deployment data in the registry.  What 
would the keys look like?  What about having two instances of OOo 
installed that are "sufficiently similar" from a code-base point of view 
(i.e., would probably both use the same keys), but nevertheless shall 
have different deployment data?


-Stephan

[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Windows: Help needed

[Kay Ramme - Sun Germany - Hamburg]

Hi Stephan,

moving out URE stuff of OOo windows installations indeed seems to be 
more difficult than Unix (IMHO, as always :-). This seems to be more or 
less rooted in the fact, that windows does not support (symbolic) links 
on the on hand, while there is a mismatch between the binary world of 
libraries, executables etc. and the registry. This simply is not thought 
through well ... ;-)


Anyway, even using the mentioned registry entry does not seem to achieve 
what you want to achieve, as this registry entry is globally unique and 
does not belong to the office installation. So, what you actually want, 
is an OOo installation specific entry, which points to the to be used URE.


AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an OOo 
installation specific registry entry, and, as you already suggested, to 
introduce .ini files for all executables, so the latter may be avoided 
by seamless integration/support of windows registry entries into the 
deployment parameter approach.


Hope that helps

  Kay

Stephan Bergmann wrote:

Hi all,

I am currently fiddling around with an OOo installation set from which 
the URE has been extracted, see 
 
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 
).


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).


- 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)?


- 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.


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]

[dev] Windows: Help needed

[Stephan Bergmann]

Hi all,

I am currently fiddling around with an OOo installation set from which 
the URE has been extracted, see 
 
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 
).


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).


- 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)?


- 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.


Input more than welcome,
-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]