At 01:43 AM 8/19/2006 +0400, Arkady V.Belousov wrote:
>e> are disabled by INT 15, and restored by iret) You miss, that only
>recent releases of EMM386 do now respect original flags value on the stack
>- previous releases just directly manipulate IF flag and do "retf 2". te>
>So I assume th
Hi!
17-Авг-2006 21:52 [EMAIL PROTECTED] (tom ehlert) wrote to Michael Devore
:
te> I don't know why pushf/cli/popf got even in there, as for any
te> selfrespecting BIOS, this should have *exactly* no effect (interrupts
te> are disabled by INT 15, and restored by iret)
You miss, that only re
Hi!
17-Авг-2006 12:49 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> Unless found precise reason, there are no assurance, that your patch
>>fixes (not masks) anything and not damages anything else.
MD> It wouldn't damage anything else, but it might mask i
At 09:52 PM 8/17/2006 +0200, tom ehlert wrote:
> > I was a bit worried about the return address getting munged myself,
> > but the fact of AX modification is a good reason for why the BIOS bug
> > didn't keep biting, and the first patched worked.
>
>the 'first patch' actually was the original - fro
Hello Michael,
> I was a bit worried about the return address getting munged myself,
> but the fact of AX modification is a good reason for why the BIOS bug
> didn't keep biting, and the first patched worked.
the 'first patch' actually was the original - from the good old times
before Michael en
At 12:49 PM 8/17/2006 -0500, I wrote:
> > 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:
> >| r
>> there's one possible solution to this, and I seem to remember
>> that at some time some variant of (MS/DR/NOVELL/...)DOS had the following
>> solution:
>>
>>look at first few instructions in program (or typical header
>>values etc.)
>>if this looks like a brain dead old exepacker, r
> there's one possible solution to this, and I seem to remember
> that at some time some variant of (MS/DR/NOVELL/...)DOS had the following
> solution:
>
>look at first few instructions in program (or typical header
>values etc.)
>if this looks like a brain dead old exepacker, relocate
Hello Michael,
>> 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
>
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 da
>that's all I know. this ugly patch solves the issue.
>>> But how you found this?!
te>> by trying these 2 versions. one works, the other doesn't
> But how you found working version?!
with luck. I had an old version that worked.
Tom
---
Hi!
17-Авг-2006 14:08 [EMAIL PROTECTED] (tom ehlert) wrote to "Arkady V.Belousov"
:
that's all I know. this ugly patch solves the issue.
>> But how you found this?!
te> by trying these 2 versions. one works, the other doesn't
But how you found working version?!
>> And what you fou
>>> >> Do you mean "flags, _saved on the stack above given code_"?
>>> >> And, if so, then why flags are damaged, but return value, which was lies
>>> >> on place of flags (relative SP) are not damaged, if you comment out
>>> >> "pushf"?
>>>that's all I know. this ugly patch solves the issue.
Hi!
17--2006 03:05 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> >> May you explain here and/or, better, in comments in source, why
>> >> decreasing SP solves issues (and which issues there are)?
>> >>>Only plausible explanation: THIS BIOS damages (some
At 09:20 AM 8/17/2006 +0200, tom ehlert wrote:
> >> May you explain here and/or, better, in comments in source, why
> >> decreasing SP solves issues (and which issues there are)? >>Only
> >> plausible explanation: >>THIS BIOS damages (sometimes ?) the
> >> flags; Do you mean "flags, _sav
>> May you explain here and/or, better, in comments in source, why
>> decreasing SP solves issues (and which issues there are)? >>Only
>> plausible explanation: >>THIS BIOS damages (sometimes ?) the
>> flags; Do you mean "flags, _saved on the stack above given code_"?
>> And, if so, t
At 06:19 AM 8/17/2006 +0400, Arkady V.Belousov wrote:
> May you explain here and/or, better, in comments in source, why
> decreasing SP solves issues (and which issues there are)? >>Only
> plausible explanation: >>THIS BIOS damages (sometimes ?) the
> flags; Do you mean "flags, _save
Hi!
16-Авг-2006 13:19 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> At 03:21 PM 8/16/2006 +0200, tom ehlert wrote:
>>'solved' the original bug (sort of) by changing
>>disable_enable_a20_BIOS:
>> ;pushf
>> ;cli
>> shr ah,1; ah
At 03:21 PM 8/16/2006 +0200, tom ehlert wrote:
>'solved' the original bug (sort of) by changing
>
>disable_enable_a20_BIOS:
> ;pushf
> ;cli
>
> shr ah,1; ah to 0 or 1
> mov al,24h
> xchgah,al ; ax == 2400h to turn off, 2401h to turn on
>
I've uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ the file
himem324.zip, containing a revised HIMEM executable and source file changed
from version 3.23.
This is an alternative version of HIMEM I'm making available for
testing. It is only slightly modified from the previous versi
20 matches
Mail list logo
