#506 Windows 2.0 segfault with EMS

[Eric Larouche]

Trying to run Windows 2.0 with EMS makes
DOSEMU segfault. With EMS desactivated,
no fault happens.

With a full dissassembly of win.com and
much efforts single-stepping with a debugger,
I finally (!!) traced back the fault to a bug
in the EMS call implementation for AH=58h
get mappable physical addr array in
get_mpa_array in emm.c

According to the EMS spec, the array should be given
in ascending order of segment. The page frame
(in high addr) is allocated to the first 4 page numbers.
For this call, they should be listed at the end
instead of the beginning.

So, here is a fix for this bug.

P.S.
Note that Windows 2.x refuses to even load with FreeDOS.
But this seems to be related to the FreeDOS kernel, not DOSEMU.
(the same thing happens in VMWare).
I only succeeded to load Win 2.0 with MS-DOS 5.0,
with HMA disabled.

[Stas Sergeev]

Hi Eric, thanks for tracking this.
Indeed, disassembling win.com is probably a
large work, have you used IDA for that?
But let me suggest you that Windows 2 used
to work perfectly in the past, so any problems
with it you can easily nail with 'git bisect'.

I applied a slightly different fix to devel,
could you please test?

[Stas Sergeev]

Hmm, and yes, it should work with HMA
enabled too. If not - we have another regression.

[Eric Larouche]

I think your fix won't work.
EMS apps expect the first four
physical pages (0-3) to be in the page frame.
MS-DOS's EMM386.exe put them there and
physical pages 4-27 in conventional memory.
For the "get physical map call", it lists them
in seg order though:
seg 4000 page 4
...
seg 9c00 page 27
page frame seg 1 page 0
page frame seg 2 page 1
page frame seg 3 page 2
page frame seg 4 page 3

My fix was conformant with EMM386.exe behaviour.

*

For the disassembly I used NASM disassembler,
but IDA would have been probably a better idea.

For the HMA, I am bit baffled. It supposes to be
used only in Windows 2.1. The conflicts also
happens in VMWare, so I don't think it's a
DOSEMU regress.

[Stas Sergeev]

Do you mean only the GET_MPA method, right?
I don't expect there is any other way to
"check" if the first pages are in page frame?
This may be enough to revert my patch, but I
wonder if there are other means you are talking
about, or just that.

Still, what does Windows do now?

[Eric Larouche]

The emm_map array is indexed by physical page ordinal.
For example, for the map page API call, the physical page
argument (0-3) should correspond to the page frame. With
your fix, it will map in conventional memory.

The get_mpa method changes the order of the output
table because it must be given in seg order.

[Eric Larouche]

excerpt from the EMS spec
"The Map/Unmap Handle Page function maps a logical page at a
specific physical page anywhere in the mappable regions of
system memory. The lowest valued physical page numbers are
associated with regions of memory outside the conventional
memory range."

[Stas Sergeev]

The interesting thing is that I tested
my patch, and it worked fine even with
windows-3.1. :)
But I applied your patch now, thanks!
Need to sleep a little more.
Still wondering why it worked so well...

[Eric Larouche]

ok, thanks.
Maybe Windows uses all the pages
as a pool without consideration to order.

[Stas Sergeev]

Hi Eric, were you able to get win-3.0 to work
with this patch? There seem to be some problems.
Please see here:
https://github.com/stsp/dosemu2/issues/225