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 ... 17
Comments, Suggestions & Questions / Re: Censorship complaints
« on: February 26, 2018, 06:32:44 pm »
write absolutely anything you want (excluding if you are from one of about 100 nations where you will go to jail)
The single fact that someone else can insult about 100 nations just confirms that the moderators are unqualified volunteers with a rather random nepotism policy. This Andreas isn't that bad, and typically he's accountable and replies. If you don't like it, then perhaps try to read what you don't like less often, or get used to sometimes having to read between the lines.

Setup & Installation / Yet another eCS 1.2-fix by users
« on: January 22, 2018, 07:20:38 pm »
Assuming a default install, as usual, with an original copy of UniAud:

x:\MMOS2\UNIMIX.EXE requires LIBC04.DLL, which is missing.

Installing a copy of LIBC04.DLL in e.g. x:\ECS\DLL or x:\MMOS2\DLL will result in a different fatal error message, but at least its text is better than the originally reported missing system DLL.

Programming / Re: DHCP client
« on: January 01, 2018, 05:20:22 pm »
As usual he's just trying to produce his own trolls, over and over again: if we all use the 100% irrelevant XWP or XWP derivates, then so do I, isn't it!?

On Shutdown @ Hobbes appears to be one of the existing utilities in question, and confirms that such a solution is not a bad practice.

A quick test of the concept, with different orders of execution, shows that On Shutdown doesn't avoid a dialog of e.g. a "normal" WPA_SUPPLICANT.EXE background session. If you close this session first, then apparently On Shutdown shows an own dialog too because it cannot kill that closed session anymore, so it isn't fully hidden.

Programming / Re: DHCP client
« on: January 01, 2018, 04:41:59 pm »
It doesn't do that on my IBM R61 laptop, maybe because as Andi mentioned, we all use xwp or derivatives  :)

As usual he's just trying to produce his own trolls, over and over again: if we all use the 100% irrelevant XWP or XWP derivates, then so do I, isn't it!?

On Shutdown @ Hobbes appears to be one of the existing utilities in question, and confirms that such a solution is not a bad practice.

Programming / Re: DHCP client
« on: January 01, 2018, 04:20:06 pm »
From memory there is a utility to do exactly what you are talking about as I used it in the early 2000's, I just cant remember what it's called :(
Hopefully someone else will remember it.

Which implies the answer to the question is: yes. Thank you, now I'll consider writing my own. Apparently all OS/2 WPA2 DHCP clients have to show a close-dialog to an user shutting down, which ... blows. Additionally the ISC one even executes a visible, important MODE command without using e.g. DETACH.

Programming / DHCP client
« on: December 30, 2017, 01:54:32 pm »
Is it possible to write a "hidden" (i.e. out of sight) third-party PM app for any version of the OS, which waits for the system to shutdown (and then e.g. kills the DHCP client when WPA2 was used, without bothering the user with a dialog)?

Or is it bad practice to start any new session, like a CMD file which would become the (quick) killer?

Multimedia / Re: Saving OS/2 icons - OS/2 icon format in 2017
« on: December 23, 2017, 09:18:41 am »
Mind that small things are not noticeable, so your icon must consist of simple things which are also recognizable when its 20x20 or 16x16.


No, it mustn't. In lazy mode an unmodified image which was nothing but resized may stop being recognizable indeed, but some apps (including IBM's) do use different images for different sizes. If, for example, the brand name "Joop!" looks good in 40x40 mode, then one could use the same font's "J!" in 16x16 mode.

Regarding small details, it can be enough to suggest a shape too, just like a 16x16 "Jeep!" will probably look like a 16x16 "Joop!". An advantage of small sizes is that's harder to notice such a difference too, as long as "Joop!" itself is iconic on its own.


Multimedia / Re: Saving OS/2 icons - OS/2 icon format in 2017
« on: December 23, 2017, 09:04:26 am »
"taskbar.ico" does not render on the OS/2's desktop.


It does with another OS/2, but first you'll have to delete the next best matching sizes of (IIRC) 64x64 and 48x48 too. With 16x16, 20x20, 32x32, 40x40 and 128x128 it works as expected. There is an unverified, guessed possibility that 128x128 doesn't match the preferred 40x40, and that the OS selects the next largest size just once. This isn't an expected size, hence a default icon instead of a 64x64 or 40x40 icon. Changing the order of sizes may help.

So apparently a fully working icon file can include the size 128x128, but not all possible sizes of PNG icon files of Unix ports.


Applications / Re: Establishing Wlan Connection by Command Line
« on: December 23, 2017, 08:35:48 am »
start dhclient


1. Couldn't this more visible DHCP client be morphed into a more hidden (non-tasklist) PM app, which reacts to e.g. WM_QUIT without bothering the user?

2. Is DHCONF.CMD an undocumented requirement of XWLAN 3.12 (didn't check 3.13, 3.12 just mentions the EXE) too?


General Discussion / Re: OS/2 application developers
« on: December 21, 2017, 03:18:55 pm »
At a minimum, any such things we have seen in the past, we shouldn't see in the future.

Arithmetic precision in REXX is arbitrary at the expense of lengthier/slower operation.


If one wants to promote DosOpenL as some new default, why not, then one has to make it easier to replace DosOpen/fopen/... by DosOpenL, regardless of the development environment (Cs, Pascals, BASICs, ...). Unfortunately it's harder than just appending the L.

I'm not sure there's such a thing as arithmetic precision in REXX, even if we ignore rounding due to NUMERIC DIGITS settings. No numbers, no arithmetic precision. With any programming language with 8-bit numbers you can compile a string which represents a result and stop when the length of the compiled string is N characters.

As such a proper design of DosOpenL isn't required. It's possible to use the best available API, which is e.g. DosOpen XOR DosOpenL. A wrapper takes care of that.


General Discussion / Re: OS/2 application developers
« on: December 21, 2017, 02:50:22 pm »

Phase -1: implement your own LONGLONG
Phase 0: add a wrapper, DosOpenL isn't always available

Easy phases 1 and beyond: append a L to DosOpen or replace DosOpen()

VAC4's fatal new errors

FWIW: calculated output was different, compared to C and REXX. It may be a VAC3.65/VAC4 bug, it may be some change of the C programming language. Since I'm not being paid by the hour I stopped trying to append the L, mainly because of phase -1 and the errors.


General Discussion / Re: OS/2 application developers
« on: December 18, 2017, 03:41:33 pm »
Today, every application should use the "L" type of functions: DosOpenL, DosSetFileSizeL, DosSetFilePtrL, etc.

Should. Not every development environment of every application is aware of a LONGLONG, and implementing your own LONGLONG variable is slightly harder than appending a reasonable L. If a development environment supports LONGLONG by default, then it resulted in a broken app (VAC3.08 -> VAC4FP2, IIRC).

I wish it was as easy as appending an L, and implementing my own LONGLONG is a bit over the top for an app which typically won't be used with huge files. Nevertheless I've looked at appending it, but it resulted in VAC4's fatal new errors.

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.

Pages: [1] 2 3 ... 17