Files
2024-02-19 00:25:23 -05:00

74 lines
3.8 KiB
HTML

<html><head>
<title>HPFS: Application Programs and the HPFS</title>
</head>
<body>
<center>
<h1>Application Programs and the HPFS</h1>
</center>
Each of the OS/2 releases thus far have carried with them a major
discontinuity for application programmers who teamed their trade in the
MS-DOS environment. In OS/2 1.0, such programmers were faced for the first
time with virtual memory, multitasking, inter-process communications, and
the protected mode restrictions on addressing and direct control of the
hardware and were challenged to master powerful new concepts such as
threading and dynamic linking. In OS/2 Version 1.1, the stakes were raised
even fufiher. Programmers were offered a powerful hardware-independent
graphical user interface but had to restructure their applications
drastically for an event-driven environment based on objects and message
passing. In OS/2 Version 1.2, it is time for many of the file- oriented
programming habits and assumptions carried forward from the MS-DOS
environment to fall by the wayside. An application that wishes to take
full advantage of the HPFS must allow for long, free-form, mixed-case
filenames and paths with few restrictions on punctuation and must be
sensitive to the presence of EAs and ACLs.
<p>
After all, if EAs are to be of any use, it won't suffice for applications
to update a file by renaming the old file and creating a new one without
also copying the EAs. But the necessary changes for OS/2 Version 1.2 are
not tricky to make. A new API function, DosCopy, helps applications create
backups--it essentially duplicates an existing file together with its EAs.
EAs can also be manipulated explicitly with DosQFileInfo DosSetFileInfo
DosQPathlnfo and DosSetPathInfo. A program should call DosQSysInfo at run
time to find the maximum possible path length for the system and ensure
that all buffers used by DosChDir DosQCurDir and related functions are
sufficiently large. Similarly the buffers used by DosOpen DosMove
DosGetModName, DosFindFirst D DosFindNext and like functions must allow for
longer filenames. Any logic that folds cases in filenames or tests for the
occurrence of only one dot delimiter in a filename must be rethought or
eliminated. The other changes in the API will not affect the average
application. The functions DosQFileInfo DosFindFirst and DosFindNext now
retain all three sets of times and dates (created last accessed last
motified) for a file on an HPFS volume but few programs are concerned with
time and date stamps anyway. DosQFslnfo is used to obtain volume labels or
disk characteristics just as before and the use of DosSetFsInfo for volume
labels is unchanged. There are a few totally new API functions such as
DosFsCtl (analogous to DosDevlOCtl but used for communication between an
application and an FSD) DosFsAttach (a sort of explicit mount call) and
DosQFsAttach (determines which FSD owns a volume) these are intended mainly
for use by disk utility program. In order to prevent old OS/2 applications
and MS-DOS applications running in the DOS box from inadvertently damaging
HPFS files a new flag bit has been defined in the EXE file header that
indicates whether an application is HPFS-aware. If this bit is not set the
application will only be able to search for open or create files on HPFS
volumes that are compatible with the FAT' file system's 8.3 naming conventions.
lf the bit is set OS/2 allows access to all files on an HPFS volume because
it assumes that the program knows how to handle long free-form filenames and
will take the responsibility of conserving a file's EAs and ACLs.
<p>
<hr>
&lt; <a href="faultol.html">[Fault Tolerance]</a> |
<a href="hpfs.html">[HPFS Home]</a> |
<a href="sum.html">[Summary]</a> &gt;
<hr>
<font size=-1>
Html'ed by <a href="http://www.seds.org/~spider/">Hartmut Frommert</a>
</font>
</body></html>