Date: Tue, 30 May 2000 10:57:11 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: DJGPP-WORKERS Subject: Re: LONG: fat32 diff in cvs In-Reply-To: <200005291840.UAA21789@father.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 29 May 2000, Martin Str|mberg wrote: > I've some places where I've used "#if 0 ... #endif" for > easy enabling of debugging print-outs. Should I delete those? I don't think there's a need to delete them if you think they might be useful in the future. > + #define __DJ_offset_t typedef long long offset_t; Is there any other type, besides offset_t, that is used by other platforms which support 64-bit file positions? If so, perhaps we should support the names used by others, at least as an alias. Also, at least Solaris calls the function `llseek', without the leading underscore. perhaps we should have that as well, either as an alias, or simply change the name (assuming that no standard function needs to call llseek internally). One of your earlier versions included an FSEXT hook for _llseek, while this version does not. Isn't it a good idea to have such a hook? > if(use_lfn) { > r.x.ax = 0x716c; > ! r.x.bx = 0x1002; /* Open r/w with extended size. */ > r.x.dx = 0x0012; /* Create, truncate if exists */ > r.x.si = __tb_offset; > + } else if(7 <= (_get_dos_version(1) >> 8)) { > + r.x.ax = 0x6c00; > + r.x.bx = 0x1002; /* Open r/w with FAT32 extended size. */ > + /* FAT32 extended size flag doesn't help on WINDOZE 4.1 (98). */ > + r.x.dx = 0x0012; /* Create, truncate if exists */ > + r.x.si = __tb_offset; I think the comment about Windows 98 above should be made more clear. It doesn't make sense to have the explanation of the problem in the .txh file, but not in the source. Also, I understand that extended size doesn't work on Windows 98, but you pass it down nonetheless, right? > + @ignore > + * File _llseek.txh. > + * > + * Copyright (C) 1999 Martin Strerg . > + * > + * This software may be used freely so long as this copyright notice is > + * left intact. There is no warranty on this software. > + * > + @ignore end The last line should say "@end ignore". (Did you build the library with these changes? If not, I think you should: it prevents you from breaking the library build due to some minor syntax problems, such as this one.) > + #if 0 > + int main(int argc, char *argv[]) > + { > + int ret; > + > + if( argc == 2 > + && 'A' <= argv[1][0] > + && argv[1][0] <= 'Z' ) > + { > + > + ret = _get_fat_size(argv[1][0] - 'A' + 1); > + fprintf(stderr, "_get_fat_size returned %d.\n", ret); > + > + return(0); > + } > + else > + { > + fprintf(stderr, "%s: run like this '%s C'.\n", argv[0], argv[0]); > + > + return(1); > + } > + > + } > + #endif Please make a test program from this and add it to the proper directory under `tests/' (including the changes to makefile there), so it gets added to djtstNNN.zip. > + This function will not succeed on DOS version < 4, setting > + @code{errno} to @code{ENOSYS}. It is also known to have trouble > + detecting the file system type of disks formatted with a later version > + of DOS than on the version it is run on. E. g. floppies with LFN ^^ This "on" should be removed. > + int _get_fs_type( const int drive > + , char *const result_str > + ); > + @end example Why this strange format? > + If successful the result is put in @var{result_str} which must be at > + least 9 characters long. If unsuccessful errno is set. "errno" should have the @code markup, since it's a C identifier. > + of DOS than on the version it is run on. E. g. floppies with LFN ^^ Another "on" that should be removed. > + This function checks if drive number @var{drive} (1 == A:, 2 == B:, > + etc.) is a CD-ROM drive. Works with MSCDEX 2.x, but what about other > + CD-ROM device drivers? You can add that it also works with Windows 9X built-in CDFS support. > + int _is_fat32( const int drive ); > + @end example > + > + @subheading Description > + > + This function checks if drive number @var{drive} (1 == A:, 2 == B:, > + etc.) is formatted with FAT32. > + > + For performance reasons the result is cached, hence if a drive is > + reformatted either from or to FAT32 a DJGPP program must be restarted. I don't know if it's important, but perhaps it's a good idea to add a function that will force _is_fat32 to reinitialize itself, to avoid restarting the whole program. Btw, it looks like there's a whole slew of functions that can be used to find out the filesystem properties, in particular whether it is or isn't FAT32. How about adding cross-references between them, and some short discussion of their relative merits? Some user might become really confused when faced with a decision which function(s) to use. > + int _is_ram_drive( const int drive ); > + @end example > + > + @subheading Description > + > + This function checks if drive number @var{drive} (1 == A:, 2 == B:, > + etc.) is a RAM disk. It is done by checking if the number of FAT > + copies (in the Device Parameter Block) is 1, which is typical of > + RAM disks. This doesn't @emph{have} to be so, but if it's good > + enough for Andrew Schulman et al (@cite{Undocumented DOS, 2nd > + edition}), we can use this as well. I think this logic should be put in the source (in a comment) as well, so that the code explains itself. > + @code{_media_type} should only be called after you are sure the drive > + isn't a CD-ROM or a RAM disk, since these might fool you with this > + call. This looks like a good place to add cross-references to _is_ram_drive and _is_cdrom_drive. Also, please make sure there are 2 spaces after a period that ends a sentence. This is very important when you generate printed docs with TeX (TeX's typesetting algorithms depend on that).