From: Martin Stromberg Message-Id: <200005300907.LAA14742@lws256.lu.erisoft.se> Subject: Re: LONG: fat32 diff in cvs To: djgpp-workers AT delorie DOT com Date: Tue, 30 May 2000 11:07:47 +0200 (MET DST) In-Reply-To: from "Eli Zaretskii" at May 30, 2000 10:57:11 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > 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. I don't know. Anyone? > 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). Sounds like a good idea. I say we change the name to llseek. > 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? Yes. (I wonder where that went?) > > 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. Ok. > Also, I understand that extended size doesn't work on Windows 98, but > you pass it down nonetheless, right? Yes, I'm doing a best effort; too bad WINDOZE don't want to do as told. > > + @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.) Hmmm. Strange. I surely built it like that. Perhaps the build process doesn't stop on errors? Or perhaps it just @ignored away some functions until a correct @end ignore showed up? I admit I didn't look at all of the generated texinfo files. > 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. Ok. > > + 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. Ok. > > + int _get_fs_type( const int drive > > + , char *const result_str > > + ); > > + @end example > > Why this strange format? It's very good patch-wise. Suppose you need to add a parameter, then you just have to add a line and not change a line and add a line. > > + 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. Ok. > > + 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. Ok. > > + 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. Ok. Where should this short discussion be put? Regarding detecting FAT32, I don't follow you. For FAT32 you should use _is_fat32(). > > + 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. Ok. > > + @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. Ok. > 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). Ooops! I've only used one space everywhere while writing the texinfo files. Where are such _crucial_ things documented? Right, MartinS