Author Topic: A-Oo 4  (Read 15523 times)

Joop

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 65
  • Posts: 591
  • Karma: +1/-0
    • View Profile
Re: A-Oo 4
« Reply #15 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. 

dbanet

  • Guest
Re: A-Oo 4
« Reply #16 on: July 27, 2014, 01:21:59 am »
DLLs should be shared.

Eugene Tucker

  • Full Member
  • ***
  • Thank You
  • -Given: 59
  • -Receive: 10
  • Posts: 155
  • Karma: +5/-0
    • View Profile
Re: A-Oo 4
« Reply #17 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.

Joop

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 65
  • Posts: 591
  • Karma: +1/-0
    • View Profile
Re: A-Oo 4
« Reply #18 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.

dbanet

  • Guest
Re: A-Oo 4
« Reply #19 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.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 221
  • Posts: 3105
  • Karma: +53/-0
    • View Profile
Re: A-Oo 4
« Reply #20 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.

Thomas M.

  • Newbie
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 22
  • Karma: +0/-0
    • View Profile
Re: A-Oo 4
« Reply #21 on: July 27, 2014, 10:19:12 am »
Thank you very much, Boris.

Thomas

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 27
  • Posts: 587
  • Karma: +6/-1
    • View Profile
Re: A-Oo 4
« Reply #22 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.

dbanet

  • Guest
Re: A-Oo 4
« Reply #23 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.

Joop

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 65
  • Posts: 591
  • Karma: +1/-0
    • View Profile
Re: A-Oo 4
« Reply #24 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.....;-)

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 27
  • Posts: 587
  • Karma: +6/-1
    • View Profile
Re: A-Oo 4
« Reply #25 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.

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 51
  • Posts: 1096
  • Karma: +4/-0
    • View Profile
Re: A-Oo 4
« Reply #26 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



Silvan Scherrer

  • Full Member
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 9
  • Posts: 184
  • Karma: +1/-0
    • View Profile
Re: A-Oo 4
« Reply #27 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
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

dbanet

  • Guest
Re: A-Oo 4
« Reply #28 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.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 221
  • Posts: 3105
  • Karma: +53/-0
    • View Profile
Re: A-Oo 4
« Reply #29 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.