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 --- FleetStreet 1.25.1 * Origin: My other computer is an IBM S/390 (2:257/609.5) .