Micro$oft to license FAT - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Micro$oft to license FAT
Quoted text here. Click to load it

The functionality of long filenames is not at issue.  A patent covers
the "how" of doing it.  If you can do it a different way, then you are
free to use that method.  But the method that MS chose was not obvious
and not trivial.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT


Quoted text here. Click to load it

Strangely enough, The success of the Philips screw (particularly in the
automibile industry in the 1930's) was due to it being such a "bad"
design - you could not over torque the screw because the screw driver
would slip out of the hole. (read "One Good Turn - the history of the
screwdriver").

Apologies if a little off topic.

Denis

Re: Micro$oft to license FAT
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

We had 8.3 filenames in CP/M in the '70s.  Also about 14 char
filenames in UCSD and early Unix.  We had a 10 significant char.
identifier limit in early Pascal, although the source could use
any length.  Don't know about early C.  MPE 3000 had an 8.8.8
filenameing scheme.

Virtually all of these were eventually expanded to longer names.
AFAICT only Microsoft imposed the execrance of allowing
significant blanks in identifiers, and confusing the truncation
schemes.  Most simply truncated overlong names, and some announced
errors on conflicts.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT
:>
:>
:> > Sure.  But Unix doesn't automatically associate two filenames with any
:> > file whose base name is longer than eight characters or whose extension
:> > is longer than three characters.  Microsoft invented that.  (Unfortunately.)
:> > The filesystem does it behind your back.
:>
:> The effect of having two names associated with the same file doesn't
:> sound like something that could be patented; however a _technique_ of
:> doing that might be patentable.
:>
:> That gets into the ugly issue of whether software should be
:> patentable.  I find it a bit of a stretch to think that this technique
:> is not obvious to a person having ordinary skill in the art (ie, is it
:> 'novel'), but apparently what really matters is who has the most
:> lawyers.
:
: Many things are obvious after they are in common use.  But it took 15
: years or more from the time we started working on PCs with 8.3 character
: names to get around to having long filenames.  Clearly it was not all
: that trivial.  

That's the beauty of it. 'Anyone' could potentially fix FAT.
But that would be to no avail since MS-DOS would remain broken.
Hence the only person or entity that truly could fix FAT was and
still is M$, by first and foremost fix MS-DOS. But even M$ met a
catch-22 as MS-DOS applications does not honor MS-DOS file-IO.
Thus, the M$ LFN fix is a cludge or workaround rather than a fix.
And now it appares that even workaronds are patentable in the US.


--
  ******************************************************
  Never ever underestimate the power of human stupidity.
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT
Quoted text here. Click to load it
(Unfortunately.)
Quoted text here. Click to load it

I don't want to beat a dead horse, but I don't think that is correct.
Anyone could have come up with a unique file system and added it to DOS
after the fact.  IIRC, a small company called Stacker did just that with
compressed files.  MS tried to duplicate their technology, infringed
their patents and had to buy the company.  

Of course the problem is programs that don't use the DOS disk interface
routines.  They would fail with any kind of add on.  But then they would
also fail with DOS changes (and do).  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT
Quoted text here. Click to load it
(Unfortunately.)
Quoted text here. Click to load it

Somewhere around 3.1 or 3.2, DOS did start supporting installable
file systems, such as the CD-ROM and Netware servers.  Before that,
it would have been a bloody pain to do anything other than a FAT
file system.  I'm not saying it would be impossible, just very
hard.







Re: Micro$oft to license FAT
Quoted text here. Click to load it
(Unfortunately.)
Quoted text here. Click to load it

So what is your point?  Anyone could have added long filenames starting
with DOS 3.1 then.  I seem to recall that there was about 5 or 6 years
between DOS 3.1 and Windows 95.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT

Quoted text here. Click to load it

What about Rock Ridge extensions to ISO9660 CD-ROM formats?  That
preceded Windows 95 as I recall.  OS/2 could also have long file names
on top of FAT file systems.  The "technique" that Microsoft used was
essentially a way to graft a long file name onto a filesystem that
didn't support it without breaking the legacy systems.

--
Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick

Re: Micro$oft to license FAT
Quoted text here. Click to load it

So what is your point?  As you indicate, what MS did was different from
what was done in these other systems and was both new and novel (not
obvious).  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT

Quoted text here. Click to load it

But other people had already invented the concept of mapping long and
short file names to each other in a backwards compatible way.  All
Microsoft did was choose a different method of doing that.  If you
asked a class of students to implement a method whereby the FAT
filesystem can support long filenames without breaking legacy
operating systems then you'd get several solutions, some of which
could resemble what Microsoft did.

If once you state the problem the solutions present themselves
immediately, then the solutions wouldn't qualify as nonobvious
to a practitioner of the art.  In this instance the problem statement
was known and at least two solutions existed (OS/2 and Rockridge).

Further, I think that Microsoft's solution could only have been
created by Microsoft anyway, even if someone else thought of it first.
If anyone other than Microsoft used that exact method those changes
could easily have broken with the next release of Windows or DOS (ie,
suddenly the reserved bits are used for something).

--
Darin Johnson
    "You used to be big."
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT
Quoted text here. Click to load it

I don't think your test of obviousness is anything like what the patent
office uses.  This is not a term from the dictionary.  This is patent
jargon and has a specific meaning just like code means something
specific to us which is different from what it means to the average
person.  

Your test of a classroom reinventing the MS lfn approach is not useful.
The bottom line is that the method was not in use for serveral years
showing that it was not obvious.  MS invented it and patented it.  Why
does so many have a problem with this?  This is what patents are all
about.  They allow companies and individuals to profit from their
inventions without someone stealing them.  I know of several examples of
small companies or even individuals who were able to defend their
patents and reap their just rewards.  If there are lots of alternatives
to the MS lfn approach, then use them.  I don't see why this is even
being discussed.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT

Quoted text here. Click to load it

Perhaps a lot of people feel that such a thing shouldn't be
patentable.  Many also feel that software patents shouldn't
exist.  Quite a lot of people actually feel that the entire
system is broken and open to abuse.  Microsoft is merely
taking advantage of this.

--
Darin Johnson
    "You used to be big."
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT

Quoted text here. Click to load it

The problem is that the MS solution is the only one that MS is unlikely to
break in future releases. The alternatives exist and can be used, but if you
want long-term portability across MS OSes, you're forced to use the MS
solution [regradless of its merits].

Re: Micro$oft to license FAT
Quoted text here. Click to load it

This is all fairly academic, but to extend the 8.3 filename system
I see only three basic places to keep the extra information: a) in
an auxiliary file b) in directory entries and c) in the file
itself.

The 4dos description system is an example of a), and many others
can be found.  c) is inherently not compatible.  b) using
previously illegal entries is MsDos's way, and a previous example
can be found in the change from CP/M 2.2 to CP/M 3.0 (or to my
DOSPLUS 2.5) somewhere around 1983 to 1987.  In fact the addition
of CP/M user numbers is an even earlier example, and came
somewhere around 1978.

The above may or may not be examples of prior art and invalidate
any MS patents.  Since IANAL and especially I am not a patent
court, that judgement must be left to others.  My personal opinion
is that it does invalidate, inasmuch as I cannot conceive that
using a previously known technique for a more restricted purpose
is patentable.  The restricted purpose itself is antedated by at
least the 4dos description system.  That leaves the usual
Microsoft "innovations" area as its usual nullity.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Micro$oft to license FAT
Quoted text here. Click to load it

There's a fourth method, which lies somewhere inside the triangle
formed by a, b, and c: Multi-stream files, a la MacOS "data fork" and
"resource fork". (NTFS has something like this now, I don't know
exactly what MS calls it). The LFN, if put in a separate stream, is
still part of the file (since it's inseparably associated with that
one file), but is pointed to by some extension to the directory entry.

Re: Micro$oft to license FAT


Quoted text here. Click to load it

Because of the Mac duality, Macs are somewhat doofuses on non-Mac networks.
Neat idea, but in practice, it is so incompatible with the world as to
further isolate them.

When Macs decide to get fussy, they can be every bit as fun as Windows
to set straight, and a major cause of Mac network problems is the resource
fork getting lost or misplaced.


Re: Micro$oft to license FAT
Quoted text here. Click to load it

   It's an interesting fact that NTFS (Windows NT File
System) makes allowance for a arbitrary number of 'meta-files'
attached to each file.  The 'Data fork' isn't special except
in that it contains the data, and in that nobody has
implemented any other forks, AFAIK.

        Regards.        Mel.

Re: Micro$oft to license FAT

Quoted text here. Click to load it
networks.
resource

It's not quite true that "nobody has implemented any other forks".  There
are a couple of applications that make use of multiple data streams in ntfs
files, but they are rare, since they won't work on FAT.  Also, windows comes
with a grand total of zero tools that are data stream aware, so it can lead
to no end of confusion and problems.  In fact, the only successful
multi-stream program I know of is ... wait for it... a virus.  It hides
copies of itself in alternate streams of exe files, where it is almost
impossible to find - the only change visible to the real exe file is a small
hook at startup.  Fortunately, it did not spread too well, and, being unable
to attack most windows machines (running on FAT/FAT32), it was not common.




Re: Micro$oft to license FAT
Quoted text here. Click to load it

Actually, it works really well in conjunction with NT's multi-stream
feature :) I administer our work LAN, I was *most* surprised to see
that when I did a straight drag-n-drop backup of one of the Mac drives
[on the NT box itself], all the resource forks were kept and stayed
with the correct files. I was expecting to get the data fork only.

Furthermore, it warned me when I tried to copy one of those files to a
FAT volume that the resource fork info would all be lost (I forget the
exact warning).

Re: Micro$oft to license FAT
Quoted text here. Click to load it

True, but in a way that can be viewed as c.  Back circa 1974,
MPE3000 (the OS for the HP3000) provided a file structure with a
system and a user reserved special data block, and provisions for
creating files with multiple user reserved special data blocks.
There was no restriction AFAICR as to what went into these blocks,
but access to them could be restricted.  I believe this structure
was used to implement fairly secure data base systems later.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline