> - small bugfix. Which is, for function 0x67: rp->r_ai->AI_Flag = (UBYTE)~(descflags / DF_NOACCESS) & 1;
Basically it makes the function work as before, or as, for example: rp->r_ai->Al_Flag = !(descflags & DF_NOACCESS); Original code was: > case 0x47: /* set access flag */ > pddt->ddt_descflags |= DF_NOACCESS; > if (rp->r_ai->AI_Flag) > pddt->ddt_descflags &= ~DF_NOACCESS; So "small bugfix" must be clarified as "if you use ONE (not sure which) dsk.c patch from Arkady, you *must* also use this 'small bugfix' patch, because the first patch accidentally inverted the result..." The broken disk access flag was the reason for "kernel 2035a does not allow FORMAT to access harddisk partitions unless they already have a valid FAT filesystem". Arkady, if you do not start explaining in more detail WHY you patch WHAT and HOW, then those people who cannot read all your patches (because they are less fluent in C than in English) will miss the really useful patches which are hidden behind optimizations. By the way, any compiler which would be smart enough to translate the code to "test dh,2 setz al" for 386+, assuming that AL will be written to Al_Flag and DX contains descflags? The whole optimization of this code seems to have started because some compiler created "big" code "if ... then AL=0 else AL=1", with some jumps... Arkady then used the division method, which is supposed to be optimized to a shift (works on "all" compilers, but for 8086 code this means that you need "mov cl,9 shr dx,cl ...". Still, the shift avoids ONE compiler stupidity (several jumps) at the cost of risking ANOTHER compiler stupidity (actual use of division). Plus I think NO compiler will be clever enough to see that the "division" can not only be implemented as "shift" but actually only is a "test/setz". Chances for the latter should be much better with the ORIGINAL 2035a code. Or try: rp->r_ai->AI_Flag = 0; if (!(descflags & DF_NOACCESS)) rp->r_ai->AI_Flag++; Whatever, this discussion has been going on off-list for 10 mails or so, while we are actually only talking about at most +/- 6 byte optimization. And no, if it is 7 byte, you do not have to write a clarifying answer on list. 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=4721&alloc_id=10040&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
