Micro$oft to license FAT - Page 5

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
snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) writes:

Quoted text here. Click to load it

This is somewhat similar to what OS/2 did (which Microsoft helped
design initially).  However, they were able to do that on a straight
DOS compatible FAT file system (optional, since their native
filesystem was preferrable).  They did implement it in a FAT
compatible way, but using a hidden file, rather than tweak FAT in a
way that wasn't forward compatible with Microsoft's version.

--
Darin Johnson
    Where am I?  In the village...  What do you want?  Information...

Re: Micro$oft to license FAT

Quoted text here. Click to load it

I (vaguely) remember that. Users could add arbitrary information to
the "attributes", as I remember. I think the java compiler kept its
output there, too, so sources weren't recompiled unless they changed.

--
Al Balmer
Balmer Consulting
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

Yeah, they lived (on FAT filesystems anyway) in a big file called " EA
DATA. SF" or something similar. Damn thing just got bigger and bigger
and kept filling with crud.

I loved OS/2 2.0 when it ran on bog-standard IBM hardware, using HPFS.

I hated, hated, *hated* it on FAT systems and anything with even vaguely
unusual hardware - at one point the only way to recover from an attempt
to change screen resolution was to reformat the hard disc! (And I think
that was only a Trident 8900C!)

pete
--
snipped-for-privacy@fenelon.com "There's no room for enigmas in built-up areas."

Re: Micro$oft to license FAT

Quoted text here. Click to load it

Extended attributes on FAT were a terrifyingly horrific kludge, though.
They only worked well on HPFS.


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

The patent (at least, the most recent one listed on MS's site,
#6286013) is specifically for Microsoft's particular way of bodging
long file names onto the side of an 8.3-limited file system. If
you're not trying to be Microsoft-compatible, then I'd bet that
these patents don't affect you at all. Actually, a large part of
the patent seems to be trying to cover the API at an assembler
level:

Quoted text here. Click to load it

I wonder if this is intended to give them a lever against things like WINE?
I'm under the impression that you can't patent APIs, but I guess nothing
stops them from trying.

If you want, you can always just go read the patent for yourself ---
the USPTO has them all online, go to
  http://patft.uspto.gov/netahtml/srchnum.htm
and type in the number.


--

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

This is unique, novel and non-obvious to those skilled in the art?
Loading a register before calling a function? A bios call??
Please...

--
Steve Sousa



Re: Micro$oft to license FAT

Quoted text here. Click to load it

Well, just load the EAX register instead of AX and the patent
won't apply :-)

--
Darin Johnson
    Gravity is a harsh mistress -- The Tick

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

Their target audience for license are music and camera manufacturers. How
many of those would you think are using an Intel x86 type processor in their
camera or MP3 player? Haven't seen too many with fans and a 20Ah battery
attached yet ;-)

Rob



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

Yes, but the four patents mentioned specifically relate to LFNs, which
are an extension to FAT. By implication, the "pending" stuff they talk
about is newer than LFNs, so probably of no interest to embedded
developers unless you're making a very computer-like device. In the
enormous majority of cases, the only reason people use FAT in embedded
systems is for data interchangeability with PCs. So a
lowest-common-denominator filesystem is perfectly acceptable for us.

Anyhow, the tone of the document is not one of MS actively seeking to
close down extant third-party FAT implementations, but more like MS
trying to keep future enhancements to the FAT format closed.

(Side note: The XBox uses FAT32, not NTFS - and it's FAT32 with some
extensions for slightly more robustness than regular FAT).

Re: Micro$oft to license FAT

Quoted text here. Click to load it

I take the document that they (MS) are trying to follow the success of
licensing of MP3 -- make the specification available, and years later ask for
fees because there are so many implementations.

[I am not a lawer, opinions are strictly mine :]

  Vadim

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

Maybe. Anyway, it's not a very serious issue - $0.25 won't break me,
but I will fight it if necessary simply out of a desire not to pay
Microsoft anything. FAT12 at least is closely based on CP/M on-disk
format anyway, isn't it?

(I guess since nobody wants Windows CE, MS has to find some other way
to get a revenue stream out of the embedded market).

Re: Micro$oft to license FAT

Quoted text here. Click to load it

Not really.  I'm reaching back 20 years in my memory,
so I may be wrong.  Seems to me that CP/M did the
allocation of clusters/sectors right at the directory
entry, not in a FAT.  This severely limited the file
size you could have and still have a reasonably length
directory.  A later kluge was "extents", where once a
directory entry was full of allocations, it chained to
another one and that was used.



Are you using PTP yet (was Re: Micro$oft to license FAT)
Quoted text here. Click to load it

Picture Transfer Protocol

http://ptp.sourceforge.net/

could become very popular suddenly.

Site Timeline