OS/2, eCS & ArcaOS - Technical > Internet

Firefox beta 4 released

<< < (6/6)

eirik:
So, by installing Apache Open Office 4.1.1.1 (a follow up to the 4.1.1 GA) the missing DLLs should be in place?  Makes sense because in a few instances I am unable to load OO 4.1.1 GA when Firefox 24.8.1 (B3) is running.

Thanks to all doing good work making this possible.  Still, I must admit I much prefer Warpin over rpm yum (which to me looks very archaic). 

Easy installation and maintenance is an important aspect of attracting more users (together wit working drivers, Fn+Fx working (for those of us who use eCS at work on Thinkpads, Fn+F7 is particularly relevant - it would enable me to use my eCS partition when I lecture to students - now I have to switch to my Win7 partition which is not the way to spread the good eCS word)

Doug Bissett:

--- Quote ---So, by installing Apache Open Office 4.1.1.1 (a follow up to the 4.1.1 GA) the missing DLLs should be in place?
--- End quote ---

Probably not. There is more to it than what is in the AOO4111 installer stuff. If you used AOO-4111-GA-rpm.wpi, and let it install those DLLs to the AOO4 program directory, those DLLs are in the wrong place, and will only be found by AOO, and only if AOO happens to be the first program to use them. All of those files need to be in either eCS\DLL, or OS2\DLL (depending on what you are using), so all programs can find them.


--- Quote ---Thanks to all doing good work making this possible.  Still, I must admit I much prefer Warpin over rpm yum (which to me looks very archaic). 
--- End quote ---

I am working on a WPI installer, for FF 24.8.1 b4, but the new requirements are being problematic. Since it appears that none of the stuff managed by YUM has any BLDLEVEL information, it is impossible to tell what version of the required DLLs that a user has installed (dates don't mean much). That means that it will be necessary to install all new, whether they are already there, or not (just to be sure). That causes two problems. One is that a user may have installed some, or all, of that stuff somewhere else (that is just asking for trouble), and some older WarpIn installers may have been used, so I need to figure out how to correct the WarpIn database, when I install things that have previously been packaged by others. Without doing that, a user is going to have trouble with the WarpIn database later. I also need to consider what other programs require, and there is always the possibility that updating something for Firefox, or AOO, will break something else (especially if the DLLs are duplicated, or in the wrong place). Then, there are some partial packages out there already. One, that I know about, packages the new GCC1, but only two of the many forwarder DLLs (AOO-4111-GA-rpm.wpi does the same thing). Doing that means that the user has an incomplete install of the GCC1 stuff, and that could come back to haunt the user later.

Currently, if you want that stuff managed, you need to use YUM. YUM keeps a database of what it installed. The biggest problem (other than the horrible YUM interface) is that a user can change something, and YUM may not know about that. YUM also creates a whole new place to keep stuff (the *NIX directory structure), and leaves behind whatever was already installed in other ways. That results in duplicates, and, eventually, some program will try using the wrong one. That will cause the old "sometimes it works, and sometimes it doesn't" problem. Very difficult to determine what is going on. The only ways to keep that stuff under control is to start with a newly installed system, with RPM/YUM already installed, then do not ever update anything unless you use YUM (that becomes a problem, because not everything is packaged for YUM). OR, you can manually clean out everything that YUM didn't install. That means that you need to know exactly which files YUM controls, and leave behind all others (which are probably program specific). Then, you need to do that again, every time YUM adds something new. It is a logistical nightmare for OS/2 users, whether you use YUM, or not.


--- Quote ---Fn+Fx working
--- End quote ---

That is probably part of ACPI. I am pretty sure that the ACPI function exists, but we have no program to use it.

I will also note, that I have been refused access to more than one web site, recently, with a notice that I need to update my browser. FF in windows is now at v 36.0.1. This is probably just stupid web design (driven by paranoia), but it does mean that I need to use windows to get to that stuff. Fortunately, the current FF for OS/2 works for most things, for now.

I will also note, that the new FF seems to get along better with other bloated ported programs (AOO4) than the older versions did. It is said that the FF DLLs (including XUL.DLL) can now be loaded high, but it is not clear if that is already done, or if a user needs to do something to get that to happen. Anybody know?

OS4User:

--- Quote from: Doug Bissett on March 12, 2015, 05:19:49 pm ---It is said that the FF DLLs (including XUL.DLL) can now be loaded high, but it is not clear if that is already done, or if a user needs to do something to get that to happen. Anybody know?

--- End quote ---

https://github.com/bitwiseworks/mozilla-os2/releases

.... XUL.DLL finally loadable into high memory (using e.g. this tool https://www.dropbox.com/sh/350r8h2dpuxsg8w/AABAiWkeaXL45H00M7SUJTCKa/aoo/highmem-20140406-os2.zip?dl=1)....

so you need a tool  to load xul.dll into HMA

Doug Bissett:

--- Quote from: OS4User on March 12, 2015, 07:10:30 pm ---
--- Quote from: Doug Bissett on March 12, 2015, 05:19:49 pm ---It is said that the FF DLLs (including XUL.DLL) can now be loaded high, but it is not clear if that is already done, or if a user needs to do something to get that to happen. Anybody know?

--- End quote ---

https://github.com/bitwiseworks/mozilla-os2/releases

.... XUL.DLL finally loadable into high memory (using e.g. this tool https://www.dropbox.com/sh/350r8h2dpuxsg8w/AABAiWkeaXL45H00M7SUJTCKa/aoo/highmem-20140406-os2.zip?dl=1)....

so you need a tool  to load xul.dll into HMA

--- End quote ---

Well, that isn't quite what I asked, but it does, indirectly answer the question. I have now set all DLLs in the Firefox directory, to load high. So far, it looks good.

Neil Waldhauer:

--- Quote from: Silvan Scherrer on March 12, 2015, 06:59:46 am ---
--- Quote from: Neil Waldhauer on March 12, 2015, 04:30:37 am ---I installed this using yum to process prerequisites. I had to track down a DLL that was a wrong version (stdcpp6.dll) I imagine this is due to a mix of yum and non-yum installs that happen over time.

Firefox seems to work well. I miss the sound library that Dave Yeo had added to his version.

--- End quote ---
We know about the sounds stuff. And you can be sure we add that soon. But we will not add the old, not anymore supported by mozilla version, which Dave used.

regards
Silvan

--- End quote ---

Thanks Silvan, for an excellent port!!! I have used this today and it's running very well.
 8)

Navigation

[0] Message Index

[*] Previous page

Go to full version