app/share/locale/xx/LC_MESSAGES/app.mo

[A.D. Fundum]

Assuming a ported package like this:

app/app.exe
app/share/locale/it/LC_MESSAGES/app.mo

In general, in which directory structure(s) can files like APP.MO
typically be found by APP.EXE, when APP.EXE is moved from the original
subdirectory APP to a PATH-directory (let's say U:\TIL, or %HOME%) and
adding single apps to an OS/2 is not a serious option?

IOW: is there a an embedded, OS/2'ified search strategy to find
non-DLL file types?

Of course I can go to U:\TIL\APP to execute U:\TIL\APP\APP.EXE, which
can use its U:\TIL\APP\SHARE\LOCALE\IT\LC_MESSAGE\APP.MO, but that
would ignore the condition (and, more important, the advantages) of
the PATH.


--

[ivan]

Post by A.D. Fundum
app/app.exe
app/share/locale/it/LC_MESSAGES/app.mo
In general, in which directory structure(s) can files like APP.MO
typically be found by APP.EXE, when APP.EXE is moved from the original
subdirectory APP to a PATH-directory (let's say U:\TIL, or %HOME%) and
adding single apps to an OS/2 is not a serious option?
IOW: is there a an embedded, OS/2'ified search strategy to find
non-DLL file types?
Of course I can go to U:\TIL\APP to execute U:\TIL\APP\APP.EXE, which
can use its U:\TIL\APP\SHARE\LOCALE\IT\LC_MESSAGE\APP.MO, but that
would ignore the condition (and, more important, the advantages) of
the PATH.
--

An extremely good question that does require an answer especially for
those of us that are not enamoured with using a unix file system.

ivan
--

[Dave Yeo]

Post by ivan

Post by A.D. Fundum
app/app.exe
app/share/locale/it/LC_MESSAGES/app.mo
In general, in which directory structure(s) can files like APP.MO
typically be found by APP.EXE, when APP.EXE is moved from the original
subdirectory APP to a PATH-directory (let's say U:\TIL, or %HOME%) and
adding single apps to an OS/2 is not a serious option?
IOW: is there a an embedded, OS/2'ified search strategy to find
non-DLL file types?
Of course I can go to U:\TIL\APP to execute U:\TIL\APP\APP.EXE, which
can use its U:\TIL\APP\SHARE\LOCALE\IT\LC_MESSAGE\APP.MO, but that
would ignore the condition (and, more important, the advantages) of
the PATH.
--

An extremely good question that does require an answer especially for
those of us that are not enamoured with using a unix file system.

As far as I know, it just looks in $CWD (current working
\directory)\share\locale\ with the rest of the path depending on your
language setting. Libintl could probably be patched to look in %DPATH%
if someone was interested in doing the work.
Dave

[Dave Yeo]

$CWD (current working \directory)\share\locale\

Of course that should have been
$CWD\share\local where $CWD=the current working directory
Dave

[A.D. Fundum]

Post by A.D. Fundum
IOW: is there a an embedded, OS/2'ified search strategy
to find non-DLL file types?

it just looks in $CWD\share\locale\ with the rest of the path
depending on your language setting. Libintl could probably
be patched to look in %DPATH% if someone was interested
in doing the work.

I'm not sure how adopting the (useless, in our case) Unix directory
structure will work, but there are several strategies possible.

I don't know how frequently your language setting changes, but I know
my static preferred language with English as an acceptable default. So
it may as well first look whatever Unix directory struture which was
used. If it cannot find this file, assuming e.g. French, then it could
look for "app.FR" (prefered), "app.EN" (default) or "app.MO" (e.g. an
app which only support an unexpected language, like Polish) in the
same directory as the EXE.

An ugly wrapper, which changes to the right drive and directory
($CWD), executes the usefull utility (hence the PATH) and, if there's
no fatal error, restores all $CWDs and returns to the original
directory. There are several disadvantages, like the directory where a
file will be saved.

I'm even willing to use a non-bootdrive %UNIXROOT% directory as a base
for non-DLL files.

If "management" has to decide anything, then they won't need my
suggestions to come up with a solution which OS/2'ifies (optimized
search stragety) ported software better, without causing too much
avoidable headaches for both users and developers.

I think I like a better, OS/2'ified search strategy. Original location
first, next the same directory as the EXE, ..., whatever is best). My
language doesn't change frequently. E.g. APP.FR in the same PATH
directory as APP.EXE could work for me, but I don't even have a copy
of GCC installed. Of course I'm willing to move
/what/ever/path/app/fr/app.mo to the file U:\TIL\APP.FR or indeed
%DPATHDIR\APP.FR, I'm not expecting an installer nor file systems with
supports for links. I guess a smart search strategy would help, and
using the %DPATH% could work.

My Wget (bless the porter for porting it, and bless the porter again
for porting language files!!!) still is the ancient v1.10, because it
still works. It's in my PATH and LIBPATH, and required one rather
unique DLL. All other files (wgetrc, DOCs) are moved to a single
Wget-directory, i.e. without the original, useless Unix directories.
Newer versions of Wget required a.o. some Z.DLL in the LIBPATH (Z.DLL
version LK, Lords Knows), or another new version assumed a PATH-less
directory structure we're discussing here. I think I probably have
more than 1 GB of Unix-related "problems" still waiting to be
examined, including Wget-updates (like v1.14, v1.16).


--

[A.D. Fundum]

Post by Dave Yeo
%DPATH%

Is the length of the DPATH limited? In random order:

1. Original directory structure (see subject)
2. DPATH-directory (D:/PATH/<subject>)
3. Same directory as the EXE (P:/ATH/<subject> )
4. DPATH-directory, format "<APP>.<LANG>", no subdir.
5. Same directory as the EXE, format "<APP>.<LANG>" (e.g. APP.RU), no
subdirs.

This still supports having multiple versions installed, if that's
important for someone, assuming that #1 remains the first, default
choice. Options without subdirs may require e.g. an OS2.INI setting
of prefered languages, if available (e.g. in Belgium NL, FR, DE, EN).

Just my $0.02, and I'm not using GCC...


--

[Marcel Mueller]

Post by A.D. Fundum
IOW: is there a an embedded, OS/2'ified search strategy to find
non-DLL file types?

The system uses DPATH for .msg file lookups. This is quite close to to
the typical LC files of unix apps.


Marcel

[Andreas Kohl]

Post by Marcel Mueller

Post by A.D. Fundum
IOW: is there a an embedded, OS/2'ified search strategy to find
non-DLL file types?

The system uses DPATH for .msg file lookups.

It's used for any kind of data, otherwise it would be called MSGPATH ;-)

Post by Marcel Mueller
This is quite close to to
the typical LC files of unix apps.

In my opinion this is not correct. What's a "typical LC file"? In this
case typical UNIX applications or programs don't use it.
Under UNIX the file /etc/default/locale is used for the system default
locale. Simple to check by everybody with login to an UNIX machine (man 4
locale).

--
Andreas

[A.D. Fundum]

Post by Andreas Kohl
It's used for any kind of data, otherwise it would be called

MSGPATH ;-)

Brilliant. I've now deleted all DLLs in my LIBPATH directories and
moved CDWCPY.LIB to the single remaining LIBPATH directory... :-o

No matter what a "typical LC file" may be, the underlying problem
remains the same. Now we don't have the possible benefits of an Unix
link, and without a search strategy we cannot fully use the benefits
of our alternative, the PATH .

Will using the DPATH imply that base directories, at least one, will
be used, and that a ported app casu quo a generic DLL will look for
e.g. "%A_DPATH_DIR%\app\share\locale\xx\LC_MESSAGES\app.mo" if
"./share/locale/xx/LC_MESSAGES/app.mo cannot be found"?


--

[Andreas Kohl]

Post by Andreas Kohl

Post by Andreas Kohl
It's used for any kind of data, otherwise it would be called

MSGPATH ;-)
Brilliant. I've now deleted all DLLs in my LIBPATH directories and
moved CDWCPY.LIB to the single remaining LIBPATH directory... :-o
No matter what a "typical LC file" may be, the underlying problem
remains the same. Now we don't have the possible benefits of an Unix
link, and without a search strategy we cannot fully use the benefits
of our alternative, the PATH .

Limitations wherever I see ;-)

Post by Andreas Kohl
Will using the DPATH imply that base directories, at least one, will
be used, and that a ported app casu quo a generic DLL will look for
e.g. "%A_DPATH_DIR%\app\share\locale\xx\LC_MESSAGES\app.mo" if
"./share/locale/xx/LC_MESSAGES/app.mo cannot be found"?

Most of this so-called ported programs don't use DPATH at all.
*.mo files are GNU gettext language modules, that's nothing UNIXish.
Perhaps it's simply to boring for devilopers to port straight UNIX
programs because they could work reliably for an average user.

--
Andreas

[A.D. Fundum]

Post by Andreas Kohl
*.mo files are GNU gettext language modules, that's nothing
UNIXish.

The directory structure, 84.21% of the characters of the original
subject and without a search strategy to avoid such a file
specification, is. The file APP.MO itself isn't a problem, as long as
e.g. an EXE in the PATH can find it.

Of source GNU e.a. plays a role, including the fact that porters don't
have to re-invent wheels. In this case the fitted square wheels can be
fixed/avoided by using a search strategy.

It's not the only GCC-related issue, hence the ~1 GiB of produced
software I haven't looked at yet, but I don't have an overview of all
OS/2'ifyable issues without having to try to sell round wheels to
porters (including a virtual third-party utility to find and download
missing or newer DLLs).

Well, perhaps a list of stable DLLs can be compiled, which can be
saved in a LIBPATH directory without likely version-related problems.
Now it's not obvious what the best place is to save a generic DLL,
assuming a Clean LIBPATH Policy (i.e. no Z.DLLs allowed)...


--

[Dave Yeo]

Post by A.D. Fundum
Well, perhaps a list of stable DLLs can be compiled, which can be
saved in a LIBPATH directory without likely version-related problems.
Now it's not obvious what the best place is to save a generic DLL,
assuming a Clean LIBPATH Policy (i.e. no Z.DLLs allowed)...

Z should be one of the more stable DLLs. Of course there is the problem
of EMX not adding the underline prefix to symbols and of some people
building with exportsbu ordinal instead of name.
What problems have you had?
Dave

[A.D. Fundum]

Post by Dave Yeo
Z should be one of the more stable DLLs.
What problems have you had?

So the suggested list of stable DLLs ("should be" is good enough)
would be surprising. Or perhaps a shorter list, with unstable DLLs.

I cannot reproduce that, because it may have been related to an app I
have deleted or which has to be reviewed again. The only remaining
evidence is that there's no Z.DLL in my LIBPATH, and all apps which
require Z.DLL use their own copy (so using DLLs hardly has a point,
because each reader has to have its own DLLibrary).

Nevertheless I can reproduce a failure by copying Links' larger Z.DLL
(file date 17-09-15, 75568 bytes) to the LIBPATH, to replace some
working Z.DLL of SuperTux (file date 01-09-14, 52052 bytes).
POPUPLOG.OS2:

02-01-2016 03:54:48 SYS2070 PID 008e TID 0001 Slot 00a3
E:\TEST\SUPERTUX.EXE
SUPERTUX->Z._gzclose
127

If there are two fully different DLLs called Z, then a rule to copy
the latest one to the LIBPATH isn't valid (i.e. unstable, regardless
of a DLL itself). In this case SuperTux will stop working. Or is Links
the exception which confirms the rule?


--

[Dave Yeo]

Post by A.D. Fundum

Post by Dave Yeo
Z should be one of the more stable DLLs.
What problems have you had?

So the suggested list of stable DLLs ("should be" is good enough)
would be surprising. Or perhaps a shorter list, with unstable DLLs.
I cannot reproduce that, because it may have been related to an app I
have deleted or which has to be reviewed again. The only remaining
evidence is that there's no Z.DLL in my LIBPATH, and all apps which
require Z.DLL use their own copy (so using DLLs hardly has a point,
because each reader has to have its own DLLibrary).
Nevertheless I can reproduce a failure by copying Links' larger Z.DLL
(file date 17-09-15, 75568 bytes) to the LIBPATH, to replace some
working Z.DLL of SuperTux (file date 01-09-14, 52052 bytes).
02-01-2016 03:54:48 SYS2070 PID 008e TID 0001 Slot 00a3
E:\TEST\SUPERTUX.EXE
SUPERTUX->Z._gzclose
127
If there are two fully different DLLs called Z, then a rule to copy
the latest one to the LIBPATH isn't valid (i.e. unstable, regardless
of a DLL itself). In this case SuperTux will stop working. Or is Links
the exception which confirms the rule?

As I said, the problem is that EMX did not use the standard OS/2 calling
mechanism, which is to have an underline prefix on symbols, eg SUPERTUX
should be using _Z._gzclose..
Ideally is to have different named z.dll, eg Mozilla uses mozz.dll due
to the sys2070's like your example.
In practice, most apps are now built with kLIBC and the latest Z.DLL
compiled with kLIBC should be on the libpath and programs such as links,
gimp etc should use a script (or run!) to set BEGINLIBPATH and
LIBPATHSTRICT to load EMX versions of dlls.
Apps having their own copy without LIBPATHSTRICT isn't a good solution
because the system will use whichever is loaded. EG start links and then
try to run supertux and you get the same sys2070 even though z.dll isn't
on the LIBPATH.
It's best to use the latest DLLs as well as often they have security
fixes which even on our system can prevent crashes.
BTW, where did you get SUPERTUX?
Dave

[A.D. Fundum]

Off-topic: SM stopped actually downloading files. Restoring an old,
working profile helped.

Post by A.D. Fundum
SUPERTUX->Z._gzclose

eg SUPERTUX should be using _Z._gzclose..

Can e.g. EXEHDR be used by end-users as an additional condition,
before the condition that "any" newer DLL file with the same name
should safely replace an older copy?

the latest Z.DLL compiled with kLIBC should be on the libpath
programs such as links, gimp etc should use a script
(or run!) to set BEGINLIBPATH and LIBPATHSTRICT
to load EMX versions of dlls.

I'd like to point out, regardless of the compiler of that package,
that the Links v2.12 WPI install script uses the LIBPATH and that it
doesn't use any of the above. I don't actually use such a WPI file due
to its limited added value, but it could have inspired me to use the
same settings.

The latest SM WPI install script doesn't even work, because a required
DLL is successfully installed in the SM directory (".", a valid
LIBPATH entry) instead of in a LIBPATH directory, just like PM DLL
doesn't use the "." of a selected EXE.

Apps having their own copy without LIBPATHSTRICT isn't a good
solution because the system will use whichever is loaded.

Understood. Accidents may happen, albeit it't not my habit to play
SuperTux before reporting bugs.

Other than adding better solutions to WPI files not compiled by
you/programmers, is there a better way to protect the "brand" of
"right" DLLs?

You didn't say it at all, but "contact the author of a wrong Z.DLL" is
a helpdesk's solution. Perhaps it's possible to compose an utility
which checks EXEs and/or DLLs, like there was a PM utility to check
the version of VROBJ.DLL.?

PM DLL can detect that SUPERTUX.EXE cannot load Links' Z.DLL, moved to
a LIBPATH directory. That's step 1, detect that it requires Z.DLL but
that it cannot load Z.DLL. The final step would be to check if the
available Z.DLL (or the EXE) is right or "wrong". Usage history could
be used to check if an updated DLL will still work with all qualifying
EXEs. I'm not expecting that verificiation code will be added to EXEs.

It's best to use the latest DLLs as well as often they have

security

fixes which even on our system can prevent crashes.

I'll renew/modernize my strategy, albeit I don't always know which
DLLs should be safe. The number of installed Z.DLLs still is limited:

TCPIP\QupZilla 16-01-12 17:30 52.052 0 z.dll
Games\SuperTux 1-09-14 16:17 52.052 0 z.dll
Games\Toppler 1-09-14 16:17 52.052 0 z.dll
Multimedia\Qoobar 2-06-14 2:41 56.374 124 z.dll
Multimedia\SMPlayer 2-06-14 2:41 56.374 124 z.dll
TCPIP\Links 17-09-15 16:44 75.568 0 z.dll

Without some utility I'll first use PM DLL to make sure that apps can
load Links' Z.DLL, assuming that Links' Z.DLL is the right/best
LIBPATH "brand".

In general it would also help to use BEGINLIBPATH e.a. in relevant WPI
archives (compiled by Doug?), e.g. Links', based on your
recommendation. I'd adopt such a setting in my own install scripts,
without actually using the WPI script.

The SM WPI install script also uses the LIBPATH, without using any
SET=... in its WPS setup string.

BTW and FWIW, the SM WPI install script also still uses Rexx' ancient
OS2ENVIRONMENT instead of a bith shorter and portable ENVIRONMENT, but
I doubt that Microsoft OS/2 v1.x still is supported by the Mozilla
suite..

BTW, where did you get SUPERTUX?

Our Appstore, with a wife-"needs"-phone-alert of about 7.6 MiB:

http://hobbes.nmsu.edu/download/pub/os2/games/action/supertux-SDL-2014
0815.zip


--

[Dave Yeo]

Post by A.D. Fundum
Off-topic: SM stopped actually downloading files. Restoring an old,
working profile helped.

Post by A.D. Fundum
SUPERTUX->Z._gzclose

eg SUPERTUX should be using _Z._gzclose..

Can e.g. EXEHDR be used by end-users as an additional condition,
before the condition that "any" newer DLL file with the same name
should safely replace an older copy?

Sure. If you run EXEHDR on the EMX z.dll you'll see that the exports
have no or one underline prefix whereas if you do the same with a z.dll
compiled by anything else, all the exports will have at least one
underline prefix. Some symbols are meant to have an underline so they
end up with two.
This could be scripted.

Post by A.D. Fundum

the latest Z.DLL compiled with kLIBC should be on the libpath
programs such as links, gimp etc should use a script
(or run!) to set BEGINLIBPATH and LIBPATHSTRICT
to load EMX versions of dlls.

I'd like to point out, regardless of the compiler of that package,
that the Links v2.12 WPI install script uses the LIBPATH and that it
doesn't use any of the above. I don't actually use such a WPI file due
to its limited added value, but it could have inspired me to use the
same settings.

That's not good. I don't think the developer really uses OS/2 anymore
and hasn't kept up with developments. I note that he uses EMX 9C which
is ancient.
Probably someone should inform of the problems caused by mixing the DLLs.

Post by A.D. Fundum
The latest SM WPI install script doesn't even work, because a required
DLL is successfully installed in the SM directory (".", a valid
LIBPATH entry) instead of in a LIBPATH directory, just like PM DLL
doesn't use the "." of a selected EXE.

Another broken WPI :) I guess this is one of the main drivers of using
RPM/YUM, namely to standardize where DLLs are installed.

Post by A.D. Fundum

Apps having their own copy without LIBPATHSTRICT isn't a good
solution because the system will use whichever is loaded.

Understood. Accidents may happen, albeit it't not my habit to play
SuperTux before reporting bugs.\

DLLs can be compiled to stay resident, so once loaded, they stay loaded
and I think some tools chains do this.

Post by A.D. Fundum
Other than adding better solutions to WPI files not compiled by
you/programmers, is there a better way to protect the "brand" of
"right" DLLs?

Better naming? Hard to do to well with our stupid 8.3 DLL name limit.
In theory I believe it is possible to use a custom DEF file to get a DLL
to work with both EMX and everything else.

Post by A.D. Fundum
You didn't say it at all, but "contact the author of a wrong Z.DLL" is
a helpdesk's solution. Perhaps it's possible to compose an utility
which checks EXEs and/or DLLs, like there was a PM utility to check
the version of VROBJ.DLL.?

Sure, as said above, check for the leading underline on exported
symbols, check for ordinals at the same time as well.
Doesn't solve the problem where a DLL is updated to do more without
changing the name. eg stdcpp6 where the newer one works fine for old
programs but the old one gives subtle errors if used by newer program.
I think the YUM/RPM maintainers have also added bldlevel info getting
added automatically recently.

Post by A.D. Fundum
PM DLL can detect that SUPERTUX.EXE cannot load Links' Z.DLL, moved to
a LIBPATH directory. That's step 1, detect that it requires Z.DLL but
that it cannot load Z.DLL. The final step would be to check if the
available Z.DLL (or the EXE) is right or "wrong". Usage history could
be used to check if an updated DLL will still work with all qualifying
EXEs. I'm not expecting that verificiation code will be added to EXEs.

It's best to use the latest DLLs as well as often they have

security

fixes which even on our system can prevent crashes.

I'll renew/modernize my strategy, albeit I don't always know which
TCPIP\QupZilla 16-01-12 17:30 52.052 0 z.dll
Games\SuperTux 1-09-14 16:17 52.052 0 z.dll
Games\Toppler 1-09-14 16:17 52.052 0 z.dll
Multimedia\Qoobar 2-06-14 2:41 56.374 124 z.dll
Multimedia\SMPlayer 2-06-14 2:41 56.374 124 z.dll
TCPIP\Links 17-09-15 16:44 75.568 0 z.dll
Without some utility I'll first use PM DLL to make sure that apps can
load Links' Z.DLL, assuming that Links' Z.DLL is the right/best
LIBPATH "brand".

I think that for most up to date installs, the Links Z DLL is not the
right one to have on LIBPATH as most programs are now compiled with kLIBC

Post by A.D. Fundum
In general it would also help to use BEGINLIBPATH e.a. in relevant WPI
archives (compiled by Doug?), e.g. Links', based on your
recommendation. I'd adopt such a setting in my own install scripts,
without actually using the WPI script.

Yes, the simple solution is a small script such as links.cmd that sets
BEGINLIBPATH and LIBPATHSTRICT and then launches links. The EMX DLLs
could even all be installed somewhere like x:\emx\dll and shared by EMX
programs.

Post by A.D. Fundum
The SM WPI install script also uses the LIBPATH, without using any
SET=... in its WPS setup string.
BTW and FWIW, the SM WPI install script also still uses Rexx' ancient
OS2ENVIRONMENT instead of a bith shorter and portable ENVIRONMENT, but
I doubt that Microsoft OS/2 v1.x still is supported by the Mozilla
suite..

Doug will probably see this and perhaps adjust his WPI scripts. There's
also the intent to use RPM/YUM to install the next versions of Mozilla
though I'll still distribute zips.

Post by A.D. Fundum

BTW, where did you get SUPERTUX?

http://hobbes.nmsu.edu/download/pub/os2/games/action/supertux-SDL-2014
0815.zip

I'll have to check it out
Dave

[Doug Bissett]

Post by Dave Yeo

Post by A.D. Fundum
The latest SM WPI install script doesn't even work, because a required
DLL is successfully installed in the SM directory (".", a valid
LIBPATH entry) instead of in a LIBPATH directory, just like PM DLL
doesn't use the "." of a selected EXE.

Another broken WPI :) I guess this is one of the main drivers of using
RPM/YUM, namely to standardize where DLLs are installed.

The WPI is not broken. It does it the way that it should be done, and
expects the user to do the same. It is NOT correct to put those DLLs
into the SM directory. If the user insists on using a non standard
setup, they are on their own, and I would point out that they are just
asking for trouble by doing it that way. There is a pretty good chance
that something else won't work properly (probably just sometimes),
depending on which version of a DLL gets loaded first. There should be
only ONE of each, and they need to be available to ALL programs that
are installed (BTW, the dot ".;" doesn't always work with ported
programs). Z.DLL, as discussed, is one of the major problems that a
user must handle in other ways (LIBPATHSTRICT or RUN!), if they want
to use programs that do not use the standard DLLs (better that those
programs should be fixed, but...).

Unfortunately, those who do those things have decided that that is the
way that it will be done, and the rest of us must live with it. Don't
try to beat the system, or you will eventually suffer the
consequences.

You have been warned. :-)

[A.D. Fundum]

Post by Doug Bissett
The WPI is not broken.

It is, but it really has no use to discuss that with authors whom
claim that their products aren't broken, while they have to claim that
a perfectly working, ignored setup is somehow wrong. One cannot always
learn an old Doug new tricks.

In this specific case the script, and its author, were now also
ignoring the recommended BEGINLIBPATH. That's a pity, because it could
encourage users of "non-standard setups" to use the "right" setup.

Even weirder is such a Microsoft Support'ish claim of a superior
install script, combined with Doug's own error messages like "The
required support library FREETYP6.DLL was not found on your system.
You must install this library before you can install Seamonkey.". I'd
say the SM directory can be found on my system, the DLL is already
installed, and I already have an installed SeaMonkey (instead of
Seamonkey) before I tried to use this broken script. So I'm afraid the
quality of the script itself already was the warning.

Despite of the fatal bogus error messages and a lacking BEGINLIBPATH
Education Section those broke scripts aren't fully useless, because
one can always copy and use the better, smaller components of such a
script, without the PITA of erroneous REQUIRES of engineers. Sometimes
a warning is better than a wrong assumption, just like PM DLL may
assume that a LIBPATHs dot is the directory of the examined EXE and
not PM DLL's directory...


--

[Doug Bissett]

Post by A.D. Fundum

Post by Doug Bissett
The WPI is not broken.

It is, but it really has no use to discuss that with authors whom
claim that their products aren't broken, while they have to claim that
a perfectly working, ignored setup is somehow wrong. One cannot always
learn an old Doug new tricks.
In this specific case the script, and its author, were now also
ignoring the recommended BEGINLIBPATH. That's a pity, because it could
encourage users of "non-standard setups" to use the "right" setup.
Even weirder is such a Microsoft Support'ish claim of a superior
install script, combined with Doug's own error messages like "The
required support library FREETYP6.DLL was not found on your system.
You must install this library before you can install Seamonkey.". I'd
say the SM directory can be found on my system, the DLL is already
installed, and I already have an installed SeaMonkey (instead of
Seamonkey) before I tried to use this broken script. So I'm afraid the
quality of the script itself already was the warning.
Despite of the fatal bogus error messages and a lacking BEGINLIBPATH
Education Section those broke scripts aren't fully useless, because
one can always copy and use the better, smaller components of such a
script, without the PITA of erroneous REQUIRES of engineers. Sometimes
a warning is better than a wrong assumption, just like PM DLL may
assume that a LIBPATHs dot is the directory of the examined EXE and
not PM DLL's directory...

If you don't like doing things the way they are supposed to be done,
don't use the WarpIn installer. If you want the dot to work, start
WarpIn from the desired target directory. The WarpIn installer will
still remove all files that it did not install, or expect to find
(that does include any stray DLLs that you may have incorrectly put
into the directory).

As I understand it, you will soon need RPM/YUM to install Firefox,
Thunderbird, and Seamonkey anyway. If somebody keeps on building a ZIP
file, I will continue to build a WarpIn installer (until it becomes
obvious that it is more work than it is worth). FWIW, right now, it
takes only a couple of minutes to turn a ZIP file into a WarpIn file.
The hard part is to determine what the requirements are, and then
convince the user to do it right. The main flaw in that, is that all I
can do is look to see if the proper DLL file exists. I cannot query it
to find out if it is the proper version. That is because there is no
way to know. Date and time don't mean anything, and bldlevel
information is not included. Either the user needs to manually keep
track of everything, or you need to use a program to do it. RPM/YUM is
not good, but it is much better than doing it yourself.

Even if you use the ZIP file, and follow the directions ("DO NOT
install over an older version"), you still have the same problems that
you complain about. Why not just do it right, and avoid the problems?

[Dave Yeo]

Post by Doug Bissett
As I understand it, you will soon need RPM/YUM to install Firefox,
Thunderbird, and Seamonkey anyway. If somebody keeps on building a ZIP
file, I will continue to build a WarpIn installer

I'll still be building TB and SM zips and if needed FF. How they're
planning to build the RPMs I don't know but generally the programs are
installed somewhere such as under /usr/lib/mozilla or /usr/share/mozilla
and scripts to launch the binaries installed in /usr/bin.
If I had the bandwidth, I'd also build static versions as well.
Dave

[Doug Bissett]

Post by Dave Yeo

Post by Doug Bissett
As I understand it, you will soon need RPM/YUM to install Firefox,
Thunderbird, and Seamonkey anyway. If somebody keeps on building a ZIP
file, I will continue to build a WarpIn installer

I'll still be building TB and SM zips and if needed FF. How they're
planning to build the RPMs I don't know but generally the programs are
installed somewhere such as under /usr/lib/mozilla or /usr/share/mozilla
and scripts to launch the binaries installed in /usr/bin.
If I had the bandwidth, I'd also build static versions as well.
Dave

From what I have seen, so far, they mash all of the executables into
the same directory, so it may be difficult to extract parts for a ZIP
file, from the RPM stuff.

I guess we wait to see exactly what they do, then figure it out.

[Dave Yeo]

Post by Doug Bissett

Post by Dave Yeo

Post by Doug Bissett
As I understand it, you will soon need RPM/YUM to install Firefox,
Thunderbird, and Seamonkey anyway. If somebody keeps on building a ZIP
file, I will continue to build a WarpIn installer

I'll still be building TB and SM zips and if needed FF. How they're
planning to build the RPMs I don't know but generally the programs are
installed somewhere such as under /usr/lib/mozilla or /usr/share/mozilla
and scripts to launch the binaries installed in /usr/bin.
If I had the bandwidth, I'd also build static versions as well.
Dave

From what I have seen, so far, they mash all of the executables into
the same directory, so it may be difficult to extract parts for a ZIP
file, from the RPM stuff.
I guess we wait to see exactly what they do, then figure it out.

Hard to do when the DLLs have the same name but are incompatible.
Besides Mozilla apps are hardcoded where to look for their DLLs

Dave

[T.]

Hi Doug,

Post by Doug Bissett
The main flaw in that, is that all I
can do is look to see if the proper DLL file exists. I cannot query it
to find out if it is the proper version. That is because there is no
way to know. Date and time don't mean anything, and bldlevel
information is not included.

what about using something like md5sum?

Include the result of all versions in your WPI and compare it with the
installed one, if it is the wrong one, replace it, give the user a
warning ...

[Doug Bissett]

Post by T.
Hi Doug,

Post by Doug Bissett
The main flaw in that, is that all I
can do is look to see if the proper DLL file exists. I cannot query it
to find out if it is the proper version. That is because there is no
way to know. Date and time don't mean anything, and bldlevel
information is not included.

what about using something like md5sum?
Include the result of all versions in your WPI and compare it with the
installed one, if it is the wrong one, replace it, give the user a
warning ...

MD5 is also useless. That changes if somebody uses LXLITE on it, and
even that changes depending on which options they use. Even finding
all of the possible versions is not an easy job.

The best answer (and it is not really a good answer) is to use RPM/YUM
to keep everything up to date.

I am considering changing the check routine to execute the YUM
commands, when YUM is found to be installed, but if YUM is installed,
the user should be using that to install, and manage, FF anyway. I
would assume that TB and SM will eventually be installed using YUM
too.

[A.D. Fundum]

if you do the same with a z.dll compiled by anything
else, all the exports will have at least one
underline prefix.
This could be scripted.

Good enough for me, one can detect the right "brand". My EXEHDR tends
to crash while displaying the headers of Z.DLLs, but I can see the __s
of the right calling conventions.

Probably someone should inform of the problems
caused by mixing the DLLs.

I'll try to find a few elves.

I guess this is one of the main drivers of using RPM/YUM,
namely to standardize where DLLs are installed.

RPM/YUM is probably a watershed, introduced by eCS 2.x. Using RPM/YUM
isn't obvious when you're restricted to eCS 1.x and older. AFAIK it
was never promoted as an implied must-have.

Doesn't solve the problem where a DLL is updated to do more
without changing the name. eg stdcpp6

That's hardly a problem when users can determine a right brand and
upgrade, even if an upgrade would be harder without RPM/YUM. Often
netlabs.org could be cleared, e.g. a section with all latest DLLs, and
users may not know what a "klibc"-version is.

Yes, the simple solution is a small script such as links.cmd
that sets BEGINLIBPATH and LIBPATHSTRICT

I'll still have look at (the undocumented, at least here)
LIBPATHSTRICT, I've never used that. Well over 95% of my apps is
installed by using a Rexx- or WarpIN-script, so adding SETs to WPS
setup strings isn't that hard. Otherwise using run! could help too.
Version management was a problem, if you weren't "into Unix
environments". That more clear now, thanks to your efforts.

Sometimes finding DLLs is a problem too, but that also has to do with
the fact that the developer already will have all required DLLs
installed.

There's also the intent to use RPM/YUM to install the next versions
of Mozilla though I'll still distribute zips.

Can RPM/YUM be uploaded to a GA archive like Hobbes too, so using it
is more obvious for everyone? Other developers/maintainers also still
have to document both methods. As such I could perhaps strat using
RPM/YUM, but I've never seen it, I don't have it and I don't know it.

supertux-SDL-20140815.zip

I'll have to check it out

So do I. This were a few installed packages, including SuperTux, but
the number of packages I haven't looked at due to non-seamless
requirements and/or Unix-based structures is more than 1000 or 1 GiB.


--

[Doug Bissett]

Post by A.D. Fundum
Can RPM/YUM be uploaded to a GA archive like Hobbes too, so using it
is more obvious for everyone? Other developers/maintainers also still
have to document both methods. As such I could perhaps strat using
RPM/YUM, but I've never seen it, I don't have it and I don't know it.

Do yourself a favor, and get the Arca Noae Package Manager. It is free
and it is supposed to work on Warp 4 and up (perhaps even Warp3).
When you install that, it will also install RPM/YUM, and give you a
good user interface to be able to use it.

Post by A.D. Fundum
https://www.arcanoae.com/wiki/anpm/

I will warn you that you will probably have problems, caused by using
incorrect methods to install what RPM/YUM supplies (your insistance
that system DLLs should be found in the Seamonkey directory, for
instance), until you make the effort to remove all of that stuff from
your system. I will also warn you that you must use RPM/YUM properly,
and don't try to outsmart the system, or you will have trouble.

It is a sad situation, but if you wish to use modern software, that
has been ported from elsewhere, you need the support that RPM/YUM
supplies. RPM and YUM are a horrible way to do it, but those who do it
have decided that that is the way that it will be done, so we are
stuck with it unless you really do like spending many hours trying to
figure out how to work around it, and spending even more hours trying
to figure out why something doesn't work (perhaps only sometimes). The
other options are to simply stop updating to newer software, or switch
to another operating system.