Author Topic: Firefox 31.8.0 Beta 5 - First Impressions  (Read 25423 times)

Jan-Erik Lärka

  • Global Moderator
  • Full Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 13
  • Posts: 176
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #45 on: August 11, 2015, 08:06:45 am »
This is a script to solve the problem.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 10
  • -Receive: 134
  • Posts: 1948
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #46 on: August 27, 2015, 05:15:11 am »
Be nice to add some logging as it runs fast with just output from unlock and upload it to Hobbes or such so it is easier to refer people to the script

Jan-Erik Lärka

  • Global Moderator
  • Full Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 13
  • Posts: 176
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #47 on: August 27, 2015, 12:01:04 pm »
I'll think about that. My approach was to deactivate/rename .dlls in use in wrong library folders rather than rewriting config.sys. Would you like my script to pause in the end perhaps, not show the unlocking part but rather just the file names it work on?

Yumie that Alex Taylor is working on should take care of it all.

Yumie is not complete yet, but it look quite nice and provide a gui for rpm and yum. I sure hope to see a version out really soon so that we can begin to use it and let some parts be developed/tuned/activated later as it mature.

//Jan-Erik

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 10
  • -Receive: 134
  • Posts: 1948
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #48 on: August 28, 2015, 05:15:37 am »
It's nice to be able to review the changes your script does. When I tested it, it ran so fast and all I saw was a bunch of unlock output and as the DLLs weren't locked it wasn't very informative. BTW your script should also have a license header.
As for Yumie, the latest just checks if @UNIXROOT\usr\lib is at the head of LIBPATH and offers to change it.  (GUI to disable to be added)Your approach has advantages and so does Alex's. Both don't take into account that it is also correct to have @UNIXROOT\usr\local\lib having preference over @UNIXROOT\usr\lib as advanced users may want to manually install DLLs, eg I did this when I updated Freetype.
Yumie also needs documentation written.

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 44
  • Posts: 1169
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #49 on: August 28, 2015, 05:50:27 am »
Quote
Yumie that Alex Taylor is working on should take care of it all.

I hate to say it, but no, it won't.

Yumie makes using RPM/YUM possible, for the average user. It does not perform miracles. It does not eliminate all extra DLLs that programmers have kindly supplied with their work, which makes it all too easy to have duplicate, down level, copies, and they don't even need to be in LIBPATH to cause problems (remember the '.' dot entry). A quick look at dllCleanOut.cmd indicates that it only checks LIBPATH for duplicates (it appears to do nothing on my systems, but I already took steps to eliminate what I could find). It needs to check the whole file system, but that is complicated because a user may have a second (third...) boot drive, where it may be correct to have duplicate (even down level) files. The user may also have some place where they store those things, and that may be okay (as long as nothing actually uses them). Even starting with a clean eCS 2.2.b2 install, which includes RPM/YUM support, leaves junk behind, that shouldn't be there. Starting to use RPM/YUM after using a system for a while is even more complicated. Yumie also has trouble when YUM screws up (and it does that all too often). Usually, the user will need to do some manual repair when that happens.

Yumie works great, when YUM works, and after a user has cleaned out what shouldn't be there, but it certainly won't take care of it all.

dllCleanOut.cmd seems to be a good start, but I think it needs to go deeper to find all of the duplicates (which are usually down level). Speed of operation is not very important, since it should be a one time run, but it is important to get all of the files (and not take out the ones that a user wants to keep for one reason or another).

Jan-Erik Lärka

  • Global Moderator
  • Full Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 13
  • Posts: 176
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #50 on: August 28, 2015, 08:10:28 am »
Yumie should be extended further to address the problems that every day users face. The script dllCleanOut may hopefully with your help provide a base how to take care of files that yumie doesn't take into account yet.

I can try to extend the script further. The idea behind dllCleanOut is to look in the usr\lib folder for dlls and then search for each dll in the libpath (excluding usr\lib) and unlock duplicates and rename them. The dll files in usr\lib will be loaded after the next reboot.

Please tell me how the script should search the system to determine what should be left and what should be renamed. Feel free to provide functions to take care of whatever has to be taken care of and I'll try to glue it all together.

//Jan-Erik

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 20
  • Posts: 417
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #51 on: August 28, 2015, 08:58:36 am »
Quote
...a bunch of unlock output and as the DLLs weren't locked it wasn't very informative.
If you want to suppress unlock output you can use the unlock.exe included in ftp://ftp.netlabs.org/pub/wlan/xwlan312beta3.zip with >>NULL. Unfortunately all unlock.exes shipped with recent eCS have broken output redirection.

Joop

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 40
  • Posts: 458
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #52 on: August 28, 2015, 01:19:02 pm »
and they don't even need to be in LIBPATH to cause problems (remember the '.' dot entry).
As far as I know the "." dot entry translates as active directory. So if you have DLL's in other drives, directories  which are not in your config.sys, then they should not disturb the process. I have more problems in identifying DLL's if they are the right version and with the latest distribution for FF needed dll's it seems that certain dll's are smaller, have lower version numbers etc. This gives a puzzle. Thanks to config.sys and the way it works we can update dll's in a very easy way which is not seen in other OS systems. But for some reason we don't want to make use of it. To do so you need to make a statement in what directory the OS/2 natives are hold (\OS2\DLL seems most logic) and all what's added afterwards and needed by programs (\ECS\DLL seems to me most logic). But as stated before, not one OS/2-eCS installation will be the same. So I don't see the need for a YUM, but I see the need for clear identification of DLL's, so everyone can copy the right one in the right directory. As those paths are already in the config.sys your ready after a restart. And we have to stick to that deliberate copy a file and a restart in order to stay free of unwanted software which comes thru your internet connection by accidental clicking on the wrong link or so.  Just my two cents...

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 404
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #53 on: August 28, 2015, 03:23:43 pm »
As far as I know the "." dot entry translates as active directory. So
if you have DLL's in other drives, directories which are not in your
config.sys, then they should not disturb the process.
Not true. DLLs were only unloaded on exiting an app. If you open
another app wich requires a DLL with the same name, the function were
taken from the already loaded DLL. That's the reason why program
packages should never hold commonly used and shared DLLs in there dir
tree. Only those DLLs should be better installed to a common dir.

Unfortunately our OS doesn't came with a DLL or packet manager that
controls each of these files. Solutions were developed, but either
have too many flaws or are still not fully accepted.

I have more problems in identifying DLL's if they are the right
version and with the latest distribution for FF needed dll's it seems
that certain dll's are smaller, have lower version numbers etc.
There exists the 8.3 limitation for DLLs. Therefore sometimes the
filename can't contain the entire version number.

Thanks to config.sys and the way it works we can update dll's in a
very easy way which is not seen in other OS systems.
That's not true. That would be possible for all other OS, too. Plus
most of them support long DLL names and symbolic links.

but I see the need for clear identification of DLL's, so everyone can
copy the right one in the right directory.
That tool doesn't exist yet. Additionally, there exist too many older
packages that are linked to DLLs without version numbers in their
filenames. It just won't work now if you just copy everything to one
dir. You have to DLL-rename all these older packages first.

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 44
  • Posts: 1169
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #54 on: August 28, 2015, 05:01:53 pm »
Quote
Yumie should be extended further to address the problems that every day users face.

Doing that is why Yumie is still not available. Remember that Yumie simply operates YUM, and YUM does not always return intelligent information when it fails, which means that Yumie would need to implement a lot of artificial intelligence to figure out what went wrong. A few of the more common failures are handled, but even then, it seems to be impossible to fix some problems. For example, all of my test systems complain that the RPM database is corrupted, every time I download something. There is really no problem, whatever it is gets properly installed, and all of the suggestions about how to fix the database don't fix the problem (which is probably not a database error anyway). It looks like the only answer is for Yumie to ignore the error, but doing that may miss a legitimate error.

Quote
Please tell me how the script should search the system to determine what should be left and what should be renamed. Feel free to provide functions to take care of whatever has to be taken care of and I'll try to glue it all together.

That is somewhat difficult. There are two major divisions. One is using RPM/YUM (with, or without, Yumie). The second is not using it (and there are many good reasons not to use it, but the main problem can still exist). Then there is a minor division, where a user has eComStation, or not. Less common, is where a user has made their own location to contain all of the RPM supplied DLLs (and that doesn't need to be on the boot drive). So, your script needs to determine if RPM/YUM is actually installed, and USED. Then, it needs to make the YUM stuff the first choice (if it is actually used), accounting for the user preference of the order of @UNIXROOT\usr\local\lib and @UNIXROOT\usr\lib (and they don't need to be on the boot drive). followed by what is in <bootdrive>:\OS2\DLL and <bootdrive>:\eCS\DLL (assuming that a user hasn't moved them around). All duplicates in any of those locations need to be resolved (there should be only ONE, and it should be the latest, but you can't depend on file size, or date, to determine that, and there is no bldlevel information, which should be easy to add, if those who supply the files would just do it. Then, you need to scan the rest of the system (ignoring alternate boot drives), and eliminate anything that is in any of those (call them "master") directories. Of course, you need to ASK the user what to do about duplicates because they may have a reason to keep something (which is okay, as long as they understand the consequences).

I want to emphasize a previous post about uninstalling the RPM/YUM WarpIn installer (using WarpIn), after running the initial YUM INSTALL YUM command. That command actually installs RPM/YUM, using a temporary, very down level, version of RPM/YUM. If you continue to use the "console", you will be using that very down level version, and it doesn't work very well. You need to use the standard command line window, or Yumie (when available) to use the updated stuff.

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 33
  • Posts: 906
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #55 on: August 28, 2015, 05:52:24 pm »
Andreas.

Quote
There exists the 8.3 limitation for DLLs. Therefore sometimes the filename can't contain the entire version number.

I would have thought that the simple answer to that limitation would be to insert BLDLEVEL information into the DLLs.  That way there can be no confusion and it should be very easy to find out if the correct DLLs are there, or is that too easy?  From my engineering background that is the type of identification we do on a daily basis.

Joop

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 40
  • Posts: 458
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #56 on: August 28, 2015, 09:23:42 pm »
Not true. DLLs were only unloaded on exiting an app. If you open
another app wich requires a DLL with the same name, the function were
taken from the already loaded DLL. That's the reason why program
packages should never hold commonly used and shared DLLs in there dir
tree. Only those DLLs should be better installed to a common dir.
I was referring to one DLL directory for programs. I downloaded shortly a program which should hold the latest in DLL, but I had already the same DLL with a higher version number and a different size. However inside you can't find version number, production date or anything which could identifying what is true latest file.

There exists the 8.3 limitation for DLLs. Therefore sometimes the
filename can't contain the entire version number.
This comes from a program written before even the PC-XT was born;
Version 3.35, Serial Number 6335S00194
Copyright (C) Brown Bag Software 1986-90. All Rights Reserved
So your statement won't hold.

but I see the need for clear identification of DLL's, so everyone can
copy the right one in the right directory.
That tool doesn't exist yet.
That tool is called brain, fingers, eyes and reading a clear instruction.

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 404
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #57 on: August 29, 2015, 10:45:06 am »
I would have thought that the simple answer to that limitation would
be to insert BLDLEVEL information into the DLLs.
The buildlevel is ignored when DLLs were loaded. Therefore it can't
help reliably with loading the correct versions.

Additionally, even many files compiled by IBM don't have that info
built in.

That way there can be no confusion and it should be very easy to find
out if the correct DLLs are there
Finding means an additional process. Moreover, you need a package
management system (or similar) for the info which app requires which
DLLs and which ones are available. That's nothing for the end user
having just a simple installer.

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 33
  • Posts: 795
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #58 on: August 29, 2015, 01:52:59 pm »
Hi Andreas

The BLDLEVEL information could be checked by the user to ensure they have the required DLL file specified in the readme file supplied with the app. Of course, that also requires the readme file to be up to date and accurate regarding the apps requirements.


Regards

Pete

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 404
    • View Profile
Re: Firefox 31.8.0 Beta 5 - First Impressions
« Reply #59 on: August 29, 2015, 05:06:41 pm »
Would you like my script to pause in the end perhaps, not show the unlocking
part but rather just the file names it work on?
I would just create a log file to list all changed filenames.

Additionally, the script could report at the end how many files were changed
and give a useful return code, e.g. 0 = NO_ERROR if files were changed and
2 = FILE_NOT_FOUND if no file was changed.

Yumie that Alex Taylor is working on should take care of it all.
Good idea. I would add a bug report for that on https://mantis.arcanoae.com
« Last Edit: August 29, 2015, 10:17:08 pm by Andreas Schnellbacher »