🚀 go-pugleaf

Try using the DosGetProcAddr API to check for the DosQFSAttach API.  If it
returns NULL, then you are running under 1.1 .

This, along in the DosLoadResource (I think that's the API name) also comes
in handy for providing Help Manager support when the program is running under
1.2 , but supports 1.1 .

Cheers,
Q - the "Q"uestor for knowledge (, a degree, etc.)

lsalomo@hubcap.clemson.edu
ibmman@clemson.clemson.edu
=============================================================================
"Gee Wally, I think there's something wrong with the Beaver."
=============================================================================

dale@mks.com (Dale Gass) writes:

> I require a portable and efficient method of determining whether a given
> drive uses the HPFS file system.

I needed to do the same thing a while back.  What I did is have my program
look at the boot sector, which, in 1.2(1), contains a (text) field that
describes the file system.  The field isn't there for 1.1, so if it's not
there, you assume FAT.  (You can determine the offset of this field into
the boot sector by looking at a boot sector in ASCII format, with DEBUG,
SYMDEB, or Norton Utilities, for example.)  Your program can read the boot
sector using the usual DosOpen, DosRead calls if you open the drive for
direct access (by setting the DASD flag).

In article <1990Nov15.174907.19980@mks.com> dale@mks.com (Dale Gass) writes:
>However, since the DOS calls are dynamically linked, the mere external
>reference to DosQFAttach in the executable causes the program execution
>to fail at load time.
>
>What I require, is a portable way (i.e.  works on OS/2 1.1, 1.2) to
>determine whether a drive is a HPFS file system, without using calls
>that are unsupported in version 1.1.
>

In one of my programs, I have exactly the same problem. Currently, I use
DosGetModuleHandle() and DosGetProcAddress() to obtain the address of
the DosQFSAttach() call, which is DOSCALLS.182 (ordinal). I do this only
if the OS version is 1.2 or higher. I did not yet test the program under
1.1 but I am not very optimistic that it will run. Apparently, the
linker puts in some version number from DOSCALLS.LIB/OS2.LIB which
prevents loading of some programs under 1.1 when they were linked using
the 1.1 tools.

Kai Uwe Rommel

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

lsalomo@hubcap.clemson.edu (lsalomo) writes:

> Try using the DosGetProcAddr API to check for the DosQFSAttach API.  If it
> returns NULL, then you are running under 1.1 .

You have provided a method for determining whether the version of OS/2 
is earlier than 1.2, but this won't help in determining which file
system is in use.

In article <1990Nov15.174907.19980@mks.com> dale@mks.com (Dale Gass) writes:
>I require a portable and efficient method of determining whether a given
>drive uses the HPFS file system.
>
>
>What I require, is a portable way (i.e.  works on OS/2 1.1, 1.2) to
>determine whether a drive is a HPFS file system, without using calls
>that are unsupported in version 1.1.
>
something you can do is put the call to DosQFSAttach in a segment that is
marked as "LOADONCALL" in the .def file.  then, you only call your IsHpfs()
call when you have already checked the os/2 version number.  In that way, you
avoid the fault on the load of the program because it won't load and fixup the
code segment with the unsupported API call (for v1.1).  When you do call it,
os/2 will load the segment and perform the fixups then instead of at program
startup time with a "PRELOAD" (the default) segment attribute.

Hope this helps.


-- 
------------------------------------------------------------------------
dan spalding -- microsoft systems/languages -- microsoft!dans
"there has not been a word invented that would convey my indifference to
that remark." - paraphrase from hawkeye pierce

dale@mks.com writes:
| I require a portable and efficient method of determining whether a given
| drive uses the HPFS file system.

dans@microsoft writes:
| something you can do is put the call to DosQFSAttach in a segment that is
| marked as "LOADONCALL" in the .def file.  ...


The default for code and data selectors within an EXE are to
be demand loaded (loadoncall).  They are preloaded when the
application is loaded from remove-able media, or when being run
from accross the network in os/2 versions less then 1.3.   And
since the os will sometimes pre-load the selectors from within
the exe image, you can't really use the "loadoncall" method to
reference the 1.2 (or better) specific function - if for some
reason the selector get's referenced and the function doesn't
exist on the current machine, the program will be crashed by
the os/2 when it fails to get the function address to fixup
the selector.

    a program which uses the "loadoncall" method to reference
    functions not available on the current level of os/2 will
    not work when:
	it's loaded from removable media (floppy drive)
	it's loaded from over the network on os/2 1.0 or 1.1
	or 1.2 when the swap file is on a local hard-disk.
	(1.2 remote booted with a remote swap file would work).
	if a DLL happened to reference the selector

You can use the function DosGetProcAddr to dynamically obtain
the addresses of functions in DLL's, or the OS entry points.
(Note: most of the os/2 functions can only be obtained via
their ordinal numbers.  I believe they are published in an
include file, but for your reference DosQFSAttach is: DOSCALLS.182)

In any event, I wouldn't use QFSAttach for determining the IFS
type.  It doesn't work as you expect accross the network.  It will
return a file-system name of "LAN" if the drive is redirected to
a server.

If you are interested in knowing whether or the file system supports
long files names, you can simply try to create or reference one.
On down-level files systems (or fat) you will get an error when you
try to pass it in a non 8.3 filename.

Another (cheap) method, which was used in a port of LS for
esthetics, looks at the returned FindFirst info. If only the
last-modification date gets returned by the API, the LS program
assumes it was fat and lower cases the filenames before displaying
them; otherwise, it leaves them alone.

    Note: you have to flag the application to be "longnames"
    aware; otherwise, the os will mask out access to non 8.3
    filenames, and will uppercase them before returning them
    to your appliation.  (this is for compatibility with programs
    that do not understand non 8.3 filenames)

                - Ken

In article <1990Nov15.174907.19980@mks.com> dale@mks.com (Dale Gass) writes:
>
> [...]
>
>However, this call is not supported under OS/2 1.1 (and I want the
>program to remain 1.1 compatible).  Since HPFS was non-existent under
>OS/2 1.1, I can easily avoid making this DosQFSAttach call after
>checking the version number and finding it to be less than 1.2.
>However, since the DOS calls are dynamically linked, the mere external
>reference to DosQFAttach in the executable causes the program execution
>to fail at load time.

The solution to your problem is to use DosQFSAttach as a Run-Time API-Call.
First you check your version number of OS/2 then you make calls to 
DosLoadModule (check your system DLL's for DosQFSAttach) and DosGetProcAddr.
After this you can use DosQFSAttach. Be sure to free the Module with
DosFreeModule. For further information about Runtime-DLL's consult your
manuals (RTFM ;-)

   Bye,

-- 
Fealon, a.k.a. Frank Fuchs (Foxware), fealon@nadia.stgt.sub.org