Path: utzoo!attcan!uunet!snorkelwacker!ai-lab!august-east!rpk
From: rpk@august-east.ai.mit.edu (Robert Krajewski)
Newsgroups: comp.windows.ms
Subject: Re: HPFS for Windows (was Re: Sound under Windows...)
Keywords: file systems, standard dialogs
Message-ID: <11087@life.ai.mit.edu>
Date: 29 Sep 90 19:17:19 GMT
References: <3399@gmdzi.gmd.de> <26382@cs.yale.edu> <3407@gmdzi.gmd.de>
Sender: news@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory
Lines: 30

In article <3407@gmdzi.gmd.de> strobl@gmdzi.gmd.de (Wolfgang Strobl) writes:
>...Sure, but this is true for programs written for OS/2 version 1.0 and
>1.1, too. If memory serves me right, one has to mark a program as
>HPFS aware in order to get access to files with names which don't fit into
>the 8.3 scheme. If you don't mark it, a program can make the very same
>assumptions it can make under DOS. 

One can look at HPFS compatibility for DOS and Windows programs, in
its least elaborate implication, as allowing those programs to get to
files which has DOS-compatible names.  Such programs always use DOS
for file system operations.  This kind of compatibility is pretty much
the same as compatibility with network file systems; there are
some programs whose older incarnations (like XTree) were *not* network
file system compatible.

What Microsoft really ought to do is come up with standard, extensible
file dialog boxes in Windows and OS/2 APIs, just the like Mac
Toolbox's SFGetFile and SFPutFile.  The interface could also be
specified in such a manner that file name lengths were irrelevant.
Also, having standard file dialog boxes would keep people from
reinventing the wheel, and allow third-parties to enhance these
standard file dialogs globally (much like INITs like Boomerang and
SFVolInit do for a surpisingly large set of file dialogs in Macintosh
applications).



----
Robert P. Krajewski
Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com