• Language for multi-platform

    From David Noon@2:257/609.5 to Mike Luther on Saturday, February 17, 2001 12:55:28
    Hi Mike,

    Replying to a message of Mike Luther to Murray Lesser:

    However, if you are not in too much of a hurry at run time, you
    could write your application in REXX.

    I investigated that .. but actually gave up on it, as one reason, for precisely the exact same reason you noted above. I carefully avoided
    all CHAIN operations and chose to carry all the required parameters
    for control passage between executables as disk I/O. I thought that
    made more sense in planning for portability. Thus executable
    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.

    That is also one of the reasons I winced when I tried Visual Age for
    Basic in OS/2 which I bought and have! Sure the ball bounces! But
    by the time you ever see it bounce, your opponent has already stolen
    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.

    If, a la as PowerBASIC finally did for WIN-ugh, M/S and IBM had ever released a full compiler version of VB, that would have run on both
    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.

    REXX has the same SELECT construct as does
    PL/I. (REXX was derived, in part, from PL/I; in the same sense that
    the original line-by-line-compiled Dartmouth BASIC was derived from
    FORTRAN.) I got my copy of REXX for DOS (Personal REXX v 3.0 by
    Quercus Systems) in 1991. It may still be available.

    Here comes the education! Yes, if true, a part of portability sure
    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.

    When Gordon Letwin crafted the foundation for OS/2 he also happened to
    be the Chief Architect of the PDS Compiler! Somewhere in my printed
    text I happen to have read his remark, I think it's his, that, "The arrival of a new language is marked by the arrival of the first true compiler." That's, in my feeble understanding of things, a very
    correct statement.

    All too many modern languages cannot be compiled (e.g. SmallTalk).

    Because of the way that PDS 7.1 was written to integrate the assembler operations for the HEX21 interrupt work so well into BASIC, we got
    two very,very important things cross-referenced to both OS/2 and DOS!
    We got a terribly simple-to-implement full network file I/O system
    with file lock,record lock; shared multi-user tools. And to a lesser note, we also got the entire ISAM file engine buttoned up so that
    even a dunce like Mikey could learn to use and implement full
    networked file I/O with deadlock intervention and all that!

    Compared to what is potentially ahead for you, that facility is crude and limited.

    You know that insane feeling, the whirl of the dance, it plays with
    you, it plays with you. And when the room quits spinning, "Morning
    is breaking, comes the first morning ..."

    Please go easy on the Cat Stevens. ... :-)

    [And it's "Morning has broken, like the first morning ..."]

    Gee, playing that hymn on
    a Baldwin concert grand is just like the computer keyboard when I
    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.

    I still have somewhere, I think, the FidoNet post Bob Juge posted that chided me for even comparing DesqView to OS/2. I think that is one
    of the landmark posts I've ever had addressed to me. I listened
    CAREFULLY to what Bob said, took his advice. But ... in doing so,
    the superb work of Gordon Letwin with PDS 7.1's FAMILY approach to programs and, specifically,the business of full network aware I/O,
    has been, to me a mess elsewhere.

    We can safely forget FAPI too.

    Where do I go to get the complete cadre of INT21 network tools, in
    such a concise form as I've learned and written stuff for
    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!

    Remember! It isn't that
    it can't be done in other languages that are available in OS/2!

    It's that I have to be able to extend the services *BACKWARDS* in DOS, yes,pure DOS for another seven damned years after I make the toolset 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.

    That and another of Gordon's diamond sharp gifts, variable length
    string arrays with the assembly language automatic trashman! I
    listened! I listened! I learned a little, enough to know I ain't
    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.]

    I need two things, big time! I need multi-dimensional variable-length string arrays, that, in fact, can be dimensioned, not as you might
    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.

    and full network aware file I/O shared read-write lock and deadlock protectable.

    File locking is intrinsic to PL/I's record-oriented I/O. There is an UNLOCK statement too.

    Can REXX, for example, and PL/1, in one easy common source code caper,provide me with full support for OS/2, WIN-ugh, and DOS, for
    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.

    And don't you, huge grin, tell me like Paul Sittler used to and keeps telling me, "Write your own functions, stupid!" I won't live long
    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.

    I've spent many hours with Ileff vectors, all that. I still can't
    quite get Watcom C++ to let me get through the string game, but I'm
    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.

    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.

    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. ... :-)

    Regards

    Dave
    <Team PL/I>

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