Subj : Language for multi-platform
To : Mike Luther
From : David Noon
Date : Sat Feb 17 2001 12:55 pm
Hi Mike,
Replying to a message of Mike Luther to Murray Lesser:
ML>> However, if you are not in too much of a hurry at run time, you
ML>> could write your application in REXX.
ML> I investigated that .. but actually gave up on it, as one reason, for
ML> precisely the exact same reason you noted above. I carefully avoided
ML> all CHAIN operations and chose to carry all the required parameters
ML> for control passage between executables as disk I/O. I thought that
ML> made more sense in planning for portability. Thus executable
ML> shifting and load time is important.
The switch of execution context in REXX is much more rapid than a CHAIN in
BASIC. [The longest time I ever saw a compiled BASIC system take for a CHAIN
statement was just over 45 minutes, but that was on a DEC PDP-11/70 in 1977.
Modern machines are a tad more powerful.]
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> That is also one of the reasons I winced when I tried Visual Age for
ML> Basic in OS/2 which I bought and have! Sure the ball bounces! But
ML> by the time you ever see it bounce, your opponent has already stolen
ML> the interpreter and scored ten goals with the silly compiled ball!
Visual Age for BASIC runs slower than almost anything else. It is on a par with
Java for poor execution performance. Even the 2-CD "fixed" version was slower
than treacle.
ML> If, a la as PowerBASIC finally did for WIN-ugh, M/S and IBM had ever
ML> released a full compiler version of VB, that would have run on both
ML> OS/2 and WIN-ugh, the world would have been VERY different today!
IBM was not into native object code when VAB (originally named "Bart") was
being planned and developed. The company is still into Java byte codes in place
of object code, as that sells more hardware for fewer end-user results.
ML>> REXX has the same SELECT construct as does
ML>> PL/I. (REXX was derived, in part, from PL/I; in the same sense that
ML>> the original line-by-line-compiled Dartmouth BASIC was derived from
ML>> FORTRAN.) I got my copy of REXX for DOS (Personal REXX v 3.0 by
ML>> Quercus Systems) in 1991. It may still be available.
ML> Here comes the education! Yes, if true, a part of portability sure
ML> might be made between OS/2 and back-level DOS!
Quercus Personal REXX is still around, I believe.
However, PC-DOS 7.0 (or patched to PC-DOS 2000) comes with REXX built-in. It
also has an extension function facility.
ML> When Gordon Letwin crafted the foundation for OS/2 he also happened to
ML> be the Chief Architect of the PDS Compiler! Somewhere in my printed
ML> text I happen to have read his remark, I think it's his, that, "The
ML> arrival of a new language is marked by the arrival of the first true
ML> compiler." That's, in my feeble understanding of things, a very
ML> correct statement.
All too many modern languages cannot be compiled (e.g. SmallTalk).
ML> Because of the way that PDS 7.1 was written to integrate the assembler
ML> operations for the HEX21 interrupt work so well into BASIC, we got
ML> two very,very important things cross-referenced to both OS/2 and DOS!
ML> We got a terribly simple-to-implement full network file I/O system
ML> with file lock,record lock; shared multi-user tools. And to a lesser
ML> note, we also got the entire ISAM file engine buttoned up so that
ML> even a dunce like Mikey could learn to use and implement full
ML> networked file I/O with deadlock intervention and all that!
Compared to what is potentially ahead for you, that facility is crude and
limited.
ML> You know that insane feeling, the whirl of the dance, it plays with
ML> you, it plays with you. And when the room quits spinning, "Morning
ML> is breaking, comes the first morning ..."
Please go easy on the Cat Stevens. ... :-)
[And it's "Morning has broken, like the first morning ..."]
ML> Gee, playing that hymn on
ML> a Baldwin concert grand is just like the computer keyboard when I
ML> first discovered INT21, I swear it!
The INT 21H interrupt is not especially special, especially once one forgets
raw DOS and uses a system with greater facilities.
ML> I still have somewhere, I think, the FidoNet post Bob Juge posted that
ML> chided me for even comparing DesqView to OS/2. I think that is one
ML> of the landmark posts I've ever had addressed to me. I listened
ML> CAREFULLY to what Bob said, took his advice. But ... in doing so,
ML> the superb work of Gordon Letwin with PDS 7.1's FAMILY approach to
ML> programs and, specifically,the business of full network aware I/O,
ML> has been, to me a mess elsewhere.
We can safely forget FAPI too.
ML> Where do I go to get the complete cadre of INT21 network tools, in
ML> such a concise form as I've learned and written stuff for
ML> shared-locked file I/O with other than C?
You don't get them at all in C!
All those facilities are external calls as non-standard extensions to the C
Standard Library. Functions like int86x(), etc., are not at all portable. They
aren't even a reasonably mnemonic way of coding. And they aren't part of C!
ML> Remember! It isn't that
ML> it can't be done in other languages that are available in OS/2!
ML> It's that I have to be able to extend the services *BACKWARDS* in DOS,
ML> yes,pure DOS for another seven damned years after I make the toolset
ML> switch!
How DOS is DOS? Remember that much of what you are asking for is implemented by
add-ons such as TSR's. I have largely dropped DOS support in my work these
days, unless something serendipitous happens such as a 32-bit DPMI extender
offering facilities that allow some code to work in DOS too.
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> That and another of Gordon's diamond sharp gifts, variable length
ML> string arrays with the assembly language automatic trashman! I
ML> listened! I listened! I learned a little, enough to know I ain't
ML> very smart.
Gordon Letwin did not invent variable length strings, nor did he invent garbage
collection. These were both mature technologies by the late 1960's, some 20
years before MS BASIC PDS 7.1. [Read some of Bill McKeeman's papers published
through Stanford in the mid-to-late 1960's for some insight into both of these
topics.]
ML> I need two things, big time! I need multi-dimensional variable-length
ML> string arrays, that, in fact, can be dimensioned, not as you might
ML> suppose most folks do, but as DIM A$(-150 to +150, 10), or the like,
How about:
DCL String_array(-150:150,10) CHAR(4096) VAR;
?
That's a PL/I declaration of an array of strings, varying in length up to 4096
bytes and subscripted from -150 to +150 in the first dimension and 1 to 10 in
the second dimension. Of course, the array bounds and the string maximum length
don't have to be constants in most contexts; they can be arithmetic expressions
involving variables of "outer scope" if needed.
ML> and full network aware file I/O shared read-write lock and deadlock
ML> protectable.
File locking is intrinsic to PL/I's record-oriented I/O. There is an UNLOCK
statement too.
ML> Can REXX, for example, and PL/1, in one easy common source code
ML> caper,provide me with full support for OS/2, WIN-ugh, and DOS, for
ML> these?
For 16-bit DOS you could be constrained by your environment, and by the elderly
Digital Research compiler.
For OS/2 and Win32 you are off and racing with PL/I. All you ask for is built
into the base language.
ML> And don't you, huge grin, tell me like Paul Sittler used to and keeps
ML> telling me, "Write your own functions, stupid!" I won't live long
ML> enough!
Functions? That is making one's point the hard way.
The use of function calls to perform I/O is one of the worst features of C, and
one reason why the iostreams of C++ make that language a major leap forward. An
even better approach is the use of native language statements, a la COBOL, so
that the compiler is aware of the semantics of I/O. This is also the PL/I
approach, liberally plagiarised from COBOL, except for handling raw
bytestreams.
ML> I've spent many hours with Ileff vectors, all that. I still can't
ML> quite get Watcom C++ to let me get through the string game, but I'm
ML> close.
Good luck.
C's string semantics are so divergent from BASIC's that this could be quite a
tough port. If you are using a C++ string class then you are starting a little
closer.
ML> I think that's doable, and I know the file I/O bit is.
The file locking is actually a little sporty in C, as you will likely need to
... ugh ... write your own functions to call the native API [whatever that
might be].
The Watcom library is quite helpful here, though. Just be aware that not all
the exotic functions are available on all platforms, as they are not standard
C.
ML> PL/1(i), whatever, OS/2, Win-ugh, DOS .. and REXX, are they really
ML> 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. ... :-)
Regards
Dave
<Team PL/I>
--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)
