Subj : Extending Pl/I To : Murray Lesser From : David Noon Date : Thu Feb 22 2001 12:30 am Hi Murray, Replying to a message of Murray Lesser to David Noon: DN>> 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. ML> PL/I is also extensible :-). (Almost any compiled language and ML> many interpreted languages are extensible with assembled procedures. ML> I wrote three books in the 1980s dealing with extending various ML> 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. ML> There used to be less necessity for ML> extending PL/I than for extending REXX, and it is much more ML> difficult. Extending PL/I may have become more likely for those of ML> us who write text-mode utilities, now that IBM has dropped the PL/I ML> 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. DN>> 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. ML> Hmmm. Is that new fashion the reason IBM dropped the ability to ML> compile PL/I procedures calling the 16-bit bsesub.cpy OS/2 API ML> 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. ML> I keep a copy of the ML> FP-4 version of my compiler in a different partition, just to avoid ML> having to "extend" PL/I with assembled procedures. Once compiled, ML> 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). DN>> 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. ... :-) ML> Thanks for the kind words. However, Mike should note that I am ML> one of the _only_ two members of this echo who admit to having an ML> acquaintance with PL/I. I recall Will Honea admitting some brief dalliance with PL/I a couple of years ago. ML> If he really needs technical advice, he ML> should do what I do: ask you :-). :-) Regards Dave --- FleetStreet 1.25.1 * Origin: My other computer is an IBM S/390 (2:257/609.5) .