Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!media-lab!lenox
From: lenox@media-lab.MEDIA.MIT.EDU (Lenox H. Brassell)
Newsgroups: comp.os.os2.programmer
Subject: Re: Dectection of HPFS File system?
Summary: a better way
Message-ID: <4112@media-lab.MEDIA.MIT.EDU>
Date: 19 Nov 90 20:03:30 GMT
References: <15510005@hpspcoi.HP.COM> <11686@hubcap.clemson.edu>
Organization: MIT Media Lab, Cambridge, MA
Lines: 36

In article <11686@hubcap.clemson.edu>, lsalomo@hubcap.clemson.edu (lsalomo) writes:
> 
> No no no no...If IBM (or Microsoft) even get around to porting OS/2 to other
> architectures, then your idea will (more likely than not) not work anymore.
> However, DosGetProcAddress looks up the API in the .DLL, which will be there
> REGARDLESS of what architecture you are on.
> 

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.

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:

   int UsesOnlyFATnames (char chDriveName)
   {
       char szTestDirName[] = "*:/..BadFatDirectoryName";
       USHORT usCode;

       szTestDirName[0] = chDriveName;
       usCode = DosMkDir (szTestDirName, 0L);
       if  (usCode == 0)
	   usCode = DosRmDir (szTestDirName, 0L);

       return usCode != 0;
   }

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
anything that is HPFS-specific: if you are on an OS/2 workstation
which is an NFS client, this test ought to tell you that long
filenames are safe on, say, a remote Unix drive.