Mail Archives: djgpp-workers/2000/05/30/05:08:26
> 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 <ams AT ludd DOT luth DOT se>.
> > + *
> > + * 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
- Raw text -