Sorry, I misread the license. I saw "creating portions of products which comply with the Specification" at the end of the paragraph, but didn't notice that the license simply allows you to distribute the "Specification solely for the purposes of creating portions of products which comply with the Specification in unmodified form."
But there's a lot more legalese in there, including a Covenant Not to Sue which may or may not say that Microsoft won't sue you for implementing the spec. Perhaps someone who is more proficient in legalese than I am could take a look and comment?
Here is a document on Microsoft's web server that details the on-disk format of the FAT file system.
The document is dated December 6, 2000. And on page 2, licensing terms are shown:
(a) Provided that you comply with all terms and conditions of this Agreement and subject to the limitations in Sections 1(c) - (f) below, Microsoft grants to you the following non-exclusive, worldwide, royalty-free, non-transferable, non-sublicenseable license under any copyrights owned or licensable by Microsoft without payment of consideration to unaffiliated third parties, to reproduce the Specification solely for the purposes of creating portions of products which comply with the Specification in unmodified form.
So if you don't pay the FAT tax, you're using Microsoft's patents without a license, and therefore are open to be sued. I'm surprised to see Microsoft so openly flaunting the antitrust settlement. This is worse than the Unisys GIF debacle.
As further evidence that the license isn't just for getting the "true" implementation of FAT (from the page linked above):
the license requires that licensees' FAT file system implementations in the licensed media and devices be fully compliant with certain required portions of the Microsoft FAT file system specification. To help licensees implement the FAT file system, Microsoft will also provide certain reference source code and test specifications as part of the licensing package in both licenses.
So it's your own implementation, but you get some of Microsoft's code to help you. As if you'd need it. I didn't have too much trouble implementing a FAT reader/writer in my operating systems class without any Microsoft code.
Incidentally, this isn't the first time Microsoft has made their FAT code available. If you purchase the $1000 Integrated File Systems kit, the FAT code is included as an example.
I usually did my drawing to an offscreen malloc()'ed buffer, and waited for the vertical sync signal on port 0x3DA or wherever it was before REP MOVSD'ing the whole thing to the visible frame buffer.
Not as efficient as page flipping, but good enough for what I did.
Yeah, I didn't think it was too complicated, but ten years ago I couldn't be bothered to figure out what a "plane" was. And these days I'm more interested in OpenGL hacking, for obvious reasons.
The original 16-bit color mode of the EGA cards and VGA cards must have been designed by somebody who was high on crack.
I think you mean 16-color (or 4-bit color), not 16-bit color.:)
The memory is accessed as 4 independent planes, so you have to unnaturally slice every pixel up into individual bits and have a PhD in boolean logic to get them on the screen as you intended. It easily could take a newbie a whole day of reading manuals and hacking before they could get a single white dot on the screen.
True for EGA/VGA 16-color modes, but the 320x200 256-color mode (Mode 13h) was very easy to program for. Just a nice linear array of one byte per pixel. Setting palette entries using OUTs was pretty easy too. I have many fond memories of writing assembly language Mode 13h graphics demos in my high school days...
Heck, the video stores give you a week! And they have a limited supply of physical DVD discs to work with.
With this thing, there's nothing to "return", so there's no reason not to let users have access to it for least a week.
Obviously they won't let you have it on your set-top-box HDD indefinitely, since they want you to buy the overpriced DVD, but 24 hours is too short a time.
I estimate that the DRM will be broken within a week of release, making this whole point academic, however...
All together, these three small code fragments comprised no more than 200 lines out of the more than one million lines of our overall contributions to Linux. Notably, it appears that most or all of the System V code fragments we found had previously been placed in the public domain, meaning it is very doubtful that the SCO Group has any proprietary claim to these code fragments in any case.
Tomorrow's SCO press release will say:
All together, these... code fragments comprised... more than one million lines of... System V code... that the SCO Group has... proprietary claim to.
All together, these three small code fragments comprised no more than 200 lines out of the more than one million lines of our overall contributions to Linux. Notably, it appears that most or all of the System V code fragments we found had previously been placed in the public domain, meaning it is very doubtful that the SCO Group has any proprietary claim to these code fragments in any case.
SCO press release says:
All together, these... code fragments comprised... more than one million lines of... System V code... that the SCO Group has... proprietary claim to.
"SCO's references to XFS are completely misplaced. XFS is an innovative
SGI- created work. It is not a derivative work of System V in any
sense, and SGI has full rights to license it to whomever we choose and
to contribute it to open source. It may be that SCO is taking the
position that merely because XFS is also distributed along with IRIX it
is somehow subject to the System V license. But if so, this is an
absurd position, with no basis either in the license or in common
sense. In fact, our UNIX license clearly provides that SGI retains
ownership and all rights as to all code that was not part of AT&Ts UNIX
System V."
Okay, assume for a moment that it's true that SCO can distribute the whole of Linux because it claims it has a copyright on a part of it.
This means that if there really is copyrighted SCO code in Linux, then IBM, RedHat, et. al. are free to distribute it along with Linux. After all, IBM, RedHat, et. al certainly have their own copyrights in Linux.
I was just looking at Amazing performance yesterday. Specifically, looking for hacks to improve it. Currently it manages between 5-8 frames per second (not too amazing... sigh...but the no texture version gets up to 15).
One idea I have is to rotate the display 90 degrees. That way, when writing a texture column, I can take advantage of the video memory layout and do 16 pixels at once.
The map isn't really slowing things down. It's static--I just draw it at the beginning and let it sit there. The "action area" as you called it is the only thing that gets updated every frame.
TIGCC is based on GCC 3.2 but cross-compiles for TI-89/92+/Voyage 200 calculators. It includes a mostly complete C library, plus a TIOS syscall library and some graphics functions.
I don't think I've used the math features of my TI-89 since my last physics class, but I've been happily hacking away as late as this past week. Some of the stuff I've done is here, including a 3D maze game a la Wolfenstein 3D (but with no shooting, yet).
First, SCO criticizes the industry because no one will offer indemnification. Something along the lines of "they must think our claims have merit because otherwise they would indemnify." (I can't find a link--anyone?)
Now that HP is, SCO says it must be because HP thinks SCO's claims have merit.
But HP doesn't admit that. From the article, "HP is not acknowledging anything related to SCO's actions."
Think about it. If HP really thought SCO had a case, would they be willing to take the fall when no one else will? HP marketroids are just catering to the paranoid/wimpy CIO market.
HP's actions this morning reaffirm the fact that enterprise end users running Linux are exposed to legal risks. Rather than deny the existence of substantial structural problems with Linux as many Open Source leaders have done, HP is acknowledging that issues exist and is attempting to be responsive to its customers' request for relief. HP's actions are driving the Linux industry towards a licensing program. In other words, Linux is not free.
SCOX is already shorted to the hilt. This hasn't stopped the stock from sailing through the stratosphere (last seen in the range of $20/share) despite the company having no fundamentals.
SCOX has a very small float--it's closely held. This means that insiders and friends of SCO can manipulate the price easily.
Stay far far away from SCOX. It's too big a gamble, short or long.
Slashdot Mirror
The patents cover Microsoft's long filename kludge which was introduced with Windows 95. That's why the patent wasn't applied for until then.
Why would Microsoft choose to patent their ugly hack? I can think of no other reason than to erect a toll bridge for devices FAT filesystems.
Fortunately, my digital camera doesn't support long filenames...
Here is a PDF version of the same specification.
Sorry, I misread the license. I saw "creating portions of products which comply with the Specification" at the end of the paragraph, but didn't notice that the license simply allows you to distribute the "Specification solely for the purposes of creating portions of products which comply with the Specification in unmodified form."
But there's a lot more legalese in there, including a Covenant Not to Sue which may or may not say that Microsoft won't sue you for implementing the spec. Perhaps someone who is more proficient in legalese than I am could take a look and comment?
The document is dated December 6, 2000. And on page 2, licensing terms are shown:
Not in so many words, but at the end of Microsoft's "FAT File System Technology and Patent License", it says "The FAT file system licensing program includes rights to a number of U.S. Patents".
So if you don't pay the FAT tax, you're using Microsoft's patents without a license, and therefore are open to be sued. I'm surprised to see Microsoft so openly flaunting the antitrust settlement. This is worse than the Unisys GIF debacle.
As further evidence that the license isn't just for getting the "true" implementation of FAT (from the page linked above):
So it's your own implementation, but you get some of Microsoft's code to help you. As if you'd need it. I didn't have too much trouble implementing a FAT reader/writer in my operating systems class without any Microsoft code.
Incidentally, this isn't the first time Microsoft has made their FAT code available. If you purchase the $1000 Integrated File Systems kit, the FAT code is included as an example.
I think you've got this backward. News of SCO retaining Boies was leaked in January. SCO sued IBM without warning in March.
I usually did my drawing to an offscreen malloc()'ed buffer, and waited for the vertical sync signal on port 0x3DA or wherever it was before REP MOVSD'ing the whole thing to the visible frame buffer. Not as efficient as page flipping, but good enough for what I did.
Yeah, I didn't think it was too complicated, but ten years ago I couldn't be bothered to figure out what a "plane" was. And these days I'm more interested in OpenGL hacking, for obvious reasons.
I think you mean 16-color (or 4-bit color), not 16-bit color. :)
True for EGA/VGA 16-color modes, but the 320x200 256-color mode (Mode 13h) was very easy to program for. Just a nice linear array of one byte per pixel. Setting palette entries using OUTs was pretty easy too. I have many fond memories of writing assembly language Mode 13h graphics demos in my high school days...
I never did get the hang of ModeX, though.
Heck, the video stores give you a week! And they have a limited supply of physical DVD discs to work with. With this thing, there's nothing to "return", so there's no reason not to let users have access to it for least a week. Obviously they won't let you have it on your set-top-box HDD indefinitely, since they want you to buy the overpriced DVD, but 24 hours is too short a time. I estimate that the DRM will be broken within a week of release, making this whole point academic, however...
Tomorrow's SCO press release will say:
SCO press release says:
"SCO's references to XFS are completely misplaced. XFS is an innovative SGI- created work. It is not a derivative work of System V in any sense, and SGI has full rights to license it to whomever we choose and to contribute it to open source. It may be that SCO is taking the position that merely because XFS is also distributed along with IRIX it is somehow subject to the System V license. But if so, this is an absurd position, with no basis either in the license or in common sense. In fact, our UNIX license clearly provides that SGI retains ownership and all rights as to all code that was not part of AT&Ts UNIX System V."
Of course. We all know the 'net is a safe haven free from product placement.
I don't think all of IBM's contributions are for the S/390 mainframes, but I could be wrong.
This means that if there really is copyrighted SCO code in Linux, then IBM, RedHat, et. al. are free to distribute it along with Linux. After all, IBM, RedHat, et. al certainly have their own copyrights in Linux.
Says SCO. Look here for a good refutation of SCO's claims against IBM.
That must be why Boies skipped SCOForum and has silently slipped into the background, leaving Mark Heise as SCO's new chief counsel.
I was just looking at Amazing performance yesterday. Specifically, looking for hacks to improve it. Currently it manages between 5-8 frames per second (not too amazing... sigh...but the no texture version gets up to 15). One idea I have is to rotate the display 90 degrees. That way, when writing a texture column, I can take advantage of the video memory layout and do 16 pixels at once. The map isn't really slowing things down. It's static--I just draw it at the beginning and let it sit there. The "action area" as you called it is the only thing that gets updated every frame.
The TI-89 and 92+ sport a 10MHz 16-bit Motorola MC68000 (in the same class as the Mac Classic, I believe).
Not quite 33MHz, but still fast enough for a rudimentary first-person shooter.
TIGCC.
TIGCC is based on GCC 3.2 but cross-compiles for TI-89/92+/Voyage 200 calculators. It includes a mostly complete C library, plus a TIOS syscall library and some graphics functions.
I don't think I've used the math features of my TI-89 since my last physics class, but I've been happily hacking away as late as this past week. Some of the stuff I've done is here, including a 3D maze game a la Wolfenstein 3D (but with no shooting, yet).
Eh, how often do you find any CDs on the shelves with more than 40 minutes of music anyway?
First, SCO criticizes the industry because no one will offer indemnification. Something along the lines of "they must think our claims have merit because otherwise they would indemnify." (I can't find a link--anyone?)
Now that HP is, SCO says it must be because HP thinks SCO's claims have merit.
But HP doesn't admit that. From the article, "HP is not acknowledging anything related to SCO's actions."
Think about it. If HP really thought SCO had a case, would they be willing to take the fall when no one else will? HP marketroids are just catering to the paranoid/wimpy CIO market.
But read SCO's disgusting spin:
HP's actions this morning reaffirm the fact that enterprise end users running Linux are exposed to legal risks. Rather than deny the existence of substantial structural problems with Linux as many Open Source leaders have done, HP is acknowledging that issues exist and is attempting to be responsive to its customers' request for relief. HP's actions are driving the Linux industry towards a licensing program. In other words, Linux is not free.
I thought HP actually pulled out of SCOForum at the last minute.
SCOX is already shorted to the hilt. This hasn't stopped the stock from sailing through the stratosphere (last seen in the range of $20/share) despite the company having no fundamentals. SCOX has a very small float--it's closely held. This means that insiders and friends of SCO can manipulate the price easily. Stay far far away from SCOX. It's too big a gamble, short or long.