Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Arkady, 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 te really ? te please provide exact code sequence where it DOES return nonsense - and te I'll fix it. (we are talking about ke2035 !!) Bernd and Eric many times report, that WHICHFAT utility behaves wrongly under FreeDOS. If you blindly ommit those reports, then this not close the fact, that this happens. and why didn't you fix it long ago ? LBA_Get_Drive_Parameters should NOT disable LBA access if heads or sectors are 64k te As I wrote this: WHEN why don't you go to HISTORY.TXT ? AND WHERE?! most probably in aachen, western germany, 3'rd planet in solar system but should be mentioned in kernel docs (- DEVICEHIGH/LOADHIGH). te which kernel docs ? config.txt? this isn't an issue of *additional, non-standard* config.sys sysntax. tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi! 22--2004 22:16 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: Bernd and Eric many times report, that WHICHFAT utility behaves wrongly te and why didn't you fix it long ago ? Because not all parts of kernel is well known for me. LBA_Get_Drive_Parameters should NOT disable LBA access if heads or sectors are 64k te As I wrote this: WHEN te why don't you go to HISTORY.TXT ? Searching LBA_Get_Drive_Parameters inside history.txt... Not found. Searching LBA... No mentions for suspicous values interpretation. May be, above you was assume _when_ I wrote this _code_? but should be mentioned in kernel docs (- DEVICEHIGH/LOADHIGH). te which kernel docs ? config.txt? te this isn't an issue of *additional, non-standard* config.sys sysntax. Anyway, Eric right - FreeDOS is not enough good texts with description of different aspects (even if texts in some aspects will duplicate Pat's book). For example, description for memory model (including issues with standard RTL inclusion) is a very important thing, which should be described. BTW, Bart not answer, may be you: what happen when in OW will be fixed bug with near (not far) calls to RTL functions? In this case current kernel (with __U4M and __U4D in relocatable HMA_TEXT) will not work after compilation. --- 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_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi, I reduced the 500 line mail to 140 lines now... enjoy. Eric. --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
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
Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Eric, DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of a NULL navc pointer. If so, please submit some code to make the kernel crash. if not, shut up. I wonder if it is really desirable that the current implementation fakes bigger cluster sizes to allow cluster counts below 64k Probably Bart implemented it for sheer fun ? Maybe saturation would be better. How do other DOSes handle this? maybe would be better that YOU check other DOS'es behaviour BEFORE writing emails, because you are just bored ? 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 really ? please provide exact code sequence where it DOES return nonsense - and I'll fix it. (we are talking about ke2035 !!) for int 21.1c - probably some 0:xx data or stack got overwritten. please provide exact code sequence where it DOES overwrite something - and I'll fix it. (we are talking about ke2035 !!) LBA_Get_Drive_Parameters should NOT disable LBA access if heads or sectors are 64k As I wrote this: if sectors or heads are 64K the LBA BIOS is probably buggy. and IMO it's better to refuse to work with a buggy BIOS then to try to trash a users disk. or if totalSectHigh is nonzero. this will be relevant when disk (arrays) are larger then 2 TB (not that far away) but then we good old partitioning scheme stops to make sense, and it's better not to touch these disks at all. there could be some (easy) workarounds for that (my estimate less then a few hundred resident byte) + understanding dynamic disk partitioning (non resident code). until that is done it's a better idea not to touch these disks. 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). as was relied before (but you are probably so busy writing emails rather then reading) : there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. end of story. LBA_Transfer should call the appropriate int 2f.xx function before calling play_dj - or play_dj should call it itself: which 2f.xx functions please ? For the latter two, I recommend: If buffer is exactly aligned, transfer limit should probably be 64k, not 64k - 1 sector. nonsense. you simply cant issue a read request to DOS 0x Track wrap protection and DMA wrap protection should be turned off (maybe add a SYS CONFIG variable!) for harddisks. nonsense again: there's a specific field in EXT13 functions, if DMA crossing is allowed or not (and the kernel doesn't care about it) doesn't make a difference anyway. 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, definitively for EMM386 style UMB's (lacking Virtual DMA support) on some UMBPCI machines but should be mentioned in kernel docs (- DEVICEHIGH/LOADHIGH). which kernel docs ? tom --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
