Hi, I reduced the 500 line mail to 140 lines now... enjoy. Eric.
lfn_inode: l_diroff offset could be an UWORD slot number, smaller dmatch dm_size is LONG but should be ULONG and dm_flags is not currently used. Note that the offsets in the structure are fixed, so dm_flags is to be replaced by a reserved field. It should be documented in comments that dmatch is "findfirst/findnext data structure". Of f_node f_flags, F_DMOD, F_DDIR and F_DDATE are used, so at other places, f_dmod should be replaced by F_DMOD in appropriate manner ("other places" is probably only the lfn hooking API?). Can f_node f_count be turned into UBYTE? It is incremented in get_f_node and set to 1 or 0 or decremented at various other places. You can turn f_mode and f_flags into UBYTE. With a little more work, they can even be merged (flags: 3 bits used, mode: values 0..3 used). That and "UBYTE f_count" saves 3-4 bytes (of 54/60 for FAT16/32 kernel) per f_node in RAM. Note that the non-f_node file open mode does use almost all 16 bits! Maybe one can use the SFT open mode to replace f_mode completely? Or would that impact performance too much? The "relative cluster number within file", f_node f_cluster_offset, can at most have 23 bits used (for 4 GB files). By the way, normal cluster numbers are at most 28 bits, rounded up to 32 bits. That would allow an obscure reduction of f_node size for FAT32 kernel by 1-2 extra bytes, but is probably slow and bug-prone. There is FreeDOS specific O_LEGACY, but O_LARGEFILE does not seem to be supported yet (that flag removes the 2 GB size limit from seek and write operations). Other FreeDOS specific file open flags are O_OPEN, O_CREAT and O_TRUNC. Maybe one could condense those a bit if free bits are needed for something else instead. The dos_open O_EXECCASE flag (mode 3 after O_ACCMODE bitmask) would cause "case preservation for exec / redirector", seems to be TODO. Similar for "flags & 7 == 4", which is a variant of readonly open mode, but avoids modifying the file access time. The O_SYNC (commit all writes at once) and O_NOCRIT (do not use int 23 (really? or int 24?)) seem to be TODO, too. Should be quite "doable". In sft, sft_size and sft_posit should be ULONG, not LONG. In addition, SftSeek/remote_lseek/dos_lseek should honor O_LARGEFILE. Notice that this means dos_lseek return type change and foffset argument type change. Because DE_INVLDFUNC and DE_INVLDHNDL can be returned, you must either limit file size to 4 GB - 256 bytes or pass separate return values for errors and offsets. The xstructs.h file should not be #included in non-FAT32 kernels. The DWORD fields there should be ULONG/CLUSTER, but take care to fix "< 0" or "== -1" type comparisons (your compiler should warn...). Having no xstructs.h helps to keep FAT16 kernels "FAT32 free". DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of a NULL navc pointer. I wonder if it is really desirable that the current implementation fakes bigger cluster sizes to allow cluster counts below 64k (DosGetFree is an interface for FAT16 originally). Maybe saturation would be better. How do other DOSes handle this? Note that *nc and *navc already are clipped ntotal and nfree values. For drives beyond lastdrive, get_cds result protects from crashes, but in between, access to unformatted disks returns nonsense for int 21.36 and even crashes while trying to do critical error dialog for int 21.1c - probably some 0:xx data or stack got overwritten. Related functions: media_check, rqblockio, flush_buffers, bpb_to_dpb, dskxfer. Maybe the DF_NOACCESS should be modified to avoid critical error dialog and return "unknown media type" dirrectly. See also: getbpb function, RWzero "wrapper" for LBA_Transfer. rqblockio also contains an ASPI/USB kludge for C_BLDBPB. This should need no typecast: dmp->dm_size = (LONG) SearchDir.dir_size; ... The DosLockUnlock function and remote_lock_unlock and share_lock_unlock should use ULONG, not LONG, for pos and len. You have to do something about "s->sft_shroff < 0" then I think. The following 2 comments are wrong: /* dos_getfsize for the file time */ /* dos_setfsize for the file time */ The dos_setfsize should use ULONG for size, as does dos_getfsize. The lfn_setup_inode should use CLUSTER for dirstart, as dir_init_fnode. (And the int 21.7403 handler should typecast to CLUSTER, not ULONG). DynAlloc does not really need that typecast to ULONG to compare. Should other places apart from DosRWSft update current_filepos, too? For better list-of-list compatibility. The "Globally referenced variables" should have a comment telling that they "are" List of Lists from some offset on. LBA_Get_Drive_Parameters should NOT disable LBA access if heads or sectors are > 64k or if totalSectHigh is nonzero. Instead, only a warning should be shown and totalSect* should be clipped. Using CHS is definitely worse for huge drives than LBA. Note that geometry taken from LBA BIOS is not used anyway, only the size information is used. For CHS, the CHS BIOS geometry is used. At several places, "ULONG / value" and "ULONG % value" could be explicitly marked as "ULONG / UWORD" and "ULONG % UWORD" type, to allow compiler optimizations (32:32->32 bits is more complex on 8086 than 32:16->32 bits). After a long search, I found that the kernel itself never divides things by more than 65535. If your compiler allows custom "32bit division" code to be used, you can also special-case division (and modulo) by 512, because this often happens (without being "hardcodeable": ultimately we want to remove all fixed SEC_SIZE values) and - on a real 808x - a division can be quite slow. We have LDIVMODU and LMULU: dx:ax = dx:ax / cx:bx, cx:bx = dx:ax % cx:bx, dx:ax = dx:ax * cx:bx LBA_Transfer should call the appropriate int 2f.xx function before calling play_dj - or play_dj should call it itself: This allows GUIs to return "okay, notified, please suppress DJ text message". There also is int 1e stuff, disk reset, track wrap avoidance and DMA wrap avoidance. For the latter two, I recommend: If buffer is exactly aligned, transfer limit should probably be 64k, not 64k - 1 sector. Track wrap protection and DMA wrap protection should be turned off (maybe add a SYS CONFIG variable!) for harddisks. There is also UMB avoidance: If a buffer is in UMB or HMA, all access is copied through the low RAM disk transfer buffer (which is only 1 sector big). Probably required, but should be mentioned in kernel docs (<-> DEVICEHIGH/LOADHIGH). If the wrap checks would be done by int 13 handler (with int 2f.13 control interface as in FDSHIELD), not only DOS access but also direct disk access would be protected, plus you gain disk change detection reliability. Maybe make that a compile time option. [Grrrr... know your mailx tilde escapes! ~r, not ~c...!] ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel