Re: Bug in the latest version

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> a) the DOS time is the same as in the previous PIC call.
PIC schedules the next activation time
and then works in "polling" mode to see
when that time is reached. Even when it
reached, there are no guarantees that it
is possible to fire the int right away,
so it can keep waiting. So it is OK when
the activation time doesn't change for
the several PIC polling cycles.

> b) IP is increased by 1 (c000:0009->c000:000a) for no apparent reason.
Some priviledged 1-byte instr was emulated?

> Namely, the PIC call before the one above does this:
I really wouldn't suspect PIC in that case.
PIC deals with an async stuff and it was
the constant source of the random crashes,
but for the 100% predictable crashes it wasn't
caught responsible yet (by me at least).

Looking at this:
> c:\wp51\wp
>          exit wp
> c:\wp51\wp
> Then, Dosemu exits with an error message.
the crash happens on the (second) startup and
at startup we have an exepack, that's why it
seems more reasonable to suspect it, together
with the fact that I am using the unpacked
wp.exe and can't reproduce the problem...

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Lars BjÛrndal wrote:
> Thank you! Now, wp.exe works perfect!
Fine. Now we know that was just another
exepack bug, not fixable by loadfix btw.
The note should even be added in FAQ I
think, because nobody knows how many "bugs"
will we chaise in a future thanks to an
exepack (and UPX!) authors.

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Hartmut Figge wrote:
>> It doesn't *cure* the problem, because
>> the real problem is an exepack's bugs
>> and not the default DOS loader.
>  To clarify: it cured the problem with pushover. Or should i say, it
>  circumvented the problem caused by exepack?
That sounds better:)

> Can we agree, that there are cases, in which loadfix will work?
Sure, but it is not the real fix. It can
work around the "packed file corrupt" problem,
but I am just wondering why people prefer
that "solution", if unpacking exe is a permanent
fix, i.e. you will have to do that only once, you
will not be affected by another exepack bugs
etc.
What I was actually arguing against, is this:
> That cured the problem with the 'corrupte file' and was the only way, 
> to use that game.
It was neither the only, nor the best way in
fact. I never argued it can work around "packed
file corrupt" problem, but when the real fix
exists, loadfix seems useless to me. loadfix is a
kind of a bug-to-bug annihilation, not the fix.

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Hartmut Figge wrote:
> Looking in the folder, in which ancient batch files resides, shows e.g.
> push.bat, which contains the line 'loadfix push'.
> That cured the problem with the 'corrupte file' and was the only way, 
> to use that game.
I don't agree. loadfix works around the
exepack bugs by preventing the load to
some specific memory regions, AFAIK.
It doesn't *cure* the problem, because
the real problem is an exepack's bugs
and not the default DOS loader.
The only real fix is to get rid of exepack
entirely, which is to unpack an executable.
Actually I am unpacking all of the executables
I have here to avoid such a problems, but so
far the only problematic packers were exepack
and an old UPX.

Re: Bug in the latest version

[Hartmut Figge]

[Stas Sergeev]:

> Hartmut Figge wrote:
> 
>>Looking in the folder, in which ancient batch files resides, shows e.g.
>>push.bat, which contains the line 'loadfix push'.
>>That cured the problem with the 'corrupte file' and was the only way, 
>>to use that game.
> 
> I don't agree. loadfix works around the
> exepack bugs by preventing the load to
> some specific memory regions, AFAIK.
> It doesn't *cure* the problem, because
> the real problem is an exepack's bugs
> and not the default DOS loader.

To clarify: it cured the problem with pushover. Or should i say, it
circumvented the problem caused by exepack?

Nevertheless, that has nothing to do with dosemu. It was a problem with
some versions of MSDOS. IIRC, in any case, i got the 'corrupted file'
message, i could run 'loadfix programm' and the problem went away.

Of course, i had only tested a few of such programms, and there may be
other programms without hope.

Can we agree, that there are cases, in which loadfix will work?

cu
-- 
hafi

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Lars BjÛrndal wrote:
> I've noticed that if I use dosemu-1.0.1, the mem-command gives, in the
> line "largest executable program size" 617K, 1.1.3.5, the same command
> and config gives 611K. Why, do you think?
I can recall only one change in a memory
allocation algo of that times, which is this:
http://marc.theaimsgroup.com/?l=linux-msdos&m=99142972626428&w=2
Even though it is very unlikely, still try
to revert that patch and see if it helps.

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Lars BjÛrndal wrote:
> After starting dosemu:
> c:\wp51\wp
>          exit wp
> c:\wp51\wp
> Then, Dosemu exits with an error message.
> What can we do with this problem?
What can we do to reproduce this problem,
that is the question...
Btw, wp.exe is exepack'ed. To my memory
exepack was a constant source of troubles
("Packed file corrupt" and the like things).
I would suspect it also here.
Does it help if you unpack wp.exe before
starting?

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Hartmut Figge]

[Stas Sergeev]:

> Btw, wp.exe is exepack'ed. To my memory
> exepack was a constant source of troubles
> ("Packed file corrupt" and the like things).

That reminds me of old days, when some programms refused to work.
Looking in the folder, in which ancient batch files resides, shows e.g.
push.bat, which contains the line 'loadfix push'.
That cured the problem with the 'corrupte file' and was the only way, to
use that game. Full name was pushover, IIRC.

Perhaps 'wp' could be tested with 'loadfix'.

cu
-- 
hafi

Re: Bug in the latest version

[Lars Bjørndal]

How do I unpack the wp.exe-file?

I've tried "loadfix c:\wp51\wp.exe". Doing this command two times,
results in the same error.

Hartmut Figge <hfigge@uni.de> writes:

> [Stas Sergeev]:
>
>> Btw, wp.exe is exepack'ed. To my memory
>> exepack was a constant source of troubles
>> ("Packed file corrupt" and the like things).
>
> That reminds me of old days, when some programms refused to work.
> Looking in the folder, in which ancient batch files resides, shows e.g.
> push.bat, which contains the line 'loadfix push'.
> That cured the problem with the 'corrupte file' and was the only way, to
> use that game. Full name was pushover, IIRC.
>
> Perhaps 'wp' could be tested with 'loadfix'.
>
> cu
> -- 
> hafi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Bart Oldeman]

On Sun, 27 Oct 2002, Lars Bjørndal wrote:

> How do I unpack the wp.exe-file?

try this:
http://www.mirror.ac.uk/sites/ftp.simtel.net/pub/simtelnet/msdos/execomp/unp411.zip

I don't completely understand the log so I couldn't reply anything useful
so far. The last lines of your log look like this:

INT21 (0) at c000:1508: AX=3300, BX=0001, CX=0000, DX=0001, DS=c000, ES=c000
int 0x21, ax=0x3300
DO_VM86,  cs=0133:109e ss=c000:00f4 f=00033002
ax=3300 bx=0001 ss=c000 sp=00f4 bp=0000
           cx=0000 dx=0001 ds=c000 cs=0133 ip=109e
           si=13fb di=0162 es=c000 flg=00033002
RET_VM86, cs=c000:c009 ss=c000:00ee f=000b3217 ret=0x1
ax=8f11 bx=bf06 ss=c000 sp=00ee bp=0000
           cx=2352 dx=0001 ds=09e8 cs=c000 ip=c009
           si=e451 di=8208 es=c000 flg=000b3217
PIC:   0  32 00000000 fffafff9 00000000 Activate ++ dos time to 176073668
DO_VM86,  cs=c000:c00a ss=c000:00ee f=000b3217
ax=8f11 bx=bf06 ss=c000 sp=00ee bp=0000
           cx=2352 dx=0001 ds=09e8 cs=c000 ip=c00a
           si=e451 di=8208 es=c000 flg=000b3217
SIGILL while in vm86()
ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while in
vm86 (DOS)

Program=sigsegv.c, Line=202
EIP: c000:0000c3cf ESP: c000:000018e2  VFLAGS(b): 00000 00110010 00000110
EAX: 00006f04 EBX: 0000a0aa ECX: 0000f16a EDX: 00000000 VFLAGS(h):
00003206
ESI: 00008f79 EDI: 00008208 EBP: 0000e0e2 DS: 09e8 ES: 372a FS: 0000 GS:
0000
FLAGS: PF IF RF VM VIF  IOPL: 3

essentially the PIC is the last thing handled before the crash and Stas
knows the PIC better than I do. What looks suspicious (though maybe it
might be completely logical to the DOSEMU PIC experts) is that
a) the DOS time is the same as in the previous PIC call.
b) IP is increased by 1 (c000:0009->c000:000a) for no apparent reason.

Namely, the PIC call before the one above does this:

RET_VM86, cs=fdc8:6c52 ss=0133:0916 f=000b3286 ret=0x2f02
ax=111b bx=03c0 ss=0133 sp=0916 bp=0444
           cx=0000 dx=3601 ds=0133 cs=fdc8 ip=6c52
           si=00b0 di=00b0 es=036a flg=000b3286
Do INT0x2f: Using caller_function()
INT2F at fdc8:6c52: AX=111b, BX=03c0, CX=0000, DX=3601, DS=0133, ES=036a
MFS: Entering dos_fs_redirect, FN=1B
.. bunch of MFS stuff
PIC:   0  32 00000000 fffafff9 00000000 pic_itime[1]= 176096631
PIC:   0  32 00000000 fffafff9 00000000 pic_sys_time set to 176073668
PIC:   0  32 00000000 fffafff9 00000000 Activate ++ dos time to 176073668
DO_VM86,  cs=fdc8:6c52 ss=0133:0916 f=000b3287

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Lars Bjørndal]

Thank you! Now, wp.exe works perfect!
Lars
Bart Oldeman <oldeman@math.ohio-state.edu> writes:

> On Sun, 27 Oct 2002, Lars Bjørndal wrote:
>
>> How do I unpack the wp.exe-file?
>
> try this:
> http://www.mirror.ac.uk/sites/ftp.simtel.net/pub/simtelnet/msdos/execomp/unp411.zip
>
> I don't completely understand the log so I couldn't reply anything useful
> so far. The last lines of your log look like this:
>
> INT21 (0) at c000:1508: AX=3300, BX=0001, CX=0000, DX=0001, DS=c000, ES=c000
> int 0x21, ax=0x3300
> DO_VM86,  cs=0133:109e ss=c000:00f4 f=00033002
> ax=3300 bx=0001 ss=c000 sp=00f4 bp=0000
>            cx=0000 dx=0001 ds=c000 cs=0133 ip=109e
>            si=13fb di=0162 es=c000 flg=00033002
> RET_VM86, cs=c000:c009 ss=c000:00ee f=000b3217 ret=0x1
> ax=8f11 bx=bf06 ss=c000 sp=00ee bp=0000
>            cx=2352 dx=0001 ds=09e8 cs=c000 ip=c009
>            si=e451 di=8208 es=c000 flg=000b3217
> PIC:   0  32 00000000 fffafff9 00000000 Activate ++ dos time to 176073668
> DO_VM86,  cs=c000:c00a ss=c000:00ee f=000b3217
> ax=8f11 bx=bf06 ss=c000 sp=00ee bp=0000
>            cx=2352 dx=0001 ds=09e8 cs=c000 ip=c00a
>            si=e451 di=8208 es=c000 flg=000b3217
> SIGILL while in vm86()
> ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while in
> vm86 (DOS)
>
> Program=sigsegv.c, Line=202
> EIP: c000:0000c3cf ESP: c000:000018e2  VFLAGS(b): 00000 00110010 00000110
> EAX: 00006f04 EBX: 0000a0aa ECX: 0000f16a EDX: 00000000 VFLAGS(h):
> 00003206
> ESI: 00008f79 EDI: 00008208 EBP: 0000e0e2 DS: 09e8 ES: 372a FS: 0000 GS:
> 0000
> FLAGS: PF IF RF VM VIF  IOPL: 3
>
> essentially the PIC is the last thing handled before the crash and Stas
> knows the PIC better than I do. What looks suspicious (though maybe it
> might be completely logical to the DOSEMU PIC experts) is that
> a) the DOS time is the same as in the previous PIC call.
> b) IP is increased by 1 (c000:0009->c000:000a) for no apparent reason.
>
> Namely, the PIC call before the one above does this:
>
> RET_VM86, cs=fdc8:6c52 ss=0133:0916 f=000b3286 ret=0x2f02
> ax=111b bx=03c0 ss=0133 sp=0916 bp=0444
>            cx=0000 dx=3601 ds=0133 cs=fdc8 ip=6c52
>            si=00b0 di=00b0 es=036a flg=000b3286
> Do INT0x2f: Using caller_function()
> INT2F at fdc8:6c52: AX=111b, BX=03c0, CX=0000, DX=3601, DS=0133, ES=036a
> MFS: Entering dos_fs_redirect, FN=1B
> .. bunch of MFS stuff
> PIC:   0  32 00000000 fffafff9 00000000 pic_itime[1]= 176096631
> PIC:   0  32 00000000 fffafff9 00000000 pic_sys_time set to 176073668
> PIC:   0  32 00000000 fffafff9 00000000 Activate ++ dos time to 176073668
> DO_VM86,  cs=fdc8:6c52 ss=0133:0916 f=000b3287
>
> Bart
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Lars Bjørndal]

I've noticed that if I use dosemu-1.0.1, the mem-command gives, in the
line "largest executable program size" 617K, 1.1.3.5, the same command
and config gives 611K. Why, do you think?
Lars

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Bart Oldeman]

On Sun, 27 Oct 2002, Lars Bjørndal wrote:

> I've noticed that if I use dosemu-1.0.1, the mem-command gives, in the
> line "largest executable program size" 617K, 1.1.3.5, the same command
> and config gives 611K. Why, do you think?

I don't know. Depending on the DOS (Free or not), try mem /f or mem /d and
compare the two to find out where the difference is.

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Lars Bjørndal]

Bart Oldeman <oldeman@math.ohio-state.edu> writes:

> On Sun, 27 Oct 2002, Lars Bjørndal wrote:
>
>> I've noticed that if I use dosemu-1.0.1, the mem-command gives, in the
>> line "largest executable program size" 617K, 1.1.3.5, the same command
>> and config gives 611K. Why, do you think?
>
This problem was caused by that thing that 1.1.3.5 will not use the
autoexec.emu. I've replaced it with autoexec.bat now, and then it's
ok. Why will not .emu work?

My config.emu's last lines is:

SHELL=C:\DOS\COMMAND.COM C:\DOS\ /e:1024 /p

install=c:\subst.exe i: c:\
install=c:\lredir.exe c: linux\fs/dos

Witn dosemu-1.0.1, it is the autoexec.emu on the new drive c: that is
executed.

Lars

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Bart Oldeman]

On Mon, 28 Oct 2002, Lars Bjørndal wrote:

> Bart Oldeman <oldeman@math.ohio-state.edu> writes:
>
> > On Sun, 27 Oct 2002, Lars Bjørndal wrote:
> >
> >> I've noticed that if I use dosemu-1.0.1, the mem-command gives, in the
> >> line "largest executable program size" 617K, 1.1.3.5, the same command
> >> and config gives 611K. Why, do you think?
> >
> This problem was caused by that thing that 1.1.3.5 will not use the
> autoexec.emu. I've replaced it with autoexec.bat now, and then it's
> ok. Why will not .emu work?
>
> My config.emu's last lines is:
>
> SHELL=C:\DOS\COMMAND.COM C:\DOS\ /e:1024 /p
>
> install=c:\subst.exe i: c:\
> install=c:\lredir.exe c: linux\fs/dos
>
> Witn dosemu-1.0.1, it is the autoexec.emu on the new drive c: that is
> executed.

Well you can use
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /e:1024 /p /k C:\AUTOEMU.BAT
and use AUTOEMU.BAT instead of AUTOEXEC.BAT.

The problem with $_emubat, is that while it seems to work using some
OS'es, some COMMAND.COM's and some types of AUTOEXEC.BAT it is really a
hack and can be confusing. All kinds of weird things were possible such as:

* command.com simply crashing DOSEMU (this is what the FreeDOS command.com
did)
* command.com executing autoexec.emu for the first half and autoexec.bat
for the second half if the number of estimated "fakes" was not correct.
* you doing "type autoexec.bat" and getting the contents of autoexec.emu.
* potentially deleting or renaming the wrong file.

$_emusys is a hack too, but it's more predictable what the DOS does
(only one fake is needed) and it cannot be worked around so easily (only
using bootmenu's and keystrokes or a separate boot directory).

BTW if /K doesn't work you can use isemu.com in autoexec.bat:

isemu
if errorlevel 1 goto native_dos
call autoemu.bat
exit
:native_dos

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Stas Sergeev]

Hello.

Lars BjÛrndal wrote:
> Still the same problem, also with dosemu-1.1.3.4.
I tried to reproduce that problem on many
of the latest dosemus with virtually any
possible configurations, but in vain. So
I suspect it is not a dosemu's problem, but
no idea what is it.

> I've used v.1.0.1.0
> for a long time, and this problem wasn't there.
This is more interesting. Could you try 1.0.1 again
to see that the problem is not there when all other
configuration is exactly the same?

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Lars Bjørndal]

OK! I've now tried 1.0.1, and the problem isn't there. The
configuratin is exactly the same.
Lars

Stas Sergeev <stssppnn@yahoo.com> writes:

> Hello.
>
> Lars Bjørndal wrote:
>> Still the same problem, also with dosemu-1.1.3.4.
> I tried to reproduce that problem on many
> of the latest dosemus with virtually any
> possible configurations, but in vain. So
> I suspect it is not a dosemu's problem, but
> no idea what is it.
>
>> I've used v.1.0.1.0
>> for a long time, and this problem wasn't there.
> This is more interesting. Could you try 1.0.1 again
> to see that the problem is not there when all other
> configuration is exactly the same?
>
-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67

Re: Bug in the latest version

[Bart Oldeman]

On Sat, 28 Sep 2002, Lars Bjxrndal wrote:

> OK! I've now tried 1.0.1, and the problem isn't there. The
> configuratin is exactly the same.

How about 1.0.2.1 and 1.1.3? Just doing a "binary search" to see where
the problem appeared would help a lot to identify the bug.

Bart

Re: Bug in the latest version

[Lars Bjørndal]

Bart Oldeman <Bart.Oldeman@bristol.ac.uk> writes:

> On Sat, 28 Sep 2002, Lars Bjxrndal wrote:
>
>> OK! I've now tried 1.0.1, and the problem isn't there. The
>> configuratin is exactly the same.
>
> How about 1.0.2.1 and 1.1.3? Just doing a "binary search" to see where
> the problem appeared would help a lot to identify the bug.

It's the same problem in 1.0.2.1. Should I also try 1.1.3 then?

Lars

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67

Re: Bug in the latest version

[Bart Oldeman]

On Sat, 28 Sep 2002, Lars Bjxrndal wrote:

> Bart Oldeman <Bart.Oldeman@bristol.ac.uk> writes:
> 
> > On Sat, 28 Sep 2002, Lars Bjxrndal wrote:
> >
> >> OK! I've now tried 1.0.1, and the problem isn't there. The
> >> configuratin is exactly the same.
> >
> > How about 1.0.2.1 and 1.1.3? Just doing a "binary search" to see where
> > the problem appeared would help a lot to identify the bug.
> 
> It's the same problem in 1.0.2.1. Should I also try 1.1.3 then?

No, 1.0.2.1 predates 1.1.3. Probably best to make a log (-D+9a)
(form 1.1.3.4) bzip2 it and mail it to me.

Bart

Re: Bug in the latest version

[Lars Bjørndal]

The problem is also in v.1.1.3.5:

After starting dosemu:
c:\wp51\wp
        exit wp
c:\wp51\wp

Then, Dosemu exits with an error message.

What can we do with this problem?

Lars
-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in the latest version

[Lars Bjørndal]

:Start Dosemu
:Start wp51\wp
:Exit wp
:Start wp51\wp again

Then, dosemu exits, and This message occure:

ERROR: unexpected CPU exception 0x06 err=0x00000000 cr2=00000000 while in vm86 (DOS)
Program=sigsegv.c, Line=193
EIP: c000:0000c3cf ESP: c000:000018e2  VFLAGS(b): 00000 00110010 00000110
EAX: 00006f04 EBX: 0000a0aa ECX: 0000f16a EDX: 00000000 VFLAGS(h): 00003206
ESI: 00008f79 EDI: 00008208 EBP: 0000e0e2 DS: 09e8 ES: 372a FS: 0000 GS: 0000
FLAGS: PF IF RF VM VIF  IOPL: 3

Lars
-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in the latest version

[Bart Oldeman]

On Wed, 18 Sep 2002, Lars Bjxrndal wrote:

> :Start Dosemu
> :Start wp51\wp
> :Exit wp
> :Start wp51\wp again
> 
> Then, dosemu exits, and This message occure:

please be more specific: what does the "latest version" mean?
1.0.2.1? 1.1.3? 1.1.3.4?

Bart

Re: Bug in the latest version

[Lars Bjørndal]

On Thu, 19 Sep 2002, Bart Oldeman wrote:

> On Wed, 18 Sep 2002, Lars Bjxrndal wrote:
> 
> > :Start Dosemu
> > :Start wp51\wp
> > :Exit wp
> > :Start wp51\wp again
> > 
> > Then, dosemu exits, and This message occure:
> 
> please be more specific: what does the "latest version" mean?
> 1.0.2.1? 1.1.3? 1.1.3.4?
> 
> Bart
1.3.3.3
Lars

Re: Bug in the latest version

[Bart Oldeman]

On Thu, 19 Sep 2002, Lars Bjxrndal wrote:

> On Thu, 19 Sep 2002, Bart Oldeman wrote:
> 
> > On Wed, 18 Sep 2002, Lars Bjxrndal wrote:
> > 
> > > :Start Dosemu
> > > :Start wp51\wp
> > > :Exit wp
> > > :Start wp51\wp again
> > > 
> > > Then, dosemu exits, and This message occure:
> > 
> > please be more specific: what does the "latest version" mean?
> > 1.0.2.1? 1.1.3? 1.1.3.4?

> 1.3.3.3

Please try 1.1.3.4. There exists an MFS ("lredir file system") buffer
overflow in 1.1.3.3.

Also, if it the bug is still in 1.1.3.4, is it also present in older
DOSEMU's, such as 1.0.2.1?

Bart

Re: Bug in the latest version

[Lars Bjørndal]

Still the same problem, also with dosemu-1.1.3.4. I've used v.1.0.1.0
for a long time, and this problem wasn't there.

Bart Oldeman <Bart.Oldeman@bristol.ac.uk> writes:

> On Thu, 19 Sep 2002, Lars Bjxrndal wrote:
>
>> On Thu, 19 Sep 2002, Bart Oldeman wrote:
>> 
>> > On Wed, 18 Sep 2002, Lars Bjxrndal wrote:
>> > 
>> > > :Start Dosemu
>> > > :Start wp51\wp
>> > > :Exit wp
>> > > :Start wp51\wp again
>> > > 
>> > > Then, dosemu exits, and This message occure:
>> > 
>> > please be more specific: what does the "latest version" mean?
>> > 1.0.2.1? 1.1.3? 1.1.3.4?
>
>> 1.3.3.3
>
> Please try 1.1.3.4. There exists an MFS ("lredir file system") buffer
> overflow in 1.1.3.3.
>
> Also, if it the bug is still in 1.1.3.4, is it also present in older
> DOSEMU's, such as 1.0.2.1?
>
> Bart

-- 
Lars Bjørndal <lars.bjorndal@grieg.uib.no>
Storetveitåsen 15, 5067 Bergen.
Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html