Hi David--

I spent entirely too much time yesterday (Sunday) downloading and installing FP6 for the PL/I for OS/2 compiler v 2.1. I lost connection
a little over halfway through the 2.5-hour download. When I restarted,
FTP Browser didn't "resume!" Probably my fault :-(. After I installed
the FP, I found (in the file READFP6.HTM), the following statement:

"On OS/2, all 16-bit support has been dropped."

I read this as meaning that there is no longer access to the 16-bit
OS/2 API calls :-(. My needs are for KBD and VIO calls, since there are
things that I wish to do in interactive text-mode applications that
cannot be done in "native" PL/I. (For example, waiting for, and then returning, keystroke values with "no-echo" can be done in REXX, but I
haven't found any way to do it in PL/I. I have a program that uses the returned scan code, as well as the character code, which cannot be done
(AFAIK) in either language!) As a test, just to make sure the quoted
message says what I was afraid it says, I tried recompiling my
KBREAD.PLI procedure and got a compile-time message to the effect that
the compiler didn't recognize the option "linkage(pascal16)" so was
ignoring it. When I linked the newly compiled version to a test driver
and ran it, I got an access violation exception!

Fortunately, I had a backup of my "language" (compiler) partition
made before installing the FixPak, so I deleted the "updated" IBMPLI
folder and restored from the backup. I have also sent a plaintive call
for "HELP!!!" to Carolyn at Team PL/I Support. If she (or you) can
offer a suitable workaround, I will reinstall FP6. Otherwise, the tag
line wins again :-).

During the process, I noticed that FixPaks do not delete obsolete
files :-(. BSESUB.CPY was still present: the file (dated 1-09-00)
apparently was last updated with FP5 :-).

Two questions: What could have led the PL/I perpetrators to do such
a dirty deed? More important, can you think of any other workaround
than the one I used (restored the previously installed version)?

Secondary purpose of this post: There has been no traffic for about
two weeks in either this echo nor in OS2REXX. If I don't get an answer
from you in the near future, I will assume: 1) You are on vacation, or
2) the problem is that Bob Juge has lost his feed for this echo. Of
course, this doesn't say anything about the Summer doldrums on OS2REXX,
does it?

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * If it ain't broke, don't FixPak it.

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Moin Murray!

24.07.2000, Murray Lesser wrote a message to David Noon:

(let me answer something, also to confirm that your msg made it to germany)

I spent entirely too much time yesterday (Sunday) downloading and installing FP6 for the PL/I for OS/2 compiler v 2.1. I lost
connection a little over halfway through the 2.5-hour download. When
I restarted, FTP Browser didn't "resume!" Probably my fault :-(.
After I installed the FP, I found (in the file READFP6.HTM), the
following statement:

"On OS/2, all 16-bit support has been dropped."

I read this as meaning that there is no longer access to the
16-bit OS/2 API calls :-(. My needs are for KBD and VIO calls, since
there are things that I wish to do in interactive text-mode
applications that cannot be done in "native" PL/I.

...

Two questions: What could have led the PL/I perpetrators to do
such a dirty deed? More important, can you think of any other
workaround than the one I used (restored the previously installed version)?

I don't know. But remember that 1) IBM always discouraged developers to use 16-bit APIs and 2) they dropped 16-bit support in the C++ part of VAC++ 4.0.

JdBP coded a DLL to supply 32-bit counterparts of Vio, Kbd and Mou (with or w/o
unicode support). AFAIR he annouced the package in OS2PROG. Look for this:

conapi.zip 66047 02-07-00* 32-bit Unicode Console API for OS/2 with
developers' toolkit (c) Copyright 1999-2000
Jonathan de Boyne Pollard. All Rights reserved.

IBM did the same while developing OS2PPC (a unsupported 32VIO archive floats arounds).

Secondary purpose of this post: There has been no traffic for
about two weeks in either this echo nor in OS2REXX. If I don't get
an answer from you in the near future, I will assume: 1) You are on vacation, or 2) the problem is that Bob Juge has lost his feed for
this echo. Of course, this doesn't say anything about the Summer
doldrums on OS2REXX, does it?

Your post was the first in OS2PROG since 4 July.

Bye,
Vitus

---
* Origin: Convert your Pentium into a Game Boy, run Windows NT! (2:2474/424.1)

Murray Lesser,

25-Jul-00 21:48:32, Vitus Jensen wrote to Murray Lesser

24.07.2000, Murray Lesser wrote a message to David Noon:

Subject: PL/I v 2.1 FixPak 6

"On OS/2, all 16-bit support has been dropped."

I read this as meaning that there is no longer access to the
16-bit OS/2 API calls :-(. My needs are for KBD and VIO calls,
since there are things that I wish to do in interactive text-mode
applications that cannot be done in "native" PL/I.

...

Two questions: What could have led the PL/I perpetrators to do
such a dirty deed? More important, can you think of any other
workaround than the one I used (restored the previously installed
version)?

I don't know. But remember that 1) IBM always discouraged
developers to use 16-bit APIs and 2) they dropped 16-bit support
in the C++ part of VAC++ 4.0

JdBP coded a DLL to supply 32-bit counterparts of Vio, Kbd and Mou
(with or w/o unicode support). AFAIR he annouced the package in
OS2PROG. Look for this

conapi.zip

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

Conrt.Zip 02-11-100 1

(Excerpts from a message dated 07-25-00, Vitus Jensen to Murray Lesser)

Hi Vitus--

24.07.2000, Murray Lesser wrote a message to David Noon:

I spent entirely too much time yesterday (Sunday) downloading and installing FP6 for the PL/I for OS/2 compiler v 2.1. I lost
connection a little over halfway through the 2.5-hour download. When
I restarted, FTP Browser didn't "resume!" Probably my fault :-(.
After I installed the FP, I found (in the file READFP6.HTM), the
following statement:

"On OS/2, all 16-bit support has been dropped."

I read this as meaning that there is no longer access to the
16-bit OS/2 API calls :-(. My needs are for KBD and VIO calls, since
there are things that I wish to do in interactive text-mode
applications that cannot be done in "native" PL/I.

>...

Two questions: What could have led the PL/I perpetrators to do
such a dirty deed? More important, can you think of any other
workaround than the one I used (restored the previously installed version)?

I don't know. But remember that 1) IBM always discouraged

>developers to use 16-bit APIs...

IIRC, the perpetrators of OS/2 2.0 assumed that nobody would be
writing text-mode programs any more, so they left the KBD, VIO, and MOU
API calls alone (16-bit leftovers from OS/2 1.x) and didn't provide much guidance in the early OS/2 2.x documentation as to how to use them.
However, until very recently, all IBM 32-bit OS/2 compilers have handled
the necessary thunking (in both directions) almost automatically (PL/I
was especially good at this, because you have the choice between passing variables by value or by address).

...and 2) they dropped 16-bit support in the C++ part of VAC++ 4.0.

While I don't understand this aberration, I might be able to
rationalize dropping the text-mode support for C++ in a "visual"
compiler. My little experience at the game has indicated that one
cannot write a text-mode program while using one of the visual program builders, irrespective of the language one is trying to build it in, so
one wouldn't have a reason to use these text-mode API calls while using
the "visual" VAC++ developer interface. However, I am under the
impression that the "command line" version of VAC++ 4.0 still allows
calling the 16-bit API routines. (I have no experience to verify this,
as I have never written a program in C++, nor have I ever owned any
version of VAC++.) But the only rationale I can really offer for IBM
dropping 16-bit support from its 32-bit OS/2 compilers is that such
support is platform dependent, and IBM is getting out of the
platform-dependent market.

All of my PL/I programming is for text-mode utilities, and is done
from the command line. I did try (once) to convert one of my
multi-threaded text-mode PL/I utilities, that included a call to
KbdCharin(), to a GUI program by using the "add-on" PL/I toolkit (visual program builder) for the purpose. After what I considered to be a
reasonable attempt, I gave it up as being entirely too much trouble. In
the newer "VA PL/I" compilers, the "program builder" GUI interface
version of the compiler is still an add-on that I never bothered to
install with my current "VA" PL/I for OS/2 compiler version 2.1.

JdBP coded a DLL to supply 32-bit counterparts of Vio, Kbd and Mou

>(with or w/o unicode support). AFAIR he annouced the package in
>OS2PROG. Look for this:

See my post to Andy Roberts for my excuse that adopting JdeBP's
solution would be not worth the effort it would require :-).

Secondary purpose of this post: There has been no traffic for
about two weeks in either this echo nor in OS2REXX...

Your post was the first in OS2PROG since 4 July.

It has already provoked two responses :-). Today, I am throwing in
my responses to those responses: two more. If this keeps up, we may end
up with a thriving echo again! Now, how do we get the OS2REXX echo
going?

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * Never send a PM program to do a text-mode job

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

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

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

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

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
<Team PL/I>
___
* 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)

Hi Vitus,

On 25-Jul-00, Vitus Jensen wrote to Murray Lesser:

Your post was the first in OS2PROG since 4 July.

The one from David on the 7th July didn't make it to you then... :-(

George

--- Terminate 5.00/Pro
* Origin: A country point under OS/2 (2:257/609.6)

Hi Murray,

Replying to a message of Murray Lesser to David Noon:

"On OS/2, all 16-bit support has been dropped."

Well, IBM has wanted to drop 16-bit support for about 8 years now, at least in newly developed code.

I read this as meaning that there is no longer access to the
16-bit OS/2 API calls :-(. My needs are for KBD and VIO calls, since there are things that I wish to do in interactive text-mode
applications that cannot be done in "native" PL/I.

I have seen suggestions that you use JdeBP's 32-bit shim DLL. This is actually quite reasonable. The change can be implemented using PL/I macro language, with
your original source being largely unchanged,

As a test, just to make sure the quoted message says what I was afraid
it says, I tried recompiling my KBREAD.PLI procedure and got a compile-time message to the effect that the compiler didn't recognize
the option "linkage(pascal16)" so was ignoring it. When I linked the newly compiled version to a test driver and ran it, I got an access violation exception!

Did you see any external references to DosFlatToSel() or DosSelToFlat() in the link map? If not, then no address "thunking" is being performed and no call thunking has been automatically generated.

Two questions: What could have led the PL/I perpetrators to do
such a dirty deed?

The product manager told them to do it. That's the prime mover of *all* architectural software changes.

What possessed the product manager to approve this "stroke of genius" I cannot fathom, but then I never could fathom the depths of the managerial mind.

More important, can you think of any other
workaround than the one I used (restored the previously installed version)?

Write your own call thunking routine in assembler. ... :-))

Secondary purpose of this post: There has been no traffic for
about two weeks in either this echo nor in OS2REXX.

It seems something has been badly broken in Fido for a few weeks now. Besides which, message traffic is always light during mid-summer recess. Normal service
appears to have been resumed.

Still, the slack time has allowed me finally to decomission my old 80486 system
and move totally to the AMD K6-III based machine I built a few months ago.

Regards

Dave
<Team PL/I>

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

(Excerpts from a message dated 07-30-00, David Noon to Murray Lesser)

Hi David--

Replying to a message of Murray Lesser to David Noon:

"On OS/2, all 16-bit support has been dropped."

I have seen suggestions that you use JdeBP's 32-bit shim DLL. This

>is actually quite reasonable. The change can be implemented using
>PL/I macro language, with your original source being largely
>unchanged,

Thanks, but no thanks. I'll just continue to live in the backwaters
of PL/I for OS/2 (v 2.1 FP4) and leave all my existing source code
alone. Personally, I can't see any less grief in having the "original
source being largely unchanged" than in having it "largely changed."
There is essentially the same amount of conversion, recompiling and
relinking involved in either case. Since I can see nothing in either
FP5 or FP6 that I need, there is no reason for me to "upgrade" just for
the sake of living with the latest version. (This is why I am still
running Warp 4 at FP5 level :-).)

I will admit that if had I taken your suggestion many moons ago, to
make my "private library" a set of DLLs, rather than a set of separately compiled static-link modules, going to JdeBP's offering would have made
sense. Mea culpa.

As a test, just to make sure the quoted message says what I was afraid
it says, I tried recompiling my KBREAD.PLI procedure and got a compile-time message to the effect that the compiler didn't recognize
the option "linkage(pascal16)" so was ignoring it. When I linked the newly compiled version to a test driver and ran it, I got an access violation Exception!

Did you see any external references to DosFlatToSel() or

>DosSelToFlat() in the link map? If not, then no address "thunking"
>is being performed and no call thunking has been automatically
>generated.

Didn't look. Perhaps I should have, but I took the compiler warning
and the access violation as sufficient proof :-(.

More important, can you think of any other
workaround than the one I used (restored the previously installed version)?

Write your own call thunking routine in assembler. ... :-))

What?!!! Who, me?

Still, the slack time has allowed me finally to decomission my old

>80486 system and move totally to the AMD K6-III based machine I built
>a few months ago.

Congratulations! Wear it in good health.

Regards,

--Murray
<Team PL/I>
___
* 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)

FYI, here is the complete text of a message from Carolyn that I
retrieved this morning (Tuesday).

Date: Mon, 31 Jul 00 08:15:38 PDT
From: "Team PL/I Support" <teampli@vnet.ibm.com>
To: mlesser@ibm.net
Subject: 16-bit OS/2 apis

Hi Murray,

I'm sorry to have to tell you this, but the decision stands to remove
the support for 16-bit OS/2 apis. The suggestion is to stay at
fixpak#5 for this support.

Regards,

Carolyn Phoa-Ting
Team PL/I Support

I'm not going to remind her that I don't have FixPak#5 because she
told me to wait for FixPak#6 :-). So, I shall hold at FixPak#4.

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * If you don't know what you are doing, don't.

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Hi David--

This is a message from the "eat your cake and have it too"
department.

As you may remember, I have been perturbed over the fact that IBM
has dropped support for thunking to and from 16-bit code from FP6 for
PL/I for OS/2. In my usual fashion, I complained and asked for help,
before thinking things through. Since all the help (all three replies)
were not useful to me, I decided to think things out for myself. I have
now solved my problem. (There may be several morals in this, but I'm
not going to dig them out.)

My easy solution to the problem requires no new 32-bit substitute
API calls, no recompiling, no relinking of existing programs, and still
allows me to use all the existing 16-bit OS/2 API calls. I determined
that the "new" upgraded version of PL/I for OS/2 will link calling
programs to "library" procedures that contain thunked code to/from
16-bit OS/2 APIs with no problems. The new runtime DLLs will run
utilities containing such thunked-code separately compiled utilities.
Eureka! So, I installed PL/I for OS/2 at FP4 level on a Zip diskette,
and added another icon (yclept "Old Pl/I Compiler") to my desktop. I
can now write and compile "new" separately compiled procedures
containing thunking code and load them into my static-link library. Once
filed in the library, they are available to all new PL/I programs written/compiled with the FP6 "new" version of the compiler, which has
again replaced its predecessor on my HD.

Of course, compiling off of a Zip diskette attached through the
parallel port is painfully slow (by modern standards). But I don't
suppose that I will do it very often, and it takes up an infinitesimal
amount of HD space. (HD space might be cheap by modern standpoints, but
not when that HD is the only one in an obsolete ThinkPad.)

For general interest, moving the compiler to the FAT-formatted Zip
diskette was very easy. I used the OS/2 BACKUP and RESTORE utilities,
to move all the extended attributes with it. All I had to change in the
REXX program that sets up the local compiler environment was all
occurrences of "H:" (the partition containing my compilers) to "K:" (the
Zip drive partition) and change the "parameters" line and the title of a
copy of the Program Object accordingly. I suppose that I could run both compilers in separate sessions simultaneously, if I could think of a
reason to do so :-).

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * Old engineering adage: there is more than one way to skin a
cat

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

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

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

I'll gladly File Attach those to E-Mail.

BTW, JdeBP is still down, so he can't reply in here yet.

Andy:
Please do me a HUGE FAVOR & file-attach copies of the above to

cookda@gate also?



Thanx in advance!

--- Maximus/2 3.01
* Origin: Gargoyle's Place BBS (1:365/3253)