Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - André Heldoorn

Pages: 1 2 [3] 4 5 ... 13
31
Programming / Re: How to build Seamonkey?
« on: June 06, 2017, 04:34:03 am »
the language packages for Seamonkey 2.40 are not installable on 2.42, when I edit the version number in the file install.rdf inside the package to make it installable this leads to an unusable Browser (pages don't load).

Same here, different old langpack. I didn't try to use the browser component without a langpack, but the result of a 2.40 langpack test is negative.

32
Internet / Re: SeaMonkey-2.42b8 and Thunderbird 45.8.0
« on: June 04, 2017, 09:09:27 pm »
QWinFF may be the only app which requires FFPLAY.EXE. I cannot recall another example, and remembered the setting of QWinFF.

Which ZIP file is the home of LZMA5.DLL ("available as zips in the http://rpm.netlabs.org/release/00/zip/ directory
libc066, zlib, bzip2, freetype, fontconfig, libzma0")?

Edit: xz-5_2_3-2_oc00.zip

33
Internet / Re: SeaMonkey-2.42b8 and Thunderbird 45.8.0
« on: June 04, 2017, 08:21:10 pm »
the latest FFmpeg 3.3.1 (Hobbes incoming currently) should also work for H264, AAC and MP3.

FFPLAY.EXE, apparently a requirement of QWinFF, is no component of FFMpeg anymore?

34
Programming / Re: How to build Seamonkey?
« on: June 04, 2017, 06:44:15 pm »
IC, I'm not using 2.42 and prefer a non en_US version too.

Regarding DIY: I guess you have contact Dave Yeo, by email. It looks like he's using components which weren't GA yet, like a LIBCX DLL. If anything you can tell him the CRC32-checksum of your compiled EXE, and if there's a match then you can upload yours. :)

35
Programming / Re: How to build Seamonkey?
« on: June 04, 2017, 05:56:04 pm »
(in the end i want to create a german version of it, but this may be step two or three)

What about just installing SM and a German language package (e.g. https://ftp.mozilla.org/pub/seamonkey/releases/2.40/langpack/)?

You may have to edit the langpack text file install.rdf (unzip the XPI file) to support SM 2.42: if 2.42 was no official release, if 2.40 is the latest langpack before 2.42, and if 2.40's langpack supports the range 2.40-2.40.

36
General Discussion / Re: OS/2 history
« on: June 03, 2017, 06:37:32 pm »
For a period of ten (10) years from the date of receipt of Source Code from the other party

IBM owns his own generated products and MS owns its own generated products.

It is possible that the copyrights are owned by Microsoft and IBM on the source code, but maybe the source code can be disclosed by now :)[/quote]

It is possible that the copyrights are owned by Microsoft and IBM on the product, but maybe the source code can be disclosed by now.

But that's not likely. Even with source code it's like owning a book, without having the rights to publish that book. Microsoft has no reason to donate you their parts of the product, which may compete with their own product again. That's financial suicide. If Microsoft wants your money, then they'd try to sell you a copy of Windows 10.

I guess laws could be modernized to account for abandonware, for example by allowing an unauthorized distribution of some registered copy of a popular shareware product after 15 years of full inactivity of the owner of the rights. This won't help OS/2, because Microsoft may still be using and updating components/technologies of MS OS/2 1.0.

37
Programming / Re: Open source OS/2 projects that need help?
« on: June 03, 2017, 06:01:33 pm »
Beginners can always try to compile updated software which was ported earlier, as a starting point. A random example is OptiPNG 0.7.6. It looks like we've got 2005's version 0.7.5. New versions of existing ports, or perhaps an update of old versions compiled with an old version of GCC. Next you can start looking for useful software which you can compile, typically text-mode apps without too many required changes. Sometimes you may have to change a few things. Sometimes even compiling it with another compiler isn't that hard.

Without significant programming skills you can sometimes OS/2'ify or improve existing packages, for example by adding an existing icon to a package or by following the expert's instructions to compile, test and upload the large SM/TB files. Writing INSTALL.CMDs or WPI files may be helpful.

I don't need OptiPNG 0.7.6 myself, so it's an honest example. Other old apps may be easier to update.

39
Applications / Re: Firefox 45.5 Install issues
« on: May 29, 2017, 12:25:09 pm »
Quote
OS/2's human package manager

Why does OS/2 rely on a human package manager?

Is this really meant still seriously?

To support Andreas' case, he has one, OS/2 doesn't rely on a human package manager. Operations do. It may be hard for an engineer to understand that their Usenet trolls have to manage more than one system, while trying to avoid the DLL hell of DLLs like JPEG.DLL and Z.DLL.

Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you. That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products. If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.

Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.

So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".

Hence: FF + OS/2 (and FF for eCS 1.x) = missing DLLs + missing requirements + missing support

So you're on your own then. While you're on your own, you may as well become the human package manager if the environment isn't that simple. It's easy to install an approved DLL. It's harder to uninstal the possibly destructive output of the random update policies of some random digital package manager, which works fine for "the average home user of selected products".

In the case of older hardware, the capacity of harddisks plays a role too. I'm pretty sure that a package manager isn't that aware of likely disk full-errors. If there's no eCS 1.x, eCs 2.x nor ArcaOS in the right language, then newer hardware isn't an obvious solution.

That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.

If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.

In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.

So please try to keep anyl Y2K-proof version of OS/2 Warp, settings of WPS objects and continuity of operations in mind while advocating that "one solution" (of some products) is "the solution" (of all products, languages and/or situations). Releasing qualifying updates for all OS/2-based products would help, but that won't solve all possible issues. If a new component really has to be added to ArcaOS, like a font, Unix directory structures or a package manager, then please consider releasing such a product as an update for all OS/2-based products. By default a simple install of OS/2 Warp 4 has no Unix directory structure, package manager, and so on.

So there's no such thing as a working "FF for OS/2", regardless of perfect and impressive OS/2 binaries. Install and update OS/2, install the FF package, and it won't work. The README.OS2 will result in a SYS1041 error.

OS/2 Warp (no FP for all OS languages), eCS 1.x (a few languages), eCS 2.x (fewer languages) and ArcaOS (EN only) are different products, each leaving a part of the community behind. In the case of ArcaOS EN perhaps a part of the German community too, slowly. The one and only package manager is a solution for the happy few. I guess availablity of ANPM is excellent, but that doesn't imply that everyone is willing to allow a random digital package manager, with random update policies, without detecting all possible OS/2 setups, to manage their packages.

Regarding applications, the number of quickly ported "OS/2" application which assume some eCS 2.x or ArcaOS setup is increasing. There is no "eCS 2.x setup for OS2" package, if you'd want such an environment in the first place. Or need such an environment. Often you can copy all files to one directory and keep the bootdrive clean, but not always. If not, then the required environment should have an added value for OS/2. Often it has no added value at all.

Of course the irrelevant, perfectly fine product WarpIN isn't the answer. A disadvantage of a (anything but perfect) WPI version of the FF products is that you may have to backup both the large WPI file and the large installed files. And, of course, WarpIN is a kind of package manager with its own policies. Here the human package manager typically extracts and converts the (sometimes anything but perfect) WarpIN install scripts to Rexx install scripts. If the results are identical, then managing and backing up the small Rexx install scripts is prefered above having to backup the whole original archive too. Fonts are a common exception (bootdrive files without a backup of the installed files, INSTFONT).

IIRC the game QNetwalk is an example of a Unixified app. It's improved significantly, but it uses a Unix directory structure. I guess just because Unix-based tools were used. Without any added value compared to an OS/2 or eCS 1.x x:\OS2GAMES\QNETWALK setup.

40
Programming / Re: Compiling PM app on 2016.
« on: May 29, 2017, 10:02:10 am »
OpenWatcom.org, the only existing cross compiler for OS/2

I'm pretty sure that, for example, at least one of the Pascal environments, Virtual Pascal, is capable of producing code for more than one OS. FWIW.

IBM VAC++ 3.08 FixPaks: FTP-server service.software.ibm, com, directory /ps/products/visualagecpp/fixes/v30os2/english-us/fixpak8

41
Internet / Re: FF45.5 - choppy response/window scrolling anyone???
« on: May 26, 2017, 04:05:25 pm »
go back to 38 and so far things seem stable and the application responsiveness of course is back to where I expect it to be...so that would point to an actual difference in the 45 release, as opposed to say one of the underlying libraries that 45 is using. This rationale of course only holds true for the libraries that are common to both 38 and 45.

Same here, and confirmed. FF 45 responses were slow with a hidden "entry field" cursor, while SM "38" was still as fast as usual. FF 45 caused a lasting 100% CPU load once, but that's hardly worth mentioning. Kill and restart took care of that issue. I'ld perhaps delete new packages, but going back is possible indeed.

42
Setup & Installation / Re: Unable to install ArcaOS
« on: May 26, 2017, 12:18:05 pm »
I can't see anything about AHCI.

To try to summarize such questions and answers: what's the brand/model/type, if any, of the computer?

43
Internet / Re: SeaMonkey-2.42b8 and Thunderbird 45.8.0
« on: May 26, 2017, 12:08:15 pm »
I accidently removed OS/2 2.0 support.

In general it's safe to assume the use of a 80386 Y2K-proof OS by now, i.e. any OS/2 Warp or newer products, unless you know that you have to keep a specific, professional real user of OS/2 2.0 in mind. Users of OS/2 2.0 will be aware of the fact that their setup is old, and they'll contact (and pay) you if their old, specializied professional setup really requires a modern browser. So, for example, you can stop using the "OS2ENVIRONMENT" of Rexx, unless one of your customers still has to use Microsoft OS/2 and needs your Rexx script. Only if the software in question is FF/SM, then you can safely add 300 to the number of the CPU because of the specific memory requirements of FF/SM to visit about:blank.

44
Internet / Re: SeaMonkey-2.42b8 and Thunderbird 45.8.0
« on: May 26, 2017, 11:50:31 am »
The build adds the icons to the exes and then make package runs lxlite on the DLLs and exes. When lxlite compresses the exe, hi-colour icons get corrupted. It's an lxlite bug.

Excuse me, I was talking about any own install script of the user. So far the right original SM icons are always included by you, so the user can avoid this problem of damaged icon data of the EXE. Avoiding the problem for all users may be better, but the right original icons are already available for all users. The user shouldn't need a SMICONS.ZIP file. This is verified with SM only, I don't know about TB.

45
Applications / Re: Firefox 45.5 Install issues
« on: May 26, 2017, 11:41:30 am »
Thanks for that information Dave.  We gave that system up as a bad job years ago when we tried using SUSE on our servers.

It's still possible to obtain all DLLs without a digital package manager. This time the package manager command-line was the main clue. So were new requirements mentioned here. I do not have a list of all required DLLs and archives, because DLLs can be used by other apps too and I've never recorded all possible DLL hell requirements of all apps. I don't know if a digital package manager uses ATTRIB +R, but I do execute that command for 6 DLLs which used to have this attribute set.

Pages: 1 2 [3] 4 5 ... 13