OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: mickhead on June 10, 2014, 01:28:43 am

Title: A-Oo 4
Post by: mickhead on June 10, 2014, 01:28:43 am
Is a developer(s) work on this program update currently?
Title: Re: A-Oo 4
Post by: dbanet on June 10, 2014, 01:33:58 am
AFAIK Yuri Dario is working on 4.1.
Title: Re: A-Oo 4
Post by: Martin Iturbide on June 10, 2014, 02:05:37 am
This was the latest news about it: http://www.os2world.com/past-news/80-software/19770-apache-openoffice-4-0 (http://www.os2world.com/past-news/80-software/19770-apache-openoffice-4-0)
Title: Re: A-Oo 4
Post by: Silvan Scherrer on June 10, 2014, 06:16:49 pm
I'm running a 2 month old 4.1 build. It works very good so far.

regards
Silvan
Title: Re: A-Oo 4
Post by: Thomas M. on June 10, 2014, 08:51:56 pm
I would be very interested in giving it a try under Warp 4.52.
Do you think this could be possible?

Thomas
Title: Re: A-Oo 4
Post by: Mentore on June 11, 2014, 09:06:12 am
I would be very interested in giving it a try under Warp 4.52.
Do you think this could be possible?

Thomas

This shouldn't be a problem. I don't remember if I had good results (maybe not, but then again, I had a clumsy OOo install).
If you're trying the Yuri Dario build, just follow his instructions regarding the needed DLLs.

Mentore
Title: Re: A-Oo 4
Post by: Mentore on June 11, 2014, 09:06:52 am
I'm running a 2 month old 4.1 build. It works very good so far.

regards
Silvan

Hello Silvan,
where did you find this release? I seem unable to fetch one.

Mentore
Title: Re: A-Oo 4
Post by: dbanet on June 11, 2014, 12:25:32 pm
I would be very interested in giving it a try under Warp 4.52.

There is no significant difference between eCS and ACP2. The days when OS/2 was being developed are gone very long time ago.
Title: Re: A-Oo 4
Post by: dbanet on June 11, 2014, 12:26:15 pm
I'm running a 2 month old 4.1 build. It works very good so far.

regards
Silvan

Hello Silvan,
where did you find this release? I seem unable to fetch one.

Mentore

Directly from Paperino, I assume. irc://freenode/netlabs (http://irc://freenode/netlabs)
Title: Re: A-Oo 4
Post by: Thomas M. on July 22, 2014, 06:21:24 pm
I would be very interested in giving it a try under Warp 4.52.
Do you think this could be possible?

Thomas

This shouldn't be a problem. I don't remember if I had good results (maybe not, but then again, I had a clumsy OOo install).
If you're trying the Yuri Dario build, just follow his instructions regarding the needed DLLs.

Mentore

Getting the needed DLLs is a  problem to me.
I found a link to an italian ecomstation site. In the readme it says:

the following packages must be installed (dll only)
   libc 0.6.5
   gcc 4.4.6
   gcc 4.4.4
   ssl
   curl
   jpeg
   xslt
   libicu
   z
   xml2
   stdcpp
   mmap
   pthread
   urpo

These files can be installed with the following command:

   yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library

if you have a valid rpm/yum installation.
Otherwise you can grab the corresponding zip files from

   http://rpm.netlabs.org/release/00/zip/


As I do not have a rpm/yum installation I intended to grab the zip-folders. But for example there is no gcc-4.4.4 folder. Others are missing also from what I understand.
Can somebody give me a hint?

Thanks a lot.

Thomas
Title: Re: A-Oo 4
Post by: Greggory Shaw on July 22, 2014, 07:33:36 pm

As I do not have a rpm/yum installation I intended to grab the zip-folders. But for example there is no gcc-4.4.4 folder. Others are missing also from what I understand.
Can somebody give me a hint?

Thanks a lot.

Thomas

I'm not trying to start something, but I can't hold back any longer on Yum

If Yuri and others ported OpenOffice which is a huge deal for us, and uses Yum why not use it. The first string posted for Yum and Dll for OF was wrong and I think Martin posted the correct one.


Greggory
Title: Re: A-Oo 4
Post by: Doug Bissett on July 23, 2014, 12:34:43 am
Quote
As I do not have a rpm/yum installation I intended to grab the zip-folders. But for example there is no gcc-4.4.4 folder. Others are missing also from what I understand.
Can somebody give me a hint?

ftp://ftp.netlabs.org/pub/gcc/gcc4core-1_2_2.wpi (ftp://ftp.netlabs.org/pub/gcc/gcc4core-1_2_2.wpi) contains some of them.

ftp://ftp.netlabs.org/incoming/mozilla/MZFNTCFGFT_RUNTIME-2-5-3.wpi (ftp://ftp.netlabs.org/incoming/mozilla/MZFNTCFGFT_RUNTIME-2-5-3.wpi) has others.

http://hobbes.nmsu.edu/download/pub/os2/apps/internet/www/browser/moz_required_dlls_v1.zip (http://hobbes.nmsu.edu/download/pub/os2/apps/internet/www/browser/moz_required_dlls_v1.zip) has even more.

Quote
I'm not trying to start something, but I can't hold back any longer on Yum

It can't go away fast enough for me.

I would suggest that if you wish to use it, start with a new install, which includes it. If you don't you are going to have to track down every instance of files that it manages, and remove them from places where RPM/YUM doesn't know about. If you don't, you will likely experience what is called "DLL HELL". You will also have to remember to try updates using RPM/YUM first, and when that doesn't work, you still need to find the individual files, which may, eventually, be supported by RPM/YUM, and then you need to remember that you did it manually, and undo it.
Title: Re: A-Oo 4
Post by: dbanet on July 26, 2014, 09:52:15 am
I would be very interested in giving it a try under Warp 4.52.
Do you think this could be possible?

Thomas

This shouldn't be a problem. I don't remember if I had good results (maybe not, but then again, I had a clumsy OOo install).
If you're trying the Yuri Dario build, just follow his instructions regarding the needed DLLs.

Mentore

Getting the needed DLLs is a  problem to me.
I found a link to an italian ecomstation site. In the readme it says:

the following packages must be installed (dll only)
   libc 0.6.5
   gcc 4.4.6
   gcc 4.4.4
   ssl
   curl
   jpeg
   xslt
   libicu
   z
   xml2
   stdcpp
   mmap
   pthread
   urpo

These files can be installed with the following command:

   yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library

if you have a valid rpm/yum installation.
Otherwise you can grab the corresponding zip files from

   http://rpm.netlabs.org/release/00/zip/


As I do not have a rpm/yum installation I intended to grab the zip-folders. But for example there is no gcc-4.4.4 folder. Others are missing also from what I understand.
Can somebody give me a hint?

Thanks a lot.

Thomas

http://www.os2world.com/past-news/79-general/20214-os-2-dlls-search-service
Title: Re: A-Oo 4
Post by: Thomas M. on July 26, 2014, 12:42:49 pm
Great! Thanks a lot.
Looking up that directory offers a lot DLLs. How can I find out which one I need? Or would you suggest to take them all?

Thomas
Title: Re: A-Oo 4
Post by: dbanet on July 26, 2014, 10:57:57 pm
You are really making troubles not using YUM/RPM, seriously.

Okay, I don't like it, but let me do that for you: it seems to be this is the easieset way in this situation.

ftp://dbanet.org/dbanet/tmp/dlls-especially-for-thomas-who-is-too-lazy-to-install-rpm-yum.zip

If it fails to work with this bundle of DLLs, just accept the thought that yum/rpm env is required. You wouldn't be asking for help on this forum.
Title: Re: A-Oo 4
Post by: Joop on July 27, 2014, 12:18:30 am
just accept the thought that yum/rpm env is required.
Yum/rpm sucks, belongs to a system with a very bad management in files and directories. We have a fine object oriented system, lets make use of it. I really don't understand what other user are complaining, installing is more or less just dumping the zip into a directory of choice. DLL's which belong to the program should be installed within the directory structure of that program and NOT  in the OS/2 or eCS directory structure with other DLL's. Only DLL's for general usage by every program should go there.
Moreover, if I install it I know were what is put down, if YUM/RPM does it for you just say some prays. 
Title: Re: A-Oo 4
Post by: dbanet on July 27, 2014, 01:21:59 am
DLLs should be shared.
Title: Re: A-Oo 4
Post by: Eugene Tucker on July 27, 2014, 01:26:20 am
I work in It. Yum I do not like it I do not dislike it. It is just a tool to achieve a desired result. Not all tools work correctly even in Linux. If I have to use Yum /RPM to get stuff to work so be it. As far as all this discussion goes on that.

Were do we get the latest build of Apache Open Office.
Title: Re: A-Oo 4
Post by: Joop on July 27, 2014, 03:02:58 am
DLLs should be shared.
No, if the DLL is specific to the program then there is no use to place it in the structure of OS/2 or eCS. Next, if you set the DLL in the program directory then  you won't get the problem of version problems of the same DLL. And there are a lot of DLL's out there which has nothing to do with the OS and everything with the program. There will be no other program which will call that DLL, so that DLL has nothing to do within the structure of OS/2 or Ecs.
Title: Re: A-Oo 4
Post by: dbanet on July 27, 2014, 05:05:14 am
DLLs should be shared.
No, if the DLL is specific to the program then there is no use to place it in the structure of OS/2 or eCS. Next, if you set the DLL in the program directory then  you won't get the problem of version problems of the same DLL. And there are a lot of DLL's out there which has nothing to do with the OS and everything with the program. There will be no other program which will call that DLL, so that DLL has nothing to do within the structure of OS/2 or Ecs.

Lots of programs use libc065, gcc446, gcc444, ssl, curl, jpeg, xslt, libicu, z, xml2, stdcpp, mmap, pthread, urpo and other libraries, distributed via RPM.

DLLs should be shared just by the definition of the very term.
Title: Re: A-Oo 4
Post by: Dave Yeo on July 27, 2014, 07:03:41 am
DLLs should be shared.
No, if the DLL is specific to the program then there is no use to place it in the structure of OS/2 or eCS. Next, if you set the DLL in the program directory then  you won't get the problem of version problems of the same DLL. And there are a lot of DLL's out there which has nothing to do with the OS and everything with the program. There will be no other program which will call that DLL, so that DLL has nothing to do within the structure of OS/2 or Ecs.

Looking at the list of DLLs that was posted earlier in thread, most all are used by various programs, mostly *nix ports. The only one that I haven't come across before is libicu and most I've used for various ports though usually my own builds.
Best is to have the *nix shared libraries in their own spot, perhaps x:\usr\lib and we can even refer to x as %UNIXROOT% and a package manager is handy to keep everything up to date and resolve dependencies, just a shame that they chose RPM which being one o f the first package managers on Linux had weaknesses.
Title: Re: A-Oo 4
Post by: Thomas M. on July 27, 2014, 10:19:12 am
Thank you very much, Boris.

Thomas
Title: Re: A-Oo 4
Post by: Andi B. on July 27, 2014, 12:38:07 pm
Quote
Yum/rpm sucks, belongs to a system with a very bad management in files and directories. We have a fine object oriented system, lets make use of it.
So start rewriting all these ported stuff to native OS/2 apps. Mozilla, OpenOffice, QPDFview, VLC, SMplayer to name only a few of them. Yoop I think you're dreaming of times where we could use OS/2 the way it was designed and neglect this times are over more than 15 years now. If you want use ported stuff you've to live with their annoyances to some extend.

Quote
DLL's which belong to the program should be installed within the directory structure of that program ..... Only DLL's for general usage by every program should go there.
That's the usual approach for ported stuff too. But sometimes it's not easy to decide which dll will not be used by another program. Moreover often some dlls will be reused by another program afterwards what the initial developers could not foresee in the first place. Just to give some ideas that the whole dll issue is way more complicated as some people think off.

Additionally we do have this very bad shared mem problem on our platform. So we have to reuse (share) dlls as much as possible. Building matching dlls for each program and distribute it in the programs directory and let every program use the special version of the dll would work for other system where these shared mem problem do not exist. But unlikely not for us.

Quote
Moreover, if I install it I know were what is put down, if YUM/RPM does it for you just say some prays.
If you're the one who do not forget anything you're the lucky one. But numerous complaints, tickets and threads prove that the majority of people do not remember that they f.i. installed gcc442.dll in some program directory years ago. They do not even fire up pmdll or similar tools to find out which dlls are necessary nor do the make a search with f.i. 'which -lasu xxxxdll' to find which dll will be used. They do not understand when which copy of a dll is loaded and unloaded nor the consequences of libpathstrict. They only complain that program x 'does not work' or 'does only work sometimes' or simply 'sucks'.

I've installed yum/rpm on my programs partition p: and 'SET UNIXROOT=P:'. So I've no problem with my system partitions. I can use my programs from different eCS partitions without problems with this setup. yum/rpm works for me most of the time flawless. There where some problems which where repaired after I opened a ticket at netlabs or discussed directly at irc channel. Like all our currents software yum/rpm lacks of development and test time AND users who are willing to work with it and give FEEDBACK and create tickets if necessary.
Title: Re: A-Oo 4
Post by: dbanet on July 27, 2014, 01:22:43 pm
Additionally we do have this very bad shared mem problem on our platform. So we have to reuse (share) dlls as much as possible.

This issue has been solved by a tool called highmem (a derivative of January June's above512 made by Paperino), and it is safe to use it since kernel version 14.106_SMP.

Tho not all DLLs can be marked as "loadable above 512", but the majority of them.

For example, I have got all my qt4* DLLs loaded high, and I'm having no problem with this.
Title: Re: A-Oo 4
Post by: Joop on July 27, 2014, 06:54:19 pm
I think you're dreaming of times where we could use OS/2 the way it was designed and neglect this times are over more than 15 years now.
I dream every day and the computer is willing to follow.....;-)
Title: Re: A-Oo 4
Post by: Andi B. on July 28, 2014, 12:04:52 pm
Quote
This issue has been solved by a tool called highmem (a derivative of January June's above512 made by Paperino), and it is safe to use it since kernel version 14.106_SMP.

Tho not all DLLs can be marked as "loadable above 512", but the majority of them.
The issue is not 'solved' and never will be I fear. Loading dlls into highmem is a workaround for this shortcoming but no solution. I like the concept of shared dlls in contrary to 'every app loads a huge amount of code into memory which does nearly the same as other app does'. Moreover even highmem is limited to a few GBytes which isn't that much nowadays if you're forced to run multiple virtual machines as the main OS misses necessary pieces of software.

AOO410 with dlls in highmem runs flawless here. But load Seamonkey and OO310 which is necessary to open old .sdx files and you see nearly no low mem left till next reboot. 1152 currently here only after some minutes after booting and OO31 even closed.
Title: Re: A-Oo 4
Post by: Pete on July 29, 2014, 01:01:24 am
Hi Andi

Where can I - and possibly others reading this discussion - download OO410?

It would be nice to see how it compares to OO4 which works reasonably well here but has some problems.


Regards

Pete


Title: Re: A-Oo 4
Post by: Silvan Scherrer on July 29, 2014, 09:51:31 am
please give us (bww bitwise works GmbH) some more time to brush it up a bit.
We will announce it as soon as we feel it's ready for a wider audience. Right now it's limited to some testers.

More Testers are welcome. If someone feels he is a good tester, please drop me a private e-mail.

regards
Silvan
Title: Re: A-Oo 4
Post by: dbanet on July 30, 2014, 02:55:34 am
Quote
This issue has been solved by a tool called highmem (a derivative of January June's above512 made by Paperino), and it is safe to use it since kernel version 14.106_SMP.

Tho not all DLLs can be marked as "loadable above 512", but the majority of them.
The issue is not 'solved' and never will be I fear.
The solution is very simple: don't allocate low shared or private memory when high shared or private memory may be used.
Title: Re: A-Oo 4
Post by: Dave Yeo on July 30, 2014, 05:06:36 am
Quote
This issue has been solved by a tool called highmem (a derivative of January June's above512 made by Paperino), and it is safe to use it since kernel version 14.106_SMP.

Tho not all DLLs can be marked as "loadable above 512", but the majority of them.
The issue is not 'solved' and never will be I fear.
The solution is very simple: don't allocate low shared or private memory when high shared or private memory may be used.

There's only about 1.25 GBs max of shared and 1.25GBs max of private memory available in the high arena, usually less with the standard 1536 virtualaddrsslimit. Run Firefox, OO and a Java application and that high shared memory is full. Even gets worse with time as memory fragments.
Title: Re: A-Oo 4
Post by: dbanet on July 30, 2014, 05:25:52 am
If an app requests a piece of high shared memory, and that arena is full, the kernel allocates the memory in the low shared one.

I thought we were initially talking about low shared. Well, the amount of high shared memory can be increased by increasing the VAL, as well as the high private. I know people running with VAL=3GiB successfully.

Due to x86, you cannot overcome the limit of the high/low shared memory unfortunately, but each process has got its own private arena, and if you need more memory, spawn more processes (in theory).