(David Noon wrote to Mike Luther on 02-17-01, topic: "Language For Multi-platfo")

Hi David--

(In the following, "ML>" identifies a quote from Mike Luther.)

Replying to a message of Mike Luther to Murray Lesser:

More interestingly, REXX is an extensible language. This means you

>can write extension DLL's in whatever native code language you
>fancy, provided it supports _System linkage convention. There are
>plenty of samples in C, and I have posted samples in PL/I
>and assembler. Thus, when the base language runs out of
>capability or too slowly, branch off into some native
>object code to do the fiddly bits.

PL/I is also extensible :-). (Almost any compiled language and
many interpreted languages are extensible with assembled procedures. I
wrote three books in the 1980s dealing with extending various dialects
of MS BASIC compilers). There used to be less necessity for extending
PL/I than for extending REXX, and it is much more difficult. Extending
PL/I may have become more likely for those of us who write text-mode
utilities, now that IBM has dropped the PL/I capability to make direct
calls to the 16-bit OS/2 APIs.

None of the major development tools vendors is supporting

>16-bit code any more, except in their assemblers. All
>modern compilers produce 32-bit code exclusively. The
>upshot is that DOS is dead. Indeed, there is no ISO/ANSI-
>certified C++ compiler for 16-bit DOS, AFAIK. [Jonathan
>might know of one.] All the 16-bit C compilers are C89 or
>worse [K&R], with no C99 compilers available. As I said,
>DOS is dead.

Hmmm. Is that new fashion the reason IBM dropped the ability to
compile PL/I procedures calling the 16-bit bsesub.cpy OS/2 API
functions, in FP-6? Another loss to fashion? I keep a copy of
the FP-4 version of my compiler in a different partition, just to avoid
having to "extend" PL/I with assembled procedures. Once compiled, the
calls run fine under the runtime DLLs that came with FP-6.

PL/1(i), whatever, OS/2, Win-ugh, DOS .. and REXX, are they really suitable tools for poor Mikey?

It's PL/I.

Only you can answer the question. How you collect

>background information to formulate the answer is up to
>you. But you have been given information from the two
>members of this echo who have the most experience with
>PL/I, and we both know/knew C too. I also know C++ quite
>thoroughly. And I dabble in REXX a bit, too. ... :-)

Thanks for the kind words. However, Mike should note that I am one
of the _only_ two members of this echo who admit to having an
acquaintance with PL/I. If he really needs technical advice, he should
do what I do: ask you :-).

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * Never send a PM program to do a text-mode job

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Is this, grin .. (In which ML refers to Murray Lesser)

Thanks for the kind words. However, Mike should note that I am one
of the _only_ two members of this echo who admit to having an
acquaintance with PL/I. If he really needs technical advice, he should
do what I do: ask you :-).

another variation of the 20 pound vs. 40 pound boll weevil joke? That Murray is the lesser of the weevils?

Huge grin.

Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hi Murray,

Replying to a message of Murray Lesser to David Noon:

More interestingly, REXX is an extensible language. This means you

can write extension DLL's in whatever native code language you
fancy, provided it supports _System linkage convention. There are
plenty of samples in C, and I have posted samples in PL/I and
assembler. Thus, when the base language runs out of capability or too
slowly, branch off into some native object code to do the fiddly
bits.

PL/I is also extensible :-). (Almost any compiled language and
many interpreted languages are extensible with assembled procedures.
I wrote three books in the 1980s dealing with extending various
dialects of MS BASIC compilers).

Moreover, PL/I is extensible (at least lexically) in PL/I. See the language reference manual for the description of %PROCEDURE ... STATEMENT, under the macro preprocessor.

There used to be less necessity for
extending PL/I than for extending REXX, and it is much more
difficult. Extending PL/I may have become more likely for those of
us who write text-mode utilities, now that IBM has dropped the PL/I capability to make direct calls to the 16-bit OS/2 APIs.

Yes, if IBM removes in-line thunking one must use a thunk layer of some sort, or re-visit the issue of keyboard/mouse/screen handling completely.

None of the major development tools vendors is supporting

16-bit code any more, except in their assemblers. All
modern compilers produce 32-bit code exclusively. The
upshot is that DOS is dead. Indeed, there is no ISO/ANSI-
certified C++ compiler for 16-bit DOS, AFAIK. [Jonathan
might know of one.] All the 16-bit C compilers are C89 or
worse [K&R], with no C99 compilers available. As I said,
DOS is dead.

Hmmm. Is that new fashion the reason IBM dropped the ability to compile PL/I procedures calling the 16-bit bsesub.cpy OS/2 API
functions, in FP-6? Another loss to fashion?

Not really.

The reason nobody produces 16-bit compilers these days is that a back-end that produces 16-bit code is more expensive to develop than one that produces 32-bit
code, and the vendor is obliged to produce a 32-bit back-end simply to support the modern CPU hardware. It is a matter of cost/benefit: the 16-bit code benefits very few people, but costs a packet.

I keep a copy of the
FP-4 version of my compiler in a different partition, just to avoid
having to "extend" PL/I with assembled procedures. Once compiled,
the calls run fine under the runtime DLLs that came with FP-6.

Of course. But "thunking down" to call a 16-bit API is not quite the same thing
as producing an entire 16-bit application, which is what Mike seems to want.

What would be nice would be to have IBM supply a 32-bit DPMI extender (a la Watcom, R.I.P.) and allow the 32-bit code to be linked as a DOS application (LE-format executable), as well as or instead of an OS/2 application (LX-format
executable) or Win32 application (PE-format executable).

Only you can answer the question. How you collect

background information to formulate the answer is up to
you. But you have been given information from the two
members of this echo who have the most experience with
PL/I, and we both know/knew C too. I also know C++ quite
thoroughly. And I dabble in REXX a bit, too. ... :-)

Thanks for the kind words. However, Mike should note that I am
one of the _only_ two members of this echo who admit to having an acquaintance with PL/I.

I recall Will Honea admitting some brief dalliance with PL/I a couple of years ago.

If he really needs technical advice, he
should do what I do: ask you :-).

:-)

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)