Hi Antony, (please switch from HTML to plain text mail...) > I would think that the information contained in the MS-DOS 6 > Programmers reference is free of any restrictions related to > that lawsuit.
(I assume you mean the one which forced MS to go DOS 6.2 to 6.22 and replace a bad license compressor with a barely ok clone...) Unfortunately, no. Things can be well documented and can still be copyrighted. For example Microsoft may have bought licenses to have the permission to implement some well known but clever and copyrighted algorithm for compressed filesystems in their DOS 6.xx ...? You maybe remember all those hassles about when Microsoft tried to get paid by everybody who uses "FAT" systems. It turned out that several patents had expired and some ideas were too trivial to be patented. But some patents remained. Those are not so much about FAT (if at all, then mostly about FAT32 extensions) but more about efficient handling of long file names. Luckily some old document from Microsoft explicitly allows other general operating systems to support all aspects of FAT, but for example makers of embedded devices like mp3 players do have to pay license fees to Microsoft... Actually I own some mp3 player which only shows id3 tags and ignores long file names ... because the makers did not want to pay Microsoft tax? This is not linked to the question who and how actually programmed this. I think even a general operating system could expect complaints if they just use the Microsoft patented optimizations for their long file name support. But as said, supporting long file names at all is okay, as long as it is for a general operating system. Please also see my footnote / PS about this whole licensing stuff! > An initial clean room design would allow us to imitate the core > functionality of DoubleSpace. This would allow us to read the > compressed volume files, if for no other purpose than compatibility. I doubt that such compressed volume files 1. still exist, 2. do exist at a place where MS DOS no longer exists and 3. anybody wants to keep them instead of just copying all files to an uncompressed disk and then throw away MS DOS. > The next step would be to improve the design where it is lacking. Dunno. MS DOS is ancient. And there are several working, free and open source modern compressed file systems out there. You should assume that those have better design than Doublespace anyway :-). > As far as writing to the file system, DoubleSpace allocates the BitFAT, > MDFAT and FAT to maximum capacity. The resulting CVF file is maxxed for > the drive in question, even though in most cases, the CVF will not be > large enough to require the maximum capacity of these structures. This > preallocation allows for growing and shrinking the CVF file very quickly. Sorry, but I do not understand your summary. I assume you mean that all tables are big enough to describe the state when all clusters are used, but are not bigger than that? Then that would be a pretty normal size for the tables :-). > The other alternative might involve some sort of GZIP done on each file, > so there is an 'invisible' decompression each time a file is accessed, > and a decompression when the file is moved from a volume designated > 'compressed' to a volume designated 'not compressed'. Actually TSRs like DIET have done that in the past. There is not much magic about that. You can flag a file as being compressed by using otherwise unused bits in the directory entry (attribs, second field of the timestamp, etc) or by letting the contents start with a header. Problem is that as soon as you switch off the driver, you can still access everything, but of course you now get compressed files instead of the invisibly decompressed files you would expect. As long as you write-protect the compressed files, that problem is sort of acceptable. The TSR driver could then grant write access by virtue of knowing that the compressed file was only write-protected because it is compressed and should not be written to without the driver loaded :-). Note that you often do not want to compress ALL files because many modern file formats already ARE compressed, so you cannot get those files much smaller anyway, and compression attempts just add overhead. > I don't see how writing to the CVF would be a problem, since all > the 'disk' writes would go through the BLOCK device driver, and > since the driver is in effect a 'TSR' of sorts, it can take over > Int 13h, portions of Int 21h, Int 25h, and Int 26h (which comprise > most of how DOS applications access the disk). Uhhhm... We are not going to write a stealth virus here. We only talk about a compressed filesystem driver. As long as DOS and your DOS apps behave, you ONLY need a block device driver for that. No hooks to any interrupt. Neither 13 (BIOS) nor 25/26 (DOS raw sector access) nor 21 (DOS file access). You can also have a compressed filesystem which is not like anything with FAT at all. The interface for such filesystems already exists in every DOS kernel, and it is used for MSCDEX / SHSUCDX (CDROM/DVD) and for network filesystems and similar things :-). This interface is a bit more work to support, because your driver has to understand the filesystem fully: The driver gives the kernel access to files and directories. For comparison, if you have a BLOCK device, then your driver only has to know how to read/write sectors. In case of the compressed filesystem, it also has to know where to find and how to decompress sectors, which typically needs extra tables unless you compress the whole filesystem as one chunk. For example the SHSURDRV ramdisk can load a gzipped raw diskimage. Pro: Gzip does not have to know that this is a diskimage at all. Contra: You have to decompress the whole diskimage to get to the last sector. The SHSURDRV also keeps the entire decompressed image in RAM, so you only save disk space but not RAM space. Yet you save MORE disk space than you could ever save by compressing each cluster of the diskimage separately with a smart tool which knows what clusters and FAT and so on are and mean :-). So SHSURDRV can be quite nice. Eric PS: Please note that I only try to summarize what I do remember about the "MS FAT / VFAT / FAT32 patents and licenses" web news many months ago. This is in no way an official / legal overview. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
