Closed Bug 275436 Opened 20 years ago Closed 20 years ago

OS/2 packages should contain a helpful ReadMe file

Categories

(SeaMonkey :: General, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla, Unassigned)

Details

Attachments

(2 files, 3 obsolete files)

(Sorry, don't find a component that makes more sense.)

Currently, OS/2 packages contain (ZIP packages) or even display (Installer
distributions) a file ReadMe.txt that is not very helpful on OS/2 as it only
contains infos for the tier 1 platforms. The problems that are frequently asked
in the newsgroups, like concurrent running of two Mozilla products, should be
adressed. At least it should contain hints to webpage(s) with tips and some
rules where to get Run!, ConfigApps, and how to set up a CMD file with
LIBPATHSTRICT. Platform requirements that are currently only given on a webpage
would be nice, too.

This similarly applies to Firefox and Thunderbird and may be even more needed there.

I will try to come up with a text in the next days, then it should be discussed
how to get the file into the packages. (Is it enough or clever to just overwrite
the current readme.txt with the OS/2 version before zipping up the package or
the installer EXE? Or just add another file "ReadMe.OS2" to the package and
change the installer to display that?)
Actually, there is support for copying a different readme during the install.

http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/Makefile.in#473
Attached patch necessary code changes (obsolete) — Splinter Review
This is the small patch with the two necessary code changes, I would have
thought there are more, but with these two the ZIP package and the installer
both get the new readme if it gets checked in as "mozilla/ReadMe.OS2".
Attachment #169671 - Flags: review?(mkaply)
A first go at the text (for some reason cvs diff -N did not work to make it a
patch).

I removed the Windows/Linux/Mac specific stuff, kept the rest, and added what I
think might be helpful. I used part of the requirements listed on
http://www.mozilla.org/releases/mozilla1.7/installation-ports.html#ports_os2
but I didn't like the huge space requirements listed there. If this new text
gets accepted the webpage should be changed accordingly.
Felix, Steve, Rich, I would like your input here. Please take a look at the new
OS/2 readme file attached to this bug. Any ideas how to present this so that
most users actually find the last paragraph?
"The program automatically ends any running Mozilla sessions"

Is this part actually true on OS/2?  I seem to recall the isntaller crashing on
me once because of an open session...

Way back in the Mozilla 1.0 era, there was a readme.os2 file included - Mike,
why was that removed?
I never "install" if I can unzip, so I don't know the answer to Steve's
question. I've never used a Mozilla installer on OS/2.

Can the installer be made to automatically launch the readme file in E.EXE
before it begins actually doing anything?

I've not run Moz on OS/2 at under 400 MHz in a long time. Leaving it up for days
at a time for me means upwards of 200M RAM consumption. I typically see around
250M freed on shutdown after uptime of 3-4 days. Recommending more than 256M and
more than 800 or 1200 MHz seems more realistic than 400 MHz & 128M.

We might also want to note the workaround for bug 167884: in userContent.css put
'* {background-attachment: scroll !important;}'.
(In reply to comment #5)

> Way back in the Mozilla 1.0 era, there was a readme.os2 file included - Mike,
> why was that removed?
> 

Mainly because it involved a manual process - the builds now are all done with
one or two build commands - I don't tweak them.

We can certainly retrive that old readme file and see if there is anything
interesting in it.
(In reply to comment #6)
> Can the installer be made to automatically launch the readme file in E.EXE
> before it begins actually doing anything?

Actually the installer has a button for displaying the readme.
If I remember correctly, the right place to put this file would be in the README
subdirectory, rather than the root.
>Place them [LIBC05] in the same directory as Mozilla's executable,
>or somewhere in your LIBPATH.
IIRC, the current packaging puts them in \os2\dll automatically.  You might
mention this & comment that they can be moved to the Mozilla directory if desired.

> Minimum hardware requirements [...] Recommended hardware for good usability
Face it, Moz on a P133/64mb would probably be unbearable.  I would drop the
first section & retitle the second "Minimum hardware for acceptable
performance".  Also, a comment that Mozilla's performance & stability increases
markedly with more memory might be appropriate.

> Software requirements
>  + OS/2 Warp 4 with Fixpack 15
Just a nit, but I'd add "or later" (yes, I know CP2/eCS is mentioned below).

> Running multiple versions of Mozilla concurrently
Much as I like to explain things at length, I'd cut back on the verbiage.  E.g.
 "Because various members of the Mozilla family (i.e. Mozilla, Firefox,
Thunderbird) may use different, incompatible versions of the same dll, some
extra steps may be required to run them concurrently."

Here's the script I would recommend:
   set LIBPATHSTRICT=T
   rem the next line is only needed to run two versions of the same program
   rem set MOZ_NO_REMOTE=1
   d:
   cd d:\internet\mozilla
   mozilla.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

IMHO, this reinforces the understanding that PATH & LIBPATH entries are not
needed when the exe is in the current directory.

> the most sophisticated method is to use the Run! utility
Sophisticated?  I'd say "simplest".
Attached file improved v2 (obsolete) —
OK, here comes the second iteration that takes into account most (?) comments.
It now also mentions the MOZILLA_HOME variable, but perhaps someone can come up
with a more concise text for that?
Btw, did nobody find any typos/spelling mistakes in the last version?


(In reply to comment #6)
> We might also want to note the workaround for bug 167884: in userContent.css
put
> '* {background-attachment: scroll !important;}'.

Hmm, this does not work here. But I have added a note about that bug.


(In reply to comment #8)
> Actually the installer has a button for displaying the readme.

I guess Felix was thinking of a way to "force" users to read the readme. The
installer could get one more screen like the one with the license the same way
as the Linux installer.


(In reply to comment #9)
> If I remember correctly, the right place to put this file would be in the
README
> subdirectory, rather than the root.

OK, will update the patch when the text has settled down. It's strange, though,
that this directory does not contain anything else that is useful, so it looks
obsolete to me. Will ask in .seamonkey to be sure.


(In reply to comment #5)
> "The program automatically ends any running Mozilla sessions"
> 
> Is this part actually true on OS/2?  I seem to recall the isntaller crashing
on
> me once because of an open session...

Yes, I tested that before. The reason probably is that it can then overwrite
DLLs more easily and does not mess up the configuration in the target
directory. The stupid thing is that it also shuts down other Mozillas running
from other directories which does not seem to be necessary...


(In reply to comment #10)
> > Minimum hardware requirements [...] Recommended hardware for good usability

> Face it, Moz on a P133/64mb would probably be unbearable.  I would drop the
> first section & retitle the second "Minimum hardware for acceptable
> performance".  Also, a comment that Mozilla's performance & stability
increases
> markedly with more memory might be appropriate.

Given that I ran it on a P166 with 64 MiB (later 128 MiB) for two years or and
even before 1.0 came out, I can say that you _can_ work with it, although it is
not as much fun if I start Mozilla on that machine today. I have found postings
by other people who use it on a P133 (albeit on Win98). In the meantime Mozilla
has improved and uses less RAM and is faster... But I have changed that section
a bit.

> > Running multiple versions of Mozilla concurrently
> Much as I like to explain things at length, I'd cut back on the verbiage.

I knew that a native speaker could make this much shorter. :-)

> Here's the script I would recommend:
[...]
> IMHO, this reinforces the understanding that PATH & LIBPATH entries are not
> needed when the exe is in the current directory.

Right, but do you not need BEGINLIBPATH if e.g. the IBW directory is listed in
LIBPATH and ".;" is not the first entry? But right, it's a very special case
and I put it in a similar remmed line.
Attachment #169674 - Attachment is obsolete: true
Attachment #169671 - Flags: review?(mkaply)
The code change Mike suggested: place into README/mozilla subdir besides
README.build. Updated version of README will follow shortly.
Attachment #169671 - Attachment is obsolete: true
Attachment #170284 - Flags: review?(mkaply)
OK, fixed the one mistake I found in the very last sentence of the previous
version, and added another how to find other known OS/2 issues.

Is anything important missing or wrong? Otherwise it would be nice to get this
into 1.8a6.
Attachment #169818 - Attachment is obsolete: true
Attachment #170287 - Flags: review?(mkaply)
Flags: blocking1.8a6?
I will try desperately to get this in tomorrow morning for 1.8a6
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.8a6?
Attachment #170287 - Flags: review?(mkaply)
Comment on attachment 170284 [details] [diff] [review]
Code changes with subdir

These are checked in, canceling review request.
Attachment #170284 - Flags: review?(mkaply)
Mike, could you also check this into the 1.7 branch? Do I need to produce a
clean patch or is this one that successfully applies with offsets good enough?

I will open another bug for Aviary readmes.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: