Re: [Freedos-kernel] Floppy disk read error
Hi! 17--2004 00:38 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: Later (after I recompile again) I try to send you (privately) compiled kernels again (and send separate letter with notification about this). But if you not receive this archive again, then I can't help you, because have no other ways beside mail. A Please yes, but sent it packed (zip or rar), it could get blocked by A some overzealous antivirus. Of course, I send in RAR archive. A And yes, a separate letter will help to find it. You and also send it cc: A to am (AT) cosmodata.com.br, which is on a diffrent server. I sent to both addresses. A I checked all my Spam and Garbadge an found nothing with attachement... Then I don't know, how to send attachments to you. :( --- 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
[Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
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 did. Read and shut up: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/format/format-0.91r.txt Maybe saturation would be better. How do other DOSes handle this? maybe would be better that YOU check other DOS'es behaviour BEFORE Buy me another DOS or shut up. please provide exact code sequence where it DOES return nonsense - and I'll fix it. (we are talking about ke2035 !!) That translates to: Provide a fix and you will have provided a fix. Helpful. there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. end of story. Compiler weakness :-P. 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. Alternative explanation: BIOS probably did not care to initialize the values because they are not needed for LBA access anyway. 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. I vote for: Then you better only use the first 2 TB. But current situation is: Use only the first 1024 CYLINDERS and stop using LBA at all. Certainly wrong. If you think it is risky to access such disks, accessing them in CHS mode will be risky, too. And you will probably have only a fraction of the DOS partitions reachable at all if you drop to CHS mode. Of course you could drop even further, to this is no disk. I think the code can be forgiving here, because: flash disks and similar devices sometimes have odd BIOS support, but because we do not only read LBA information but also partition tables, REALLY broken BIOSes are still safely excluded. If buffer is exactly aligned, transfer limit should probably be nonsense. you simply cant issue a read request to DOS 0x Thanks for telling, should probably be clarified in the DMA checker code. 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... I know that you cannot detect this. BUT on the other hand I believe that turning off track wrap protection and maybe also DMA wrap protection can help to significantly improve performance, so the user should be allowed to enable that - manually and at own risk. Sorry but I have no big test partitions where I could test that, so somebody else has to. 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
Re: [Freedos-kernel] ludivmul.inc
On Mon, 19 Jul 2004, Arkady V.Belousov wrote: 20-éÀÌ-2004 00:55 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO encouraging... In any case, I appreciate that a bug was found in BO ludivmul.inc; the same bug was in fact present in the 64 bit version I BO adapted it from! Well I notified the original author. BTW, may you point me place, where I may see the prove that present algo is correct? I myself prove this, but my prove not looks beauty to include into comments as explanation. :( I'm not aware of any direct proofs but you'll get a long way with Donald E. Knuth's book The Art of Computer Programming, Volume 2, Seminumerical Algorithms. He covers 2n-base / 2n-base division if only n-base/n-base division is provided. A bit of simplification is possible if 2n/n already exists. My bugfix-list for umb_init() includes 7 positions. How I may isolate bugfixes from new umb_init() edition?! Try to optimize something else, namely instead of how do I fix it while saving as many bytes as possible in the kernel you play the game how do if I fix it while saving as many lines as possible in the diff. Anyway, I already tried to explain you too many times, I presume it doesn't help then. Bart --- 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
