Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!nntp.et.byu.edu!news.caldera.com!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.sys.intel
Subject: Re: I have one thing to say about Windows '95 & FreeBSD
Date: 11 Sep 1995 01:08:56 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 76
Message-ID: <430279$218@park.uvsc.edu>
References: <41gceu$i14@mirv.unsw.edu.au> <41m3at$vn7@lucy.swin.edu.au> <MICHAELV.95Sep7213538@MindBender.HeadCandy.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:6037 comp.sys.intel:48287
michaelv@MindBender.HeadCandy.com (Michael L. VanLoon) wrote:
]
] In article <42nqt0$rss@kadath.zeitgeist.net> "Amancio Hasty, Jr." <hasty@rah.star-gate.com> writes:
] 2) Because Win95 may not be upto to the job or is cripple on purpose
]
] Anybody who believes it was crippled on purpose simply has to get a
] dose of reality.
I wasn't going to say anything.
But between Beta 950 and the release, the number of directory
searches required of the IFSMgr by a command line 'del' has
doubled.
I prefer to blame this particualr performance loss on someone doing
a bad job of fixing Novell client support at the wrong layer; the
NetWare server expects a search for directories followed by a search
for files, whereas a correct implementation *could* search for
both and return the attribute bit, then switch on the attribute
bit, instead of calling twice and implying it.
Whoever did this hack ought to have to go back to the NetWare client
FSD and fix it there.
I also noted the removal of the ability to return ERROR_NOT_SUPPORTED
from FS_SearchFile() and have it call FS_FindFile on your behalf.
This is especially annoying because the Microsoft networking code
does not preserver the full 32 bits in the search handle when going
across the wire: the client does not treat the data as opaque.
Both of these make it more difficult (but not impossible) to use
Win95 as a server platform.
However, I think Amancio may have a point with the issue of broken
system tools.
Specifically, the "Properties..." on a hard disk query the underlying
file system using INT calls instead of Win32 calls. This leaves
the C/H/S BIOS limits in place unnecessarily.
In addition, there appears to be a stripping of the file offset
from the Win32 interface at the IFSMgr level, forcing the use of
32 bit rather than 64 bit offsets.
The Unicode manipulations required to make IFSMgr_MetaMatch happy
with its arguments are non-trivial. Though there is not an explicit
note to this effect, the first argument must be upcased. This leads
to multiple redundant calls if you honor the "case sensitive on
storage, case insensitive on lookup" mandates; typically you'd get
around this by writing your own Unicode manipulation routines.
The TSD and ParsedPath intefaces are both rather well thought out,
but are crippled in implementation. The TSD interface, especially,
incorrctly violates the layering design with regard to the issues
of media logical partitioning and media perfection.
Finally, if you wish to export local resources, you are permitted
only one export service type. This is beacuse of the server
registration mechanism not having a clean, common export interface
with which to provide the list of exported resources to more than
a single server type at a time.
Still, it's possible to work around all of these problems and turn
Windows95 into a good server platform: with minor exceptions, as
good as NT; better, if we compare on the basis of price/performance.
Obviously, BSD won't be repeating the mistakes: they'll make their
own. 8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.