On Friday, 96/12/13, Murray Lesser wrote to David Noon about "Magic
code for DosSleep" as follows:

ML>     Just to confuse the record further, I am using red Warp 3 GA +
ML> FixPak 5.  I get "3.00" when I type VER from either an OS/2 or DOS
ML> text-mode session.

Hi Murray,

I get exactly the same results here from blue Warp 3.0 GA with no
fixpacks applied (yet).

ML> However, REXX SysOs2Ver gives 2.30, so it must
ML> use the API call DosQuerySysInfo to get the version number.  The
ML> version-return values for this API under OS/2 versions 2.0 through
ML> 3.0 are shown in a note to the API description in my early edition
ML> of the Warp 3 Control Program Programming Reference manual
ML> (G25H-7102-00). 

Yes, this is working as designed, however poor we might think the
design.

ML>     As I remember, the discrepancy was an advertised idiosyncrasy of
ML> Warp 3, supposedly for the benefit of those application programs
ML> that would not run if they didn't get a "20" as the major version
ML> type.  It was discussed at length in the OS2 echo at the time.

I remember it.

The ROT was _osmajor = 1-9 meant DOS, 10 meant OS/2 1.x and 20 meant
OS/2 2.x. Unfortunately, too many people coded a test of (_osmajor ==
20) instead of (_osmajor >= 20).

ML> I
ML> haven't the slightest idea what Warp 4 might return for a call to
ML> this API, since I don't expect to install it.

I plan to install the freebie that came with Dev Con 11, once I get NT
moved to a smaller partition.

ML>     DevCon 12 seems to assure us that Warp 3 will continue to be updated
ML> to cover the enhancements in Warp 4 that are important for those
ML> of us who aren't interested in speech recognition and aren't
ML> connected to anything except by modem (I'm not considering the
ML> cosmetic changes.)

We haven't seen Dev Con 12 on this side of the Atlantic yet. Vol. 11
has only been here about 4 or 5 weeks.

ML> Of course, this leaves commercial developers
ML> with the problem of what they might use to determine if their latest
ML> efforts will run on a particular system.  For example, if the app
ML> requires OpenDoc, the problem is no different if I am running the
ML> add-on provided in DevCon 12 for Warp 3, or the optionally
ML> installable capability of Warp 4.  If I were writing programs for
ML> anything other than my own amusement on my own system that used
ML> OpenDoc, checking for a version number won't do it.  There has to be
ML> a better way.

There is a direct parallel on the mainframe. Some IMS programs require
version 5 of IMS-TM/DM, but version 4 runs just fine under the same
level of MVS/ESA. The version of MVS is readily determined, but
detecting the version of IMS is a little more sporty.

Thus, if a program requires a given level of OpenDoc, it cannot depend
on the level of OS/2. The OpenDoc support routines should offer an API
to return the level of support available. I just hope they don't use
the same kind of hacks that are used to determine the level of Win32s
support in Windows or WIN-OS2.

The simple answer is to document the system requirements and insist
the users RTFM before calling for support. Alas, too few PC users are
mainframe systems programmers.

Regards

Dave


 * KWQ/2 1.2i * Windows: an Unrecoverable Acquisition Error!

--- Maximus/2 3.01