Author Topic: Apache OpenOffice 4.1.2 for eComStation and OS/2  (Read 17379 times)

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1027
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Apache OpenOffice 4.1.2 for eComStation and OS/2
« on: December 27, 2015, 03:59:57 pm »
Just starting out with the WarpIN install. It says don't install over an existing version. It then defaults to the existing installation directory and won't allow a directory change.

If uninstalling openoffice 4.1.1 is a requirement, it should be listed in the readme.

Did anyone install over 4.1.1? Does it work?
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

David McKenna

  • Hero Member
  • *****
  • Posts: 751
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #1 on: December 27, 2015, 05:06:19 pm »
 Installed here over 4.1.1 with no troubles (so far). It seems to be a bit faster than 4.1.1.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #2 on: December 27, 2015, 06:09:42 pm »
I also installed over 4.1.1, with no problems. I did NOT use the RPM package which still puts the RPM supplied DLLs in the program directory. That will REALLY screw things up. They should be in a common directory (\eCS\DLL, or \os2\DLL) because other programs use them, and you will end up with duplicates, and down level files, eventually. You won't have the problem if you use RPM/YUM to get those files because it puts them in the YUM directory structure (which has it's own problems).

I also did the procedure to load the DLLs and code high. I cannot even load the program, when Firefox is running, without doing that. I tried loading the Firefox stuff high, but it was crashing (the whole system) about 3 out of 5 times that I closed it (yes, I do have the 106 kernel). So far, AOO4.1.2 hasn't crashed on close, but 4.1.1 did do it about 1 in 10.

Sure hope somebody can fix some of those shared memory problems. My system is running on the hairy edge of disaster, and all I can do about it is stop running some very useful programs.  :-\

Greggory Shaw

  • Sr. Member
  • ****
  • Posts: 442
  • Karma: +0/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #3 on: December 27, 2015, 06:39:20 pm »
I also did the procedure to load the DLLs and code high. I cannot even load the program, when Firefox is running, without doing that. I tried loading the Firefox stuff high, but it was crashing (the whole system) about 3 out of 5 times that I closed it (yes, I do have the 106 kernel). So far, AOO4.1.2 hasn't crashed on close, but 4.1.1 did do it about 1 in 10.

Sure hope somebody can fix some of those shared memory problems. My system is running on the hairy edge of disaster, and all I can do about it is stop running some very useful programs.  :-\

Hi Doug,

Could you post the exact procedures on loading the DLLs and code high ?


Thanks

Greggory

David McKenna

  • Hero Member
  • *****
  • Posts: 751
  • Karma: +24/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #4 on: December 27, 2015, 06:46:52 pm »
 In the folder created when you installed OpenOffice, there is an 'Extras' folder. The 'Extras' folder has 3 scripts: one for loading code high, one for loading code and data high, and one for unloading from high memory. Just run the one you want to load OpenOffice into high memory (I only load code high because of past trouble loading code and data high, but I may try that again soon). You only need to do it once until you either want to change it, or install a new version.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #5 on: December 27, 2015, 10:04:59 pm »
David has it right. The configuration that you want to use will depend a lot on how your various programs use shared memory space. You also need the 106 kernel from eCS 2.2 b2, which has a couple of fixes for loading and unloading, DLLs in high shared memory space. Unfortunately, it seems that there is still a problem with that. Somebody is working on it, but there are no results, yet.

There are a few things that a user can do to help:

Add the line
dllbasing=off
near the top of CONFIG.SYS. This lets the system make more efficient use of shared memory space, at the expense of a very slight reduction in performance (you might notice it if you are running on a 486-SX processor).

Close, and/or don't use, unnecessary programs.

If you use X(e)Center, remove any DLLs that you don't use. Years ago, I found that WinList kept on using more, and more, shared memory space, even if I didn't use it. That may have been fixed, but I find that LSwitcher works much better.

Keep the number of tabs in Firefox (or Seamonkey) to a minimum. Each one adds a little more.

You can try adjusting VIRTUALADDRESSLIMIT=xxxx in CONFIG.SYS. Some say that 1024 is a good number. Others say that 2048 is good. The collected wisdom says that 1536 is generally the best. Personally, I find that 1536 works best, for me, and I start to have more problems if I increase, or decrease it. YMMV. Unfortunately, I still have problems from both sides, if I don't try to keep usage under control.

Now, for the big one (IMO). Programmers need to start using more static linking, to eliminate the use of DLLs. For some reason, they seem to be very reluctant to do that, but huge packages, like AOO, and Firefox, are eating up large amounts of shared memory space. Using high shared memory space is a partial fix, but it still has problems (the system can crash when the DLLs are unloaded). Running large programs, that use a lot of shared memory space is not a problem when the user only runs one program, but it becomes a large problem when somebody wants to run AOO and Seamonkey at the same time, along with a dozen other programs. It isn't possible to modify a lot of the older programs to use high shared memory, or even stop them from using DLLs (we don't have the source). Other programs, like the CLAM Antivirus daemon (CLAMD.EXE), use large amounts of shared memory space. The older versions used low shared memory space, while the latest (only available with RPM/YUM AFAIK) seems to be using upper shared memory space. That change makes it usable again, but there is still a limited amount of upper shared memory space available. The other option is to use it without the daemon. That is okay, but then it takes about 1 minute to load the database, before it can run the scan, which can take less than a second.

Some of these problems will be slightly easier to manage, when Arca Noae gets their Package Manager (ANPM - previously called Yumie) released. The program itself is working great, but getting it properly installed is turning into a nightmare because of the complexity of YUM itself, and even worse, because users have tried to outsmart the existing systems, or RPM/YUM has not been properly used in the past. RPM/YUM is a terrible choice for managing packages, but that is what we are presented with. ANPM is a user friendly front end for YUM, but it still uses YUM in the background, so it depends on YUM doing the right thing (and all too often, it screws up). It will probably take a bit of work to get it all sorted out, but managing the whole thing should be easier in the end. It will be even better, if the WarpIn interface gets added so it can manage both install methods.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #6 on: December 28, 2015, 12:16:59 am »
Now, for the big one (IMO). Programmers need to start using more static linking, to eliminate the use of DLLs.
No Doug, you're completely wrong, especially in the context of trying to minimize shared memory space.

Dynamic linking is the way to go and that's where we are already now!

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #7 on: December 28, 2015, 07:24:19 pm »
Quote
Dynamic linking is the way to go and that's where we are already now!

Well, dynamic linking causes more DLLs to be loaded in shared memory space, which is very limited. I am at the point where I need to stop using very useful programs to accommodate that. If something can be done to fix the problems with loading in high shared memory space, we will get some relief, for a while, but eventually we will run into the same problem, again.

Something needs to be done, and soon, or OS/2 will become unusable, again.

Jan-Erik Lärka

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 275
  • Karma: +5/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #8 on: December 30, 2015, 11:46:43 am »
I can't make ODBC work any longer with OpenOffice.
I've used PostgreSQL in the past and set it up (now the latset 9.x) and connect to it with phpPGAdmin and list things with unixODBC.
I've replaced the file odbc.dll with the patched version, but OO refuse to use it.

It return "The connection to the data source "NLSTeam" could not be established." and "Error code: 1000
ODBC" because it can't use/load odbc.dll.

Ideas how to solve?

//Jan-Erik

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4805
  • Karma: +99/-1
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #9 on: December 30, 2015, 06:57:02 pm »
Quote
Dynamic linking is the way to go and that's where we are already now!

Well, dynamic linking causes more DLLs to be loaded in shared memory space, which is very limited. I am at the point where I need to stop using very useful programs to accommodate that. If something can be done to fix the problems with loading in high shared memory space, we will get some relief, for a while, but eventually we will run into the same problem, again.

Something needs to be done, and soon, or OS/2 will become unusable, again.

Private memory is also limited as programs can't be loaded high. I experimented with SeaMonkey back before we moved it to use more high memory and before Mozilla forced the huge xul dll on us. It only helped for a while before it started running out of memory.
Eventually we'll get screwed as more programs go mostly X64 and expect to have even more memory available then we can ever deliver.

Roderick Klein

  • Hero Member
  • *****
  • Posts: 659
  • Karma: +14/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #10 on: December 30, 2015, 09:21:55 pm »
If I use high512 tool from Yuri Dario (forgot the exact name of tool). Since I loaded (what was it again the code or data segments) segments high for DLLś

* Open Open Office
* Firefox
* Thunderbird

I can use my system again the whole without to many issue's.

It provides a big improvement.

Roderick

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #11 on: December 30, 2015, 10:08:02 pm »
A couple of things that seem to help:

Since it is closing a program that causes DLLs that are loaded high to cause a system crash, leave the program running. This is particularly easy when using AOO 4.1.2 by starting the quick start program from the startup folder. I did have a couple of crashes before I did that, but none since then (only about 1 day). At least the lower shared memory usage seems to stay pretty constant after doing that.

I find that setting the Firefox DLLs to use high memory tends to cause a lot of crashes, when the program unloads. I have left them using low shared memory, for now. I expect that T'Bird, and Seamonkey, have the same problems.

CLAMD.EXE 0.98.6 (as supplied by RPM/YUM) uses high shared memory now. That makes it usable, as long as the user can squeeze enough upper shared memory space out of their system setup.  If you try to use it with low shared memory, it will use almost all of it, causing other programs to fail.

I would note, that the only programs that would use the ClamD database, would be ClamDscan, and Freshclam. This would seem to be a prime candidate to use the PAE memory, that QSINIT makes available, for the database. That would free up more than 200 meg of shared memory space (upper, or lower). Of course, this assumes that a user has more than 4 GB in the system (not all that uncommon any more).

I also quit using HPFS, and use only JFS and FAT32. That also freed up some shared memory space, with the added advantage of better performance.

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #12 on: December 30, 2015, 11:37:08 pm »
Hi All

I just performed a "clean" install of AOO4120 - as requested in the readme.

To achieve this I copied my existing \PROGRAMS\AOO4 directory structure to my TEMP directory, then deleted the contents of \PROGRAMS\AOO4 and then ran the AOO-4120-GA-base-en-US.wpi package. The AOO-4120-GA-rpm.wpi package was not available for this installation.

The install needs a little tweaking as

1] The install directory defaults to the existing \PROGRAMS\AOO4 directory and cannot be changed. This clashes with the instructions in the readme which state:-

** Warning **
Do not install this version over an existing installation.


2] The install went ahead despite the required AOO-4120-GA-rpm.wpi package not being available for the installation.



Having successfully(?) installed AOO4120 I opened Desktop -> Programs -> Installed Software -> Apache Openoffice 4.1

My first observation was that I now had 3 copies of the templates and fonts shadow folders. Possibly existing folders did not get "updated" or "replaced" but that still leaves 1 extra of each of those folders. I deleted the excess folders.

I then tried clicking the "Open document..." icon. The result was that the Openoffice splash screen appeared very briefly. I opened a command window in \PROGRAMS\AOO4\program and entered scalc which had the same result - the Openoffice splash screen appeared very briefly and then back to the command prompt. It seems Openoffice requires the DLL files from the AOO-4120-GA-rpm.wpi package - or suitable alternatives - to be in the AOO4\program directory as it obviously is not finding the DLL files in the \ecs\dll directory which is on the LibPath.

Unpacking the AOO-4120-GA-rpm.wpi package into the AOO4\program directory results in AOO4120 starting and working OK - very limited use to date though.

 
To those people who did not install the AOO-4120-GA-rpm.wpi package but did install over an existing installation and have AOO4 working OK(?) I suggest that they check for older/earlier/different builds of the required DLL files in the AOO4\program directory; possibly left over from a previous install. Maybe this is why the readme has the warning about installing over a previous installation...


Of course this now leads into the "DLL Hell" type of discussion as

1] A lot of people will, like me, already have the required DLL files - or alternative builds that may be suitable - installed and on the LibPath. Is it not possible to make Openoffice use the LibPath files?

2] I note that some of the DLL files supplied in the AOO-4120-GA-rpm.wpi package are different dates and sizes to those I have in \ecs\dll; some are newer and some are older. Some newer DLL files are smaller than the older builds in \ecs\dll so I wonder if there is some loss of function/capability in the newer smaller files...


Regards

Pete


Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #13 on: December 31, 2015, 12:03:10 am »
I just performed a "clean" install of AOO4120 - as requested in the readme.

To achieve this I copied my existing \PROGRAMS\AOO4 directory structure to my TEMP directory, then deleted the contents of \PROGRAMS\AOO4 and then ran the AOO-4120-GA-base-en-US.wpi package.
This is not a clean install. Because WarpIN can't uninstall anything automatically, you have to uninstall the old version first.

1] The install directory defaults to the existing \PROGRAMS\AOO4 directory and cannot be changed.
Sure. The WarpIN database has that path saved and you need to either uninstall your previous
AOO version or remove its entries from it first. Another option is to hack it to point to the
desired path.

mwizard

  • Guest
Re: Apache OpenOffice 4.1.2 for eComStation and OS/2
« Reply #14 on: December 31, 2015, 12:44:00 am »
I backed up my old 4.1.1.1 release folder.

I installed 4.1.2 over the top of the existing folder & contents using the WPI's provided.  The system automatically installed both the GA & EN installers.  I recall there is another associations installer that I selected.  I avoided the RPM install hoping that all my YUM pre-reqs were up to date.

I use YUM for my pre-reqs.

Any pre-reqs that are not part of YUM are likely in a libpath somewhere.  I do not recall installing any pre-req DLLs into my old release, so if anyone would have time to share some of those DLL names, I can double check my folder and give a more definitive answer.

My existing program objects all work fine, and retained the older 4.1.1 names.  I manually changed them in my desktop folders to use 4.1.2

I can load, open files, update files, save files, print files, in Writer withtout problems.  I use FF38 all the time as well.  One after the other and sometimes at the same time.

So far things are working just fine.  Neither application is crashing or misbehaving that I can tell.

I do not run them in high memory.  So far I have not run into problems with memory yet.   If needed, I can run some tests with AOO4.1.2 using high memory.

So far, I'm a very happy camper.
« Last Edit: December 31, 2015, 12:49:54 am by Mark »