>> 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 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
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
>>> >> 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 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
>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
---
It seems that bximage.exe of bochs does not fill in the boot sector correctly.
FreeDOS seems to be able to cope with this. But some tools, especially mine,
defrag, chkdsk, diskcopy can't handle it and diskcopy crashes.
So when creating an image for the emulator, you should first format it and th
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
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
>
> 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
>> 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
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
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 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
[sent again with the right SourceForge-approved e-mail address this time]
Anybody have a MS-DOS 5.x or 6.x image around I could use? I need to do
some side-by-side testing in Qemu of MS-DOS against FreeDOS. I had an
image, but it seems to have gone missing. Thanks.
-
Hi Michael:
Try www.bootdisk.com. boot622.exe will extract a usable MSDOS boot
floppy. It wants a disk drive...if you don't have one, I'd suggest
using VFD to capture the image. (A very useful program that assigns
a drive letter to a "virtual" floppy disk drive and can use a file
as a floppy).
At 04:54 PM 8/17/2006 -0400, Mark Bailey wrote:
>Try www.bootdisk.com. boot622.exe will extract a usable MSDOS boot
>floppy.
Cool deal. What you sent boots up under Qemu no problemo. Thanks.
-
Using Tomcat but need to do
On Thu, 17 Aug 2006, Michael Devore wrote:
> [sent again with the right SourceForge-approved e-mail address this time]
>
> Anybody have a MS-DOS 5.x or 6.x image around I could use? I need to do
> some side-by-side testing in Qemu of MS-DOS against FreeDOS. I had an
> image, but it seems to have
While testing out a users bug report, I found a terribly obscure difference
between the way MS-DOS kernel works and FreeDOS kernel works. It shouldn't
matter, but it does to QuickBASIC 4.x applications, at least for some using
BRUN40. I don't know the scope of how many QB applications are aff
Hi,
I'm pleased to read the repies are reasonable and positive, I surely hope
Johnson understands sometimes things cannot be pushed too far towards the
direction he wishes.
BAHCL
_
Learn English via Shopping Game, FREE!
http://ww
20 matches
Mail list logo
