spolsky-joel@cs.yale.edu (Joel Spolsky) (09/25/90)
In article <BwRyP1w162w@zooid.UUCP> dve@zooid.UUCP (David Mason) writes: >... That and the STUPID #(*$&# 8-character filenames... InfoWeek I think said Microsoft was considering HPFS for a future version of Windows, now that they are basically dumping OS/2. This would be amazingly cool! Break every existing application, though... Joel Spolsky spolsky@cs.yale.edu Silence = Death
strobl@gmdzi.gmd.de (Wolfgang Strobl) (09/27/90)
spolsky-joel@cs.yale.edu (Joel Spolsky) writes: >In article <BwRyP1w162w@zooid.UUCP> dve@zooid.UUCP (David Mason) writes: >>... That and the STUPID #(*$&# 8-character filenames... >InfoWeek I think said Microsoft was considering HPFS for a future >version of Windows, now that they are basically dumping OS/2. This >would be amazingly cool! Break every existing application, though... Why should this break existing applications? HPFS doesn't break existing applications under OS/2, so why should it do that under a new version of DOS (or Windows or whatever)? Wolfgang Strobl #include <std.disclaimer.hpp>
dve@zooid.UUCP (David Mason) (09/27/90)
spolsky-joel@cs.yale.edu (Joel Spolsky) writes: > In article <BwRyP1w162w@zooid.UUCP> dve@zooid.UUCP (David Mason) writes: > >... That and the STUPID #(*$&# 8-character filenames... > > InfoWeek I think said Microsoft was considering HPFS for a future > version of Windows, now that they are basically dumping OS/2. This > would be amazingly cool! Break every existing application, though... I heard this too, but only if IBM and Microsoft break off the currently semi-cosy arrangements they have now. If they build in a HPFS, I'd happily go through whatever hell was required to use it. Would have to wait for updates for ALL programs, couldn't use old reliable programs that aren't updated, etc. But it would be WORTH IT!
spolsky-joel@cs.yale.edu (Joel Spolsky) (09/28/90)
strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >spolsky-joel@cs.yale.edu (Joel Spolsky (thats me)) writes: >>InfoWeek I think said Microsoft was considering HPFS for a future >>version of Windows, now that they are basically dumping OS/2. This >>would be amazingly cool! Break every existing application, though... > >Why should this break existing applications? Because just about every DOS application I know of makes assumptions about the maximum length of file names. Joel Spolsky spolsky@cs.yale.edu Silence = Death
pajerek@usenet@kadsma (Don Pajerek) (09/28/90)
>>spolsky-joel@cs.yale.edu (Joel Spolsky (thats me)) writes: >>>InfoWeek I think said Microsoft was considering HPFS for a future >>>version of Windows, now that they are basically dumping OS/2. This >>>would be amazingly cool! Break every existing application, though... I don't see Info Week. Exactly what is happening that causes you to say that Microsoft is 'dumping' OS/2? No surprise here, exactly, but I'd like the details... Don Pajerek
strobl@gmdzi.gmd.de (Wolfgang Strobl) (09/28/90)
spolsky-joel@cs.yale.edu (Joel Spolsky) writes: >strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >>spolsky-joel@cs.yale.edu (Joel Spolsky (thats me[no that's he!])) writes: >>>InfoWeek I think said Microsoft was considering HPFS for a future >>>version of Windows, now that they are basically dumping OS/2. This >>>would be amazingly cool! Break every existing application, though... >>Why should this break existing applications? >Because just about every DOS application I know of makes assumptions >about the maximum length of file names. 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. I wouldn't call this "break every existing application". Wolfgang Strobl #include <std.disclaimer.hpp>
tom@mims-iris.waterloo.edu (Tom Haapanen) (09/29/90)
Joel Spolsky <spolsky-joel@cs.yale.edu> writes: >>> InfoWeek I think said Microsoft was considering HPFS for a future >>> version of Windows, now that they are basically dumping OS/2. This >>> would be amazingly cool! Break every existing application, though... >>Why should this break existing applications? > Because just about every DOS application I know of makes assumptions > about the maximum length of file names. The solution is exactly the same as for OS/2 1.2: mark applications with a flag that says "I know about long filenames". If the flag is off, the application can only access files with 8+3 character filenames. [ \tom haapanen --- university of waterloo --- tom@mims-iris.waterloo.edu ] [ "i don't even know what street canada is on" -- al capone ]
rpk@august-east.ai.mit.edu (Robert Krajewski) (09/30/90)
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
marshall@wind55.seri.gov (Marshall L. Buhl) (10/02/90)
tom@mims-iris.waterloo.edu (Tom Haapanen) writes: >The solution is exactly the same as for OS/2 1.2: mark applications with >a flag that says "I know about long filenames". If the flag is off, the >application can only access files with 8+3 character filenames. What happens when you create a bunch of files with long names and then want to use them with old applications? Do you have to rename them first? It seems to me that HPFS would have limited utility until the vast majority of your software supported it. -- Marshall L. Buhl, Jr. EMAIL: marshall@seri.gov Senior Computer Missionary VOICE: (303)231-1014 Wind Research Branch 1617 Cole Blvd., Golden, CO 80401-3393 Solar Energy Research Institute Solar - safe energy for a healthy future
bobt@microsoft.UUCP (Bob TANIGUCHI) (10/04/90)
Let's clear this up again, programs can be installed on, and run from HPFS with no modifications needed. Enabling long file names requires toggling a bit in the EXE header. Thus, my hard disk is all HPFS, and happily runs dos programs (including windows) in my dos box. Bob Taniguchi Systems Marketing Microsoft Yes, I now do Windows.