It's seems you cannot read. This forum area topic is about "Applications". You have no better to do than spreading fake news here. The current situation under OS/2 is a total disaster for end users of your "ported" applications. It's a fatal mixture of breaking compatibility, introducing new unstable interfaces, slovenliness and unkindliness etc.

I will simply ignore your sophistic attempts to drive this discussion off topic. Only one point regarding AIX: Even 20 years ago it was much easier to compile a application there, than using now an application dongled with your YUM/RPM requirements.

Quote

They appear ridiculous only if you missed the most important point. I bet you will not guess which one I meant. Just go through my writing once more and do a careful reading.

Nonsense. A news with an example as source hardly qualifies as fake news...

Quote

The current situation under OS/2 is a total disaster for end users of your "ported" applications.

More Trump-speak. More nonsense. Simply a blatant lie.

There are 2 ways to successfully run applications on a modern OS/2 system:

1.) Go the RPM/YUM way. Stuff simply works in most cases.2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.

Regarding Andreas Kohl: I have been advised to ignore his niggle and utter nonsense. He constantly fails to substantiate his claims anyway.

To support Andreas' case, he has one, OS/2 doesn't rely on a human package manager. Operations do. It may be hard for an engineer to understand that their Usenet trolls have to manage more than one system, while trying to avoid the DLL hell of DLLs like JPEG.DLL and Z.DLL.

Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you. That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products. If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.

Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.

So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".

So you're on your own then. While you're on your own, you may as well become the human package manager if the environment isn't that simple. It's easy to install an approved DLL. It's harder to uninstal the possibly destructive output of the random update policies of some random digital package manager, which works fine for "the average home user of selected products".

In the case of older hardware, the capacity of harddisks plays a role too. I'm pretty sure that a package manager isn't that aware of likely disk full-errors. If there's no eCS 1.x, eCs 2.x nor ArcaOS in the right language, then newer hardware isn't an obvious solution.

That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.

If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.

In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.

So please try to keep anyl Y2K-proof version of OS/2 Warp, settings of WPS objects and continuity of operations in mind while advocating that "one solution" (of some products) is "the solution" (of all products, languages and/or situations). Releasing qualifying updates for all OS/2-based products would help, but that won't solve all possible issues. If a new component really has to be added to ArcaOS, like a font, Unix directory structures or a package manager, then please consider releasing such a product as an update for all OS/2-based products. By default a simple install of OS/2 Warp 4 has no Unix directory structure, package manager, and so on.

So there's no such thing as a working "FF for OS/2", regardless of perfect and impressive OS/2 binaries. Install and update OS/2, install the FF package, and it won't work. The README.OS2 will result in a SYS1041 error.

OS/2 Warp (no FP for all OS languages), eCS 1.x (a few languages), eCS 2.x (fewer languages) and ArcaOS (EN only) are different products, each leaving a part of the community behind. In the case of ArcaOS EN perhaps a part of the German community too, slowly. The one and only package manager is a solution for the happy few. I guess availablity of ANPM is excellent, but that doesn't imply that everyone is willing to allow a random digital package manager, with random update policies, without detecting all possible OS/2 setups, to manage their packages.

Regarding applications, the number of quickly ported "OS/2" application which assume some eCS 2.x or ArcaOS setup is increasing. There is no "eCS 2.x setup for OS2" package, if you'd want such an environment in the first place. Or need such an environment. Often you can copy all files to one directory and keep the bootdrive clean, but not always. If not, then the required environment should have an added value for OS/2. Often it has no added value at all.

Of course the irrelevant, perfectly fine product WarpIN isn't the answer. A disadvantage of a (anything but perfect) WPI version of the FF products is that you may have to backup both the large WPI file and the large installed files. And, of course, WarpIN is a kind of package manager with its own policies. Here the human package manager typically extracts and converts the (sometimes anything but perfect) WarpIN install scripts to Rexx install scripts. If the results are identical, then managing and backing up the small Rexx install scripts is prefered above having to backup the whole original archive too. Fonts are a common exception (bootdrive files without a backup of the installed files, INSTFONT).

IIRC the game QNetwalk is an example of a Unixified app. It's improved significantly, but it uses a Unix directory structure. I guess just because Unix-based tools were used. Without any added value compared to an OS/2 or eCS 1.x x:\OS2GAMES\QNETWALK setup.

There are 2 ways to successfully run applications on a modern OS/2 system:

1.) Go the RPM/YUM way. Stuff simply works in most cases.

YUM relies on IP connectivity and a quite large Python language environment. We would use here RPM, but in the current form it's not an easy process. I could not find any documentation about the installation of RPM without yum. Unfortunately your "simply works" means in real world the lack of any documentation that would help the operators.

Quote

2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.

Quote

This advise is not totally wrong, but it cannot resolve all dependencies or compatibility issues.

This is just a friendly reminder, everybody has their own opinons and their preferences of how to use or interact with a personal computer. The user is free to choose how they want to work with OS/2 and the developer is also free to select what is his best way to produce software.

We already have the discussion about RPM/YUM vs WarpIn so many times. I don't think we should start over with it, but if someone think it is needs to be discussed please open a new thread.

On the other side I always dislike how some people uses lightly phrases like "you are spreading fake news", "you are suffering from blatant illusions", "you are dreaming in technicolor", "you belive in fairytales" or the simple statement in CAPS like "YOU ARE WRONG" without explaining anything. I think there are better ways to communicate with others without labeling the other party.

If you explained your reasons politely and the other party does not understand or not share your point of view just "agree to disagree".

Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you.

Sorry, but that's a wrong assumption. My observations are made on systems that are generic IBM OS/2 Warp 4 or Warp Server for e-business installations with latest fixes applied (if required). And I'm aware of minor differences between NLS versions.

Quote

That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products.

The so-called ported software from RPM packages is only tested under an US OS/2 Warp 4 MCP2 environment. Most of the included localisation that got installed (without the option to disable unwanted locales) is simply not usable or unreadable on specific NLS target systems because of wrong text encodings.

Quote

If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.

As I worked in the past for an account in Spain and France my experiences are different. For client stations the french MCP1 or MCP2 can be used. But I cannot remember exactly if it was only Canadian French installation media set to an European locale for France. I can a look at it soon.

Quote

Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.

There are a lot of inconsistencies in dynamic linking and it's consequences regarding the memory management. The lack of reliable development tools is only one of the reasons that leads often to strange behaviour of the generated application. The average user will only notice slower performance and faulty graphics in most cases. The biggest bottleneck with mozilla apps seems to be now I/O and not CPU performance.

Quote

So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".

In my opinion it's a misuse of the Firefox brand, but who cares? Usually beta versions should use a different branding.

Quote

That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.

I cannot follow the idea behind the @unixroot thing. It's only required by fontconfig which has hardcoded paths. I can only guess that this "feature" was only tested with JFS volumes.

Quote

If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.

By only reading reports from German eCS 2 users I cannot agree with you. I have only eCS 1.2 (but not installed).

Quote

In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.

I don't know where are the figures from. But it does'nt have any relevance for OS/2. Approx. 60-70% of existing installations are German NLS of different OS/2 product levels. And even communication with IBM Austin (15 years back) could be done completely in German. I agree with you that NLS should be improved. Forcing users from South Africa for instance to use an English OS/2 is not polite.

- We are testing on a mix of several language based OS/2 versions. Usually the language does not really make a difference (except SBCS vs DBCS or cyrillic issues which happen to creep in from time to time).

- A working IP connection to the internet (or any other network) is NO must have for RPM/YUM. An installed IP stack is a requirement. Python is a requirement, too.

- The DLL hell is a reality on ALL operating systems. It simply does not make sense to statically link every single requirement and thus reduce the number of required DLLs. The reason is that architectural constraints especially on our platform make that a bad idea being the source for more problems than you can imagine. We have been there. A statically linked FF does not work on OS/2 anymore. Niggling about the DLL hell and how bad it is, is as useful as niggling about the color of the sky. You don't like the DLL hell? Me neither. And I like to think about the times when "our" OS did not have it. Too bad these times are simply gone.

For those who have to operate a standalone machine that is not connected to the internet, it is possible to use RPM/YUM locally only. It is advisable to create a local RPM repo, disable the netlabs and ArcaNoae repos, copy any installation package to the local repo and let YUM install it from there.

I need to check how good and simple the docs for that scenario are, if they are not good enough, I will overhaul them.

Hi ivan, fwiw there is more than person testing on AMD machines. I know of three others who also test AMD's. I test on AMD 4 & 8 core boxes, both running ARCAOS as host. I also test on an Intel box (Lenovo) and the results are pretty much the same so far for both. Some problems, yes, but a huge improvement over eCS.

Hi Dariusz, So far I have never seen this problem on either of my AMD boxes. One frustrating problem I have encountered that occurs on AMD boxes is the "age old" sagging desktop icons. This is not a problem on my Intel box.

Apparently it is triggered by (but not caused by) using the XCenter Reduce Desktop workarea setting. The movingdesktopobjects thing does "fix" the problem, but that only works when you run it. The trick seems to be to either not use the Reduce Desktop workarea setting, or run movingdesktopobjects at every shutdown. You can do that using the XWorkplace shutdown folder. All it does, is remove the (defective) desktop settings, which are recreated (correctly) at the next boot. The exposure is that a crash won't run the movingdesktopobjects program, but it also won't save the defective settings.