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] Submitting Suggestions

[Hubert Figuiere]

On Thu, 2007-05-10 at 10:29 -0400, [EMAIL PROTECTED] wrote:
> So I was wondering to whom would I submit my suggestion to?

You can use issue tracker. (need to register first, it is free)

http://qa.openoffice.org/issue_handling/pre_submission.html

That way the issue is tracked and everybody can follow how it handled.
Be aware that this does not mean it will be solved right away.

Thanks for your interest.

Hub

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

[dev] Submitting Suggestions

[brojwlewis]

I am new to OpenOffice.org and absolutely love the concept of a user developed 
free office suite.  Also I think that you guys have done a first class job in 
creating a program that is easy to use.  
 
I am a construction estimator and use spreadsheets on a daily basis to produce 
multi-million dollar estimates and I noticed a feature in the spreadsheet that 
I would like to see expanded, however I am not a programmer.  So I was 
wondering to whom would I submit my suggestion to?
 
The feature I am referring to is the "fill down" function in the spreadsheet.  
I think that it is handy when pressing Ctrl+D under a lst of text that a small 
window appears allowing you to select what you want to fill from the preceeding 
list of text, however this feature doesn't work for a list of values.  My 
suggestion is to make the Ctrl+D fill down apply to values as well as text.
 
Thanks much,
Jeff
Username: EstimatorX

AOL now offers free email to everyone.  Find out more about what's free from 
AOL at AOL.com.

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]