Micro$oft to license FAT

to

The patent examiner should have asked about prior art from ca. 1966-1967, specifically the "Star Trek" communicators.

Reply to
John R. Strohm
Loading thread data ...

Perhaps. I am often amazed that anything more sophisticated than a digital camera still uses FAT at all. It might be in MICROS~1's interest to kill FAT off for good.

--
      Wim Lewis , Seattle, WA, USA. PGP keyID 27F772C1
Reply to
Wim Lewis

That reminds me of a website I found once that claimed that they trademarked the name "Tricorder" long before Startrek ever flew a mission. Seems Captin Kirk is still paying royalties! No joke...

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Well, a quick web trademark search shows 5 tricorder hits, the oldest being 1976.

Reply to
Jim Stewart

If they manage to do that, that'll be a rather serious problem for storage media portability. As of today FAT is the *only* filesystem full accessible out of the box to just about every operating system platform worth bothering with. Microsoft Windows itself is the major limiting factor in that, since for non-optical drives it supports only the FAT family and the rather fiercely guarded NTFS. If they did kill FAT, that might make files stored by MS Windows legally inaccessible to all other systems because of the patents and trade secrets they hold on NTFS.

Dual-booted PCs would no longer be able to access one platform's files when currently running the other.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Ahh, but that was different. Kirk held the communicator up in front of him, not to his ear. The Star Trek communicator didn't have any electronics on the upper part, merely a grill to protect the rest of the communicator.

God, I'm such a nerd.

--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology
Reply to
Alex Pavloff

Didn't you ever get the Starfleet Technical Manual? That was the antenna.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

Damn, I was trying to keep my geekiness in the closet, but...

If you read further, that circuit was altered to conform to 20th century knowledge to prevent temporal disruption. (The 27.125 MHz ch14 operation was also a tip-off.)

--
Ron Sharp.
Reply to
Android Cat

Well still, even if the Captain Kirk commnicator used the grille as the antenna, I don't see how it can be prior art for the Motorola flip phones. The only commonality between the two is the fact that there's a piece of the device attached by a hinge. The placement of components and the use of the devices are completely different.

God, not only am I a nerd, I'm like a lawyer-nerd. The horrors!

--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology
Reply to
Alex Pavloff

I'm not sure if you are at all serious or if you are just playing a part. Certainly it would be no problem to write the patent in a way that would encompass both handheld use and use next to the ear. Likewise if you don't specify the placement of components in the patent, it would then cover all placements. I have seen Motorola phones which had the mic (and whatever else) in the flip part of the phone and I have also seen Motorola phones which had *nothing* in the flip part. The mic was behind a small hole located at the base of the main part of the phone. The flipper only covered the push buttons and allowed you to answer and end calls.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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.

Also, Unix doesn't normally break the long filenames into multiple separate fixed-size directory entries, although I think I do recall reading about some hacks to SVR2 to do that. (SVR2 limited filenames to

14 characters.)
Reply to
Eric Smith

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.

--
Darin Johnson
    Laziness is the father of invention
Reply to
Darin Johnson

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.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

(Unfortunately.)

I beg to differ. When you look at the actual implementation of LFNs on FAT12/16, it's not very difficult. It simply chains extra directory entries together, while using an "illegal" combination of attribute bits to indicate the LFN to an OS that supports it, and causing it to be ignored by an OS that doesn't. Mostly, what was required was to wean users away from DOS, so they wouldn't complain as much about the 8.3 name-mangling that occurs (if you never did a DIR again, but rather just browsed in Explorer, you would never see the mangled file names anyway).

--Gene

Reply to
Gene S. Berkowitz

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

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:

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

formatting link
and type in the number.

--
      Wim Lewis , Seattle, WA, USA. PGP keyID 27F772C1
Reply to
Wim Lewis

rickman wrote: : Darin Johnson wrote: :> :> Eric Smith writes: :> :> > 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.
 Click to see the full signature
Reply to
Geir Frode Raanes

(Unfortunately.)

I don't understand what you are disagreeing about. The level of difficulty is not at issue in any way. The degree of "obviousness" is unrelated. If it had been obvious, Windows 1.0, 2.0 and 3.0 would have also used it or someone else would have added it as an addon package. I seem to recall that there was a large business around the time of Windows 3.0 and 3.1 of adding features or fixing the ones that MS implemented. I specifically remember having to buy serial port drivers for our code because the MS drivers were pretty much useless. So why did no one provide a long filename package at that time?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

(Unfortunately.)

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

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

(Unfortunately.)

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.

Reply to
Jim Stewart

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.