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 ... 16
General Discussion / Re: OS/2 application developers
« on: December 08, 2017, 05:28:16 am »
I'm not really focused on the older programs -I'm looking at 64-bit OS/2 the way Microsoft looked at 64-bit Windows.

We may need 64-bit for a 64-bit browser. That's it. And maybe for a 64-bit compiler for at least one user, to compile such a browser. If you'd expect that people want to throw away 20+ years of investements, if anything of time, to browse, then they may as well throw away their software now and start using a 64-bit browser for your 64-bit Windows. I don't really care what your private focus is, but then I'd suggest to throw away "the older programs", i.e. everything for 16- and 32-bit OS/2, and start using whatever already existing 64-bit OS with a 64-bit browser software. So it's not the best point of view ever.

I don't need nor mind 64-bit APIs, but I'd prefer an inclusive strategy instead of yet another lazy it-works-for-me strategy to reduce the size a small community. If someone likes your approach, then delete all "older programs" you've got now, start using any 64-bit OS, and pretend to be happy while browsing with a 64-bit browser.

Regarding 64-bit-APIs, I have no huge files myself, is that it would be nice if it was easier to always support huge files with "older programs", without having to write onesr own LONGLONG-code. Now 2 GiB often is the implied limit, just because it's too hard to support DosOpenL() for a few files of a few users. But we don't have to discuss this here, because "old programs", including but not limited to some older compilers, is not your focus.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: December 05, 2017, 07:22:35 pm »
I will recommend you to upload the manual to Hobbes and the Internet Archive also.

Preferably in one Hobbes archive (or two), at stated earlier. Users will have to study and/or use the WPI file, your two updates and some manual. If you want to attract users or to promote it being used, then a collection of archives isn't the best strategy.

Two packages are acceptable: an "official" WPI distribution and an "unofficial" single, clear add-on package. More than two isn't required: Young's and yours.

Utilities / Re: Manual for eFTE/2 / eFTE / FTE (Folding Text Editors)
« on: November 30, 2017, 02:19:15 am »
Do you know FTE? Do you still use it? Would this make you try the editor? Do you think I should improve this manual? How? Am I better off devoting my time to other stuff?

Despite of several non-negative answers, it's quite unlikely that new users will start using it because you've invested time in a manual. New users ought to be able to use an editor without a manual. Advanced users may like it, but the number of advanced users will be limited.

IIRC the distributions weren't that clear, which was the main reason why it took me several years to review and eventually install the right FTE files. Such a delay didn't promote it being used, because users had several years to get used to alternatives. IIRC, I do recall several FTE*.ZIP files and/or additional packages, and a lack of up-to-date important READ.ME files.

I guess writing documentation would come down to recording the knowledge of an experienced user. In the past a better installer could have helped to attract more new users, without e.g. having to download and install yet another manual package in the future.

Back to you. EPM is pretty powerful too. The number of times I've read and used a tip in an EPM tips & tricks-article will exceed the number of times I've looked for EPM manuals. If the number of readers is not important, then recording your knowledge could justify the extraordinary efforts, but you may as well write documentation for advanced users and make sure that it's not hard for new users o start using it. A quick search @ Hobbes results in 11 *FTE* files in /pub/os2/apps/editors, and I guess the WPI version got me going. Since this WPI file you've uploaded other files too. Updating the WPI archive may be better, and I don't know why wasn't replaced. Perhaps try to reduce the number of updated files to 1. Now an user may have to check 11 unclear files to figure out what's required to install 1 FTE.

My $0.02.

Programming / Re: STARTUPDIR
« on: November 30, 2017, 01:53:48 am »
Sorry, but this assumption is completely wrong.

I don't know where your information came from?

It's not required to specifiy a STARTUPDIR (a working directory) for the Setup string, so it can be left empty. Quite easy to check by using the template folder and creating a Program object from the Program template.

It looks like you've constructed and solved both of your own new issues, so that's sorted.

The single fact that the STARTUPDIR can be empty doesn't really mean anything. It's weird, but users do expect working software. The install procedure in question does create 744 WPProgram objects and sets 197 STARTUPDIRs, so I presume there's no need for such a proposed check. Nor test.

It being set by an author of an installer often appears to be random behaviour, and/or a result of pasted sample REXX code. In a way I'm pasting code of those installers too, and matching documentation of actually required settings is quite rare. The number of installers setting a STARTUPDIR was significantly more than 197, but now it isn't always 100% obvious anymore that the setting can be removed. Without breaking anything. Hence the original question.

SM still has the setting, unlike several objects pointing to simple EXEs.

Programming / Re: STARTUPDIR
« on: November 30, 2017, 01:08:01 am »
Some programs need to find their ini files and such, including the Mozilla apps that need to find their DLLs.

Is a generic conclusion that BAR.EXE reports the right current working directory, but if a file-related OS-specific API is involved (load module, open INI file, ...) then it should always be set, if anything to make sure that the OS ("SHELL.EXE") always uses the same working directory too? So even when BAR.EXE writes "Hello, INI file!" to its BAR.INI file?

Internet / Re: Experimental build of SeaMonkey
« on: November 29, 2017, 05:15:41 pm »
In this libpath I have the xull.dll modify with highmen

FWIW: are you using SET LIBPATHSTRICT=T and e.g. SET BEGINLIBPATH=y:\TEST;x:\yz\SEAMONKEY as (hidden) WPS settings for your SM test objects?

If so, then you may not be using the expected LIBPATH directory which contains a patched XUL.DLL.
If not, then you could consider to start using those settings to make sure that FF/SM will use expected DLLs, like a y:\TEST\XUL.DLL or a JPEG.DLL in SM's directory.

Programming / STARTUPDIR
« on: November 29, 2017, 04:47:23 pm »
Often one can reduce the size of INI files and install scripts by modifying what an install script (REXX, WarpIn, EXEs, ...) is doing. No object IDs for abandonware objects unless it's a WPFolder, not setting a value to its default value anymore because WPTOOLS once reported such a copied and pasted setting, using ENVIRONMENT variables instead of Microsoft's OS2ENVIRONMENT, and so on.

Code: [Select]
Assuming this EXENAME setting of a new WPProgram object of a native OS/2 F:\OO\BAR.EXE, then when/why is it required to set the STARTUPDIR to the same F:\OO as BAR.EXE's directory?

Internet / Re: Experimental build of SeaMonkey
« on: November 27, 2017, 08:42:44 pm »
...Why would anyone advocate confining them to the bloated and largely pointless @unixroot tree unless absolutely necessary? Group-think? A fondness for arrogant and authoritarian mindset that BWW unfailingly displays?

I had also presented my dislike of "Filesystem Hierarchy Standard" many times in the past. Even some groups of the Unix world dislike it.

RPM was a good solution to keep all that updated, but it came with a cost.

If the number of lines of output exceeds 100, then using STDOUT instead of STDERR hardly requires resources. Of course there are more optional ways to OS/2'ify software. Icon, installer, documented data file search strategies not assuming an @Unixroot, deleting useless files, avoided useless requirements of requirements (like a HUNSPEL0.DLL without any installed dictionary), and so on.

I'll try to care less, but does a RPM release actually manage e.g .the lxLite package, including all documentation files, of eCS 2.x?

Internet / Re: Lightning (SM/TB)
« on: November 20, 2017, 02:19:28 pm »
Localization has been fixed, so the next version of Lightning should have a language pack.
Note, it was mostly localization issues, especially on Lightning, that prevented 2.42 and various other versions from being released.

Thank you. I'm happy with a localized 4.0.x, its use typically is restricted to replying as expected to rare, Microsoft-based invitations, but wouldn't have minded to look at localizing an upgrade to 4.7.x by using several translated input files in two of the XPI directories.

IIRCR the article in German suggested some "quick & dirty" update or compatibility issue, an/or solution, which was solved by herr Kohl with a matching German version, but I should have replied to that series of article back then.

Presumably a language pack is a superiour solution anyway, at leat compared to having to compile XPIs for several of the available OS/2 languages.

Web applications / Re: Oddities with Youtube.
« on: November 20, 2017, 02:02:50 pm »
I have an old machine that not even Mosaic will install on. I wholly agree with you that all new software should be fully backwards compatible with older hardware.

Both troll Andi B. and our new comedian haven't fully understood what P6+ means, which happens to be used by the developer of my OS/2 browser, nor that I don't mind dmik producing a product for an even smaller community. A freedom of choice.

My OS has a browser, which isn't FF. My new hardware has no OS, which won't be Andi's DE nor EN.

I do hope that even the boys can try to understand that requiring new hardware, on top of many other implied requirements, without a need to do so, is a great way to reduce the size of a community. A possible goals of your trolls, isn't it? Or just a selfish goal of you, presumably one of the happy few. For one Andi is, eCS 2.x is available in his native language. Good for you. Unlike you, I tend to not exclude over 50% of the user base.

Oh, if you can be arsed to do so: can you please provide a full quote which confirms what would be, according to you, my opinion that the FF for "OS/2" browser should support all old hardware, including but not limited the old hardware of our comedian or e.g. sa 80386? IRL I did advocate the upgrade to a P6 target, albeit ignorent, biased or selfish people and trolls tend to ignore such an annoying little factoid. You're trying to attack the upgrader, again, by making up the opinion of the upgrader. At least somone liked the entertainment. Go figure...

Article Discussions / Re: Sponsorship needed for new OS/2 web browser
« on: November 20, 2017, 01:39:20 pm »
I don't know what's going on here? UNIX' directory structure was adopted back in the days of DOS version 2.

You're smarter than that and know what I mean, without having to require users to always be technically accurate. This is not an Unix forum, while perhaps appriciating a more accurate report of both Unix and the history of MS-DOS. If I want an Unix directory structure with an own root, including but not limited to solutions like RPM, then I'll start using Unix. I won't.

I could have installed such a (full) structure while smiling and not noticing it, while installing eCS 2.x DE/EN or AOS EN. But DE nor EN still isn't the prefered foreign language of the OS over here, and the developers of eCs 2.x and/or couldn't be arsed to produce an official directory structure-related upgrade for OS/2 and eCS. Different products, smaller user base. Most of the non-DE/EN community of IBM's has already left us, often without telling us.

Thanks for explsainig what Mensys did, but it's quite obvious that resources are limited. The reduced number of eCS 1.x and 2.x languages, compared to Warp 4 FixPaxk 0, has reduced the size of the community too. That's nothing but a fact. Of life. I'm not demanding all files in one directory, but I'm often pointing out that such a change can, and should be avoided. FF45 is just an example of an important product "we" aren't using anymore, and so is an updated silly Qt-based game or most of the un-OS/2'ified GCC port. If I want most of Unix, then I'll start using Unix.

Article Discussions / Re: Sponsorship needed for new OS/2 web browser
« on: November 20, 2017, 01:18:19 pm »
when I take into account the number of bugreports in the firefox bug tracker by the main complainants I get the strong impression that complaining or even trolling is more important to some than actually helping getting bugs fixed.

Names, please. For example, people with your type of arguments tend to overlook that I'm not even really using FF for "OS/2", that I don't tend to provide personal data to create accounts to report bugs, that a bug tracker is the developer's system instead of mine, that I'm a happy user of an older version of SM, that I've never complained about Yeo's efforts regarding FF/SM/his standards, that I've guessed frame rate numbers quite frequently, that I've invested quite a lot of time in upgrades and matching downgrades, and so on. I've been critized frequently, even over here by a programmer of FF, while I'm not even using their latest non-OS/2 version of FF. I've stated frequently that efforts to keep up to date with FF's Agile are impressive. I've stated fequently that authors of ports tend to reduce the size of the OS/2 community, without recalling any serious comment that I was wrong (serious: not counting the author of FF, one of his main arguments was that RPM solved language difficulties of users of OS/2). I've stated that the author of FF for "OS/2" is allowed to release a Pentium 4 version for a 80386 OS, and so on. If I would actually use FF, then I have no reason to believe that all of my latest issues with FF for "OS/2" cannot by reproduced by a $10 Pentium III test install. The author of FF for "OS/2" has offered solutions for unreported bug over here, which just show that reporting some broken components is 100% useless: use an OS with a foreign language users may not understand (DE/EN), and buy matching new hardware. I already know that was the reply to unreported bugs, which also explains why I'm not even using nor funding their work, and I didn't need dmik's silly arguments (a.o. "I'm Russian") to presume such a "solution". And so on. Which part of "I'm not really using FF, SM is my browser" isn't always clear?

Hence the question: names (plural), please? Why are you even using a bug tracker to check people? How do you know that I wasn't a bug tracker's (virtual) "user1235"? Why are you insulting anonymous people with your troll remarks? What's your definition of a troll? I, for one, would suggest the use of a better benchmark than a system of a developer of a product I'm not using, with a CTO who first described that ignoring (potential) customers, in public, is a "great feeling" and next asks (potential) customers to send more money. An unqualified amateur. If something is broken now, then it's your benchmark. And, granted, sometimes one's initial attitude of a classic engineer.

A complicated, interesting fact is that public bug trackers do promote and support the underlying problems of commercial ICT methodes, including but not limited to Mozilla's rapid release cycle. There's no direct link, I'm not expecting an eCS 3.0 anymore. There is a reason why e.g. Agile ignores experts and why e.g. ITIL has to define that customers are satisfied. Satisfied by definition, not by solutions nor actual provided services. Users of active, public bug trackers are a part of a broken system, including but not limited to users having to donate their commercial or private data to a service provider of the author.

In a nutshell: sometimes I actually do "like" to complain about Microsoft, so according to a biased or non-evidence based point of view like yours I'm not a troll when I report everything I don't like about their supported products to Microsoft, by using Microsoft's bug tracking system with a Microsoft account, while not using or really wanting to use Microsoft's dominating products at all. Go figure...

Article Discussions / Re: Sponsorship needed for new OS/2 web browser
« on: November 20, 2017, 12:07:34 pm »
The problem is that generally developers have the latest machines, using a 64 OS with lots of memory and 32 bit will become more and more of an afterthought. We're seeing it in things like the recommendation to have 16GBs of virtual address space to build Mozilla as one example.

Or, less abstract and closer to home, by things like the assumption that OS/2 has a beloved Unix directory structure. I've stopped updating several apps because the old version is aimed at OS/2, while improved newer versions are aimed at the developer's eCS 2.x and AOS.

Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: November 18, 2017, 11:03:34 am »
If you ... can provide me the HardwareID (of the USB devices), it will be great.

If USB.IDS's Either Hand is not a generic vendor with a misleading name, then the information of the USB Device Monitor (and/or USB.IDS) is not reliable and all relevant details (mainly USB 2.0 and older) were already included.

If I ignore the fact that "all" devices probably won't have a single ID, e.g. a 8 GB and a 16 GB one? I've excluded a type of "Edition" (series names) I've never used, albeit that'll probably work too. So ...

... the left one of their Snow Edition series doesn't qualify. There's no USB version printed below its capacity of 64 GB. It may work, but that's unconfirmed and excluded by the USB 2.0 (or older) restriction of the product itself.

Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: November 18, 2017, 10:27:40 am »
When it comes to USB flash drives, it might be better to collect non-working modules as in my experience, they all work once set up correctly.

Nope. An IBM Pentium 4 desktop may accept a 2 GiB USB flash drive, but the combination of eCS and older IBM hardware won't. Lord knows why, but if WinXP replaces eCS then this device will work with older IBM hardware too.

Pages: [1] 2 3 ... 16