Why oh why don't those porting firefox and other programs supply a zip file containing ALL the various DLLs that they use to have it working? That way there shouldn't be the dll hell we appear to have with versions of RPM files from odd experimental repositories or even those not in any repository yet.

License issues probably, some of the GCC libs might be published under the GPL and it cannot distributed in the same package as software with other licenses

Why oh why don't those porting firefox and other programs supply a zip file containing ALL the various DLLs that they use to have it working?

This was discussed numerous times. Maybe the whole process is too complex to understand for simple minded users? I don't know.

Quote

That way there shouldn't be the dll hell we appear to have with versions of RPM files from odd experimental repositories or even those not in any repository yet.

The dll hell starts if you mix your different zipped dlls together and that's the reason why the full rpm way is the only one to go currently. And don't say YOU are keen enough to clean up all dlls which would come with all the different packages manually. 99.99% of the OS/2 users proofed they can not.

The dll hell starts if you mix your different zipped dlls together and that's the reason why the full rpm way is the only one to go currently. And don't say YOU are keen enough to clean up all dlls which would come with all the different packages manually. 99.99% of the OS/2 users proofed they can not.

Thank you, now I know I belong to the group which falls in the 0.01% category LOL.

I have still a P4 system and as mentioned before, there is no libcx0.dll compiled for P4. May be that's the problem.

The exception handler crashed, probably due to Firefox crashing in such a way that the stack or such was corrupted, and since exceptq is supported through libcx... Really you should also have the debug info for libcx to be sure.BTW, the P4 runs i686 code fine, though perhaps a bit slower and for some programs, P4 will use things like SSE which also helps performance.

@Olafur, there is no problem with licensing, the GCC libs are GPL with a linking exception and everything else is more permissive. Those libraries that need an offer of source, well there are source RPMs that are hosted besides the regular RPMs.

@Ivan, the problem is that the direction that Bitwise took with development has resulted in a whole mess of DLLs. I'll attach the DLL tree for the latest Firefox. Some of these DLLs have to be the latest versions as some fixes for Firefox have been applied to them and there are enough inter-dependencies that it quickly can turn into a nightmare manually updating and keeping track of versions. This isn't helped by our old systems DLL support. 8.3 names that have to correspond to the internal name though there is a push to put bldlevel info in all the binaries, they don't all have it yet and some may never get it.I don't really like how development has gone but it is what we have and without Bitwise, our system would be a lot more out of date and less useful.

Firefox 45.9 is longer to start than FF 38.8 but I tried do speed it up using RAM drive - xul.dll is very big ! (29 398 067 bytes)I do a xcopy of my @uniroot\usr\lib\firefox-45.9.0 to @ramroot\lib\firefox-45.9.0 after having added a new program icon named firefox with program path: M:\lib\firefox-45.9.0 \firefox.exe under @uniroot\usr\lib\firefox-45.9.0

this is done by the startup.cmd...md M:\lib\firefox-45.9.0xcopy of my C:\usr\lib\firefox-45.9.0 M:\lib\firefox-45.9.0 /S /Eexit

Than, I run firefox from my RAM drive (created under ArcaOS and using my extra 12MB storage)I found it to be faster to start now. Other dll's have been left on @unixroot

You should be able to copy it to any directory and as long as you run the firefox.exe you copied, it should work. Looks in ..\lib\firefox-45.9.0 and . for its DLLs.SeaMonkey xul.dll is 44 MBs, and 464 MBs before lxlite removes the debug stuff and compresses it.

Tested running SeaMonkey from the ram drive, not much faster here as the bottleneck is all the windows and tabs I have open, it peaks one core for a couple of minutes.What did help was defragging my profile by moving it to a different partition and back. It also helps that it has its own partition. In a default install with MOZILLA_HOME=HOME and installed on the boot drive, room can get tight and things like places.sqlite can get pretty fragmented. Same with large mailboxes.

Thanks Dave for the information. Now the fun begins trying to sort out which implementation of each dll is the one that works - I have found that libcx does not work with anything else unless I have the magic incantation loaded in config.sys. Things should work better when they get the buildlevel info included -I can't help wondering who had the bright idea to try and convert OS/2 into SUSE linux and so create all the problems for all of us that have been using OS/2 from version 2.1.

The last updates to the DLLS for Mozilla was libc, libcx and NSPR so these have to be latest , perhaps second to latest for libcx. Just check POPUPLOG.OS2 for sys2070, probably the wrong libcx will give something like

Now the fun begins trying to sort out which implementation of each dll is the one that works

While my setup may not be perfect (e.g. Lucide has to be started an even number of times, JPEG.DLL in a JAVA142 subdirectory, no latest FF for ArcaOS, no RPM), nowadays getting it right isn't that hard, as long as the system is managed properly. An OS/2 system, i.e. not a Unixified ArcaOS system: if I want Unix, I'll start using Unix.

For example, I've got just 2 copies of Z.DLL by now. The exception is Links, which uses its own copy, and IIRC its WarpIN installer doesn't use the BEGINLIBPATH and LIBPATHSTRICT settings to account for that. So patch the install script, or Rexxify the install script to replace the WarpIN install script. Of course each distributed package with an own Z.DLL has to be checked, but apparently the typical result is that its Z.DLL can be deleted.

I do wish I had recorded which packages are using DLLs like LIBVPX*.DLL, because I'm not sure if I can delete LIBVPX3.DLL and/or LIBVPX4.DLL by now. And I tend to not install hardly ever used software with an excessive number of requirements. GIMP may be an example, despite of packages to install requirements, with Win/OS-2 and Photoshop 2.51 as an abandonware-alternative.

Thanks Dave for the information. Now the fun begins trying to sort out which implementation of each dll is the one that works - I have found that libcx does not work with anything else unless I have the magic incantation loaded in config.sys. Things should work better when they get the buildlevel info included -I can't help wondering who had the bright idea to try and convert OS/2 into SUSE linux and so create all the problems for all of us that have been using OS/2 from version 2.1.

Tha basic gist is that BWW said that the stand alone files in ZIP and install requirements was costing about 8 hours of support per week in tickets. If you take in consideations that software and downloads are provided free of charge. ..With lack of human man power they had to make chooses.

Plenty of people are using ArcaOS without much issue's. The bottom line is the ported applications need these DLL's. I do not know how you can keep the ported DLL's off OS/2 if you want to run modern ported applications.

"Plenty" nor democracy is a standard and they weren't producing a "FF for ArcaOS", isn't it?

An option may be to stop (specific) support if RPM or whatever installer wasn't used. Surely RPM.DLL, optional and not required, will appear in a *.TRP file

All I'd expect is a "FF for OS/2", for all relevant P6+ OS/2 hardware, without requirements of useless requirements of requirements of requirements. Part of the problem is that both the English and German speaking community have a recent OS, eCS 2.x DE/EN or newer, and they are the developers with their own standards.

Another example is ooRexx for their OSes. Or our new included software, often not related to an OS at all, which isn't distributed as a "FixPak" for older versions. Like Unicode fonts, if AN is supposed to add those fonts to ArcaOS. There is no good release management (own copy of Z.DLL in any LIBPATH directory, OS upgrade can en will create a mess), and I'm still the human package manager w.r.t. single CPU core hardware. I have no OS for two or more cores, so in the future it's possible that it's easier for your "plenty of people" to win the general OS elections.

Well if you would read the readme file of Firefox for OS/2 it says the RPM package is downloadable via your ArcaOS subscription.

Anyway if you know how to do it better outline your plan or call BWW to provide vast quanties of sponsorship.

Saldy most OS/2 and eCS versions published are indeed what you can use them for, for retro computing. Such as on a T42 laptop. It works for you that is great. Otherwhise good luck booting eCS 2.1 on new Thinkpad T540d.