At 02:18 PM 8/17/2006 +0400, you wrote: > >>looks like sometimes someone damages something on the stack, which > >>goes unnoticed most of the time > > Unless found precise reason, there are no assurance, that your patch >fixes (not masks) anything and not damages anything else.
It wouldn't damage anything else, but it might mask it. However, permanent masking is the best we can do without the physical BIOS to test and research. There are other workarounds that have been made for other buggy BIOS chips. How would you actually fix a BIOS chip on a user's machine? You can't force them to re-flash it, even if it were possible and available. > >> > Could just be hitting one word on the stack, i.e. [sp] at INT > entry. That > > And? Why return address isn't damaged? Let me ask again: > >stack: >| ret address | >+-------------+ >| pushf | <- tom thinks, this value damaged >+-------------+ >| INT15 call | > >stack after tom's patch: > >stack: >| ret address | <- why this value not damaged? >+-------------+ >| INT15 call | The most obvious case would be if a single bit were being tripped and the bit still matched existing return address or changed it to a benign one (which could happen if the bit was low). Less obvious case would be if a particular value or bit pattern at the location triggered or avoids the overwrite. I could speculate on other potentialities for a long time. But it is a weird thing. That's why I would prefer the SUB SP change which avoids having anything critical at the [sp] location. > >> > would match the behavior on either of the two patches. > >>right > > No: in first case stack lesser, in second case it deeper. Resultant behavior (i.e. it's working) is matched regardless -- the literal sense of the statement is accurate. The solutions are different and one is not recommended in general because if the failure is apparently due to some type of [sp] corruption; it is happenstance that it works with the return address. >MD> Plus, I just found out that there exist old compressed DOS programs which >MD> avoid the automatic A20 handling of the kernel, > > Which packer (and/or programs, which packed by this/these packers)? Very old QuickBASIC program. I actually don't know if it's packed or exactly what it's doing in its little pinhead, but it does use segment wrapping. Shortly after startup the debugger showed it normalized/underflowed a 0F73:0 segment value to an FF74:FFF0 address pointing in HMA with poor results. Ran the program in an environment where a known problematic EXEPACKed program worked (8ACROSS), it still failed. Ran it under LOADFIX, it worked. The evidence is compelling. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
