Subj : PL/I v 2.1 FixPak 6 To : Andy Roberts From : Murray Lesser Date : Wed Jul 26 2000 11:58 am (Excerpts from a message dated 07-26-00, Andy Roberts to Murray Lesser) Hi Andy-- Thank you for your offer of help for my dilemma with regard to IBM having dropped the support for 16-bit calls in the PL/I compiler FP6. But, the offered cure may well be worse than the disease :-(. AR>--- FWUTILS --- >Conapi.Zip 02-11-100 64,787 > JdeBP's 32-bit Unicode Console API, with Developers' Toolkit, >which allows one to eliminate one more 16-bit vestige from OS/2: the >16-bit thunking code that has to be included in any otherwise 32-bit >application that uses the existing 16-bit Console API that is supplied >with IBM OS/2 (a.k.a. the VIO, MOU, and KBD subsystems) even in the >very latest versions. By using the 32-bit Unicode Console API, >applications can be made purely 32-bit (as long as they don't call >any other 16-bit APIs and don't use the 16-bit Console API internally >within their compiler's runtime libraries, of course). Also included >is an entrypoint-compatible replacement for the broken 32TEXT package >from IBM that used to be on the DevCon CD-ROMs. Instructions are in >README.TXT. (c) Copyright 1999-2000 Jonathan de Boyne Pollard. All >Rights reserved. AFAIK, all IBM OS/2 compilers that allow calling 16-bit API functions provide the thunking code automatically. Particularly when, as in PL/I, one can specify variables to be passed either by value or by address. (I remember having to throw in a DosFlatToSel() when I was programming in C; until this FixPak, the PL/I compiler did it for me.) AR>Conrt.Zip 02-11-100 15,545 > JdeBP's 32-bit Unicode Console API Runtime DLLs for OS/2 (c) >Copyright 1999-2000 Jonathan de Boyne Pollard. All Rights reserved. >Install these if your application uses the 32-bit Unicode Console API >and you are running 32-bit IBM OS/2 (i.e. version 2.0 or later). >Instructions are in README.TXT. >--- AR>I'll gladly File Attach those to E-Mail. Thank you kindly for the offer, but I think it best to decline. Being a pessimist at heart, I can see the drawbacks to using JdeBP's "cures" for my self-induced problem. The obvious one is that I would have to rework his "include" files (presumably written in C) to put them into PL/I format. While I have a utility that is supposed to aid in this (it came with the compiler) I have never tried it, so don't know what I would have to do to get it to work. (It has been a long time since I have programmed anything in C other than fairly trivial "external function" DLLs for REXX; I have never programmed in C++.) Also, if I understand what I read, I would have to go back and rewrite and recompile all my current static-link library routines to call these new "API" functions. (The existing procedures run fine, as is, under the "new" FP6 runtime DLLs; it's just that I can't write any new ones under this version!) After rewriting and recompiling all my old separately compiled procedures, I would have to recompile all my old utilities that used them and relink to the new procedures, because it appears that I couldn't allow both 16-bit and 32-bit KBD and VIO calls to exist in the same program if I were to use JdeBP's offerings. (IMO, one of the major failings of JdeBP's "improvements" is that he doesn't believe in "backwards compatibility." In order to use his offerings, one has to drop the way one has been doing things for years, and start over doing them his way :-(.) So, I have taken the easy way out: I have already restored my "back" version (FP4) compiler from my backup (on a Zip Diskette containing only the contents of my "compiler" partition before I updated the PL/I compiler), and will live with it. Regards, --Murray ___ * MR/2 2.30 #120 * Newer is not necessarily better. --- Maximus/2 3.01 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000) .