Mail Archives: djgpp-workers/2000/05/30/03:57:41
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 <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.)
> + #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).
- Raw text -