🚀 go-pugleaf

In article <4112@media-lab.MEDIA.MIT.EDU> lenox@media-lab.MEDIA.MIT.EDU (Lenox H. Brassell) writes:
>Since the entry points described in OS2.DLL are not exported by name,
>the DosGetProcAddress() approach leaves something to be desired.  I
>understand that the reason you can't use the 1.1 OS/2 toolkit to produce a
>1.0 executable is that the ordinal entry points codes have changed between
>releases.
I doubt that this is true because it would prevent you from running a
program which was written under 1.0 and 1.1 under 1.2 or newer. Of
course, new ordinals were added. The docs say that ordinals should only
be used if the entry points will remain the same in future versions of
the software and I assume that this is true for the OS itself ...

>If the test you _really_ want to make is for long-filename awareness,
>the following (highly version-independent) code will tell you if a
>particular device has the restricted FAT naming convention:
>
... some code fragment deleted ...
>
>A disadvantage of this approach is that it requires write access to
>the drive in order to work.  An advantage is that it doesn't use

Another method (only requiring read access):
Try to DosOpen(), let's say, "C:\.HPFS.DETECTION" which is invalid for
FAT but valid for HPFS or other future - for example, Unix-compatible,
i.e. BSD - file systems. Simply try a DosOpen() for reading the file,
not for creation. In case of a FAT file system, the return code will be
either ERROR_INVALID_NAME or ERROR_FILENAME_EXCED_RANGE otherwise it
will (probably) indicate the the file was not found or return 0 if it
happens that such a file exists on the disk (in this case, close the
file). 

Since DosOpen() is a call that exists since 1.0 :-) and even is FAPI,
there should not be any portability problems.

Kai Uwe Rommel

--
/* Kai Uwe Rommel
 * Munich
 * rommel@lan.informatik.tu-muenchen.dbp.de
 */