#27 Windows support

[japheth]

dosemu's dpmi host (cvs version) has problems with
routing int 23h to protected mode. The routing itself
works, but it seems to me that some register
information gets lost when returning to real-mode, for
example the contents of the floating-point registers
change to "random" values.

There are other odd things, but possibly these look
better once this problem is resolved.

[Stas Sergeev]

Logged In: YES
user_id=501371

Where is your glorious test-case?
Does the information gets lost when you do retf/CF, or also
even when you just do iret?
Anyway, see the attached patch. It should handle the
termination case (retf/CF) better.

[Stas Sergeev]

Logged In: YES
user_id=501371

Could you please also provide the test-case for the
windows binaries relocation problem? (when more than
one stripped binary started) I wonder why you haven't
told us about that problem before. It is not something
that we can't quickly fix I suppose.

[japheth]

Logged In: YES
user_id=982058

Where is your glorious test-case?
Does the information gets lost when you do retf/CF, or also
even when you just do iret?

I attached the simple test case for int 23h. It's the binary
and the asm source code (though you wont be able to assemble
it, its meant as info only).

• It installs an int23 handler (currently just an iret!)
• it stores a value in st(0)
• then displays strings with int 21h, ah=9, waiting for
  escape key
• now checkes if st(0) has been modified

if you run this app and DON'T press ctrl-c, it should
display "no changes..."
if you run it and press ctrl-c before pressing escape it
displays an error with dosemu. on other platforms still
displays "no changes...".

Could you please also provide the test-case for the
windows binaries relocation problem?

In my eyes that is not a bug, it's just a missing feature of
dosemu. It would require dosemu to provide something like
the DPMI V1.0 feature "virtual machines" (multiple address
contexts). I thought this would be too sophisticated for the
moment. And if in the near future dosemu will run windows
95, this feature will have been implemented anyway ;-).

[Stas Sergeev]

Logged In: YES
user_id=501371

contexts). I thought this would be too sophisticated for the
Is this an excuse for not providing the test-case? :)
I can just remap the area that is allocated by an inactive
client, and the problem is fixed. When the client became
active again, I remap its areas to the previous locations.

[japheth]

Logged In: YES
user_id=982058

Is this an excuse for not providing the test-case? :)
I can just remap the area that is allocated by an inactive
client, and the problem is fixed. When the client became
active again, I remap its areas to the previous locations.

Sounds great. But there is the problem that no dpmi API is
defined to start an application in a new address context.
With HX I do it simply by hiding the current dpmi server
instance (for that real mode int 2f, ax=1687h is
intercepted). So another server will have to be loaded if a
new client wants to start. But how to implement anything
similiar in dosemu? Would one have to define a proprietary
API for that? Setting an environment variable? Or an option
in .dosemurc?

[Stas Sergeev]

Logged In: YES
user_id=501371

Sounds great. But there is the problem that no dpmi API is
defined to start an application in a new address context.
Yes, that always kept me puzzled. DPMI spec have a lot
of bla-bla-bla about the "virtual machines", but fails to answer
the simplest question: how is to create that separate virtual
machines? I don't know how could this happened. Was it
simply forgotten by the spec writers, or it is just me unable
to find it in specs?

But how to implement anything similiar in dosemu?
Now you confused me. I thought the problem is only
that the function 504h fails with ax=8012h. What are
the real problems here? If it is just about function 504h,
then I see no problems at all, otherwise I don't know.

[japheth]

Logged In: YES
user_id=982058

Now you confused me. I thought the problem is only
that the function 504h fails with ax=8012h. What are
the real problems here?

I thought the problem was:

1. you have 2 binaries (i.e. PE format without relocation
   info and the same image base), the first calling the second.
   This doesn't work with dosemu because there is one address
   space only to be shared by all dpmi clients, so the first
   will be loaded and run, the second fails to load when trying
   to alloc memory with 0x504.

But what would you - or dosemu - do then when/after function
0x504 failed?

---

Possibly I should remind you that this thread is about int
23h errors and loosing floating point register values.

[Stas Sergeev]

Logged In: YES
user_id=501371

I attached the simple test case for int 23h.
Thanks. Fixed in dpmi.c:1.98.
Please test how the termination now works - I worked a bit
more on it.

And if in the near future dosemu will run windows
95, this feature will have been implemented anyway ;-).
So, how win95 says "run this client in a separate context"?
Supporting truely separate contexts under dosemu would
be difficult. And I don't think the ptrace approach will work.
I don't see how the ptracer can, for example, do memory
management on behalf of the child process.
But I think it is not needed in most cases and we can
do a trivial hack on func 504h to get things working.

Btw, I figured out the problem with 32rtm (which you
probably haven't ever triggered under dosemu). It will
silently disappear soon, noone will even notice.

Still trying to get krnl286 running when int2f reports
standard mode. krnl386 already works, but no luck
with the 286 one...

[Stas Sergeev]

Logged In: YES
user_id=501371

But what would you - or dosemu - do then when/after function
0x504 failed?
I wont let it to fail. I'll just back out the needed region
and retry
the allocation.

Possibly I should remind you that this thread is about int
23h errors and loosing floating point register values.
Thanks:) but this is already fixed, and the advantage of
that thread is that you can attach to it.

[japheth]

Logged In: YES
user_id=982058

I got the current cvs.

1. The test with the "IRET" int 23h handler now works and
   doesn't trash registers.

2. I can also confirm that an int 23h handler which returns
   with

STC
RETF ;only RETF, not RETF 2/4,as it is described in RBIL!

activates dosemu's automatic termination. This work fine -
as long as no special cleanup work has to be done by the
client. But one should be aware that this termination method
is supported by dosemu only, not by winxp or win9x hosts.

1. The case that the client installs an int 23h handler and
   calls
   int 21h, ah=4Ch has problems, especially if it isn't the
   primary
   client who is terminating. Here win9x does a good job, but
   winxp has its own problems with this variant.

Personally I think this thing now works good enough.

[Stas Sergeev]

Logged In: YES
user_id=501371

client. But one should be aware that this termination method
is supported by dosemu only, not by winxp or win9x hosts.
That means the clients will not use it - very good:)

int 21h, ah=4Ch has problems, especially if it isn't the
primary
client who is terminating. Here win9x does a good job, but
But I already suggested (when discussing the WD problems)
that dosemu can find out what exactly client is terminating,
and do the better clean-up work, which could also help WD.
But you said its a bad idea...

[japheth]

Logged In: YES
user_id=982058

But you said its a bad idea...

IIRC I said it wouldn't help with the WD problem.

But with "primary client" I meant simply the first client
starting in this dos box. Your suggestion was, IIRC, to
check if it is the "active" client (the last one started in
the box) which is terminating and do a better clean-up work
if it is NOT.

[japheth]

Logged In: YES
user_id=982058

But what would you - or dosemu - do then when/after function
0x504 failed?

I wont let it to fail. I'll just back out the needed region
and retry the allocation.

That sounds a bit hazardous. I doubt that you can determine
in the host if the memory region can be safely "moved away".

The best I can currently imagine for dosemu is to optionally
start a new "virtual machine" when a new client starts, with
the conventional memory being a shared region (so not really
a VM). The previous client's extended memory, IDT, LDT, IVT?
and real-mode callbacks have to be saved, initialized and
later restored. In fact, this is just a little bit more than
what is done for a DPMI V1.0 client.

[Stas Sergeev]

Logged In: YES
user_id=501371

But with "primary client" I meant simply the first client
starting in this dos box.
<pedantic mode="" on="">
A primary client of a VM is the topmost (most recent)
client of the
stack within the VM. It is the last client of the
virtual machine that
called the protected mode entry routine obtained
through Int 2FH
Function 1687H.

So you might be confused.
<pedantic mode="" off="">

That sounds a bit hazardous. I doubt that you can determine
in the host if the memory region can be safely "moved away".
I don't see the concern. To me any region that belongs
to the currently inactive client, is safe to move away.
There may be an exceptions from this, like those if the
client was started by directly calling int21 DOS exec
from protected mode. In this case it may want to access
the memory of its parent. But this is not something that
can stand on a way I think.

[japheth]

Logged In: YES
user_id=982058

To me any region that belongs
to the currently inactive client, is safe to move away

But since - at least for 0.9 servers - a new client inherits
the IDT/LDT of the previous (or "inactive") client, how
could you be sure that in the memory you just moved away
there is no code of the inactive client to be executed?
I'm afraid I am misunderstanding something.

[Stas Sergeev]

Logged In: YES
user_id=501371

But since - at least for 0.9 servers - a new client inherits
the IDT/LDT of the previous (or "inactive") client, how
could you be sure that in the memory you just moved away
there is no code of the inactive client to be executed?
Because any interrupts, exceptions, realmode callbacks
and everything else that could transfer the control from
one client to another, is passed through the server. Of
course if the client that has the "moved" areas, became
active, the first thing to do would be to swap its data/code
back.

I'm afraid I am misunderstanding something.
I don't know what exactly. I think this technique is
very common, was used to create "multitasking" on
286 machines etc.

[Stas Sergeev]

Logged In: YES
user_id=501371

Of course if some idiot will activate another client with the
far calls, then I think my technique will screw up. But is
this really ever happens in the real world?

[japheth]

Logged In: YES
user_id=982058

But is this really ever happens in the real world?

I think yes. Example:

1. client installs handler for int 21h
2. starts new client

3. new client installs handler for int 21h, which may look
   like this:

   cmp ah, xx ;wants to catch xx function
   jz domywork
   jmp fword ptr cs:[oldint21] ;jmp to previous handler
   domywork:
   ....
   iret

That's usual coding, and in this trivial case you already
have this far jump. Not to mention pointer parameters, which
would require yet another API translation layer.

[Stas Sergeev]

Logged In: YES
user_id=501371

That's usual coding, and in this trivial case you already
have this far jump.
That's the usual coding only when the clients are in the
same address space. If both the clients needs to be loaded
at a fixed address, they either will not do this,
or will store such a shared code in the specially allocated
shared memory regions. Otherwise this just can't work.
And since the clients that must be loaded at a fixed
address, assume the separate address space, they'll
surely not do this.

[Stas Sergeev]

Logged In: YES
user_id=501371

A bit of cheating, and you can attach (the win32 testcases)
to the "Windows support" thread.

[japheth]

Logged In: YES
user_id=982058

before doing win32 stuff I would suggest to fix win16 bugs.

There is at least one causing TDW.EXE to not work under
win311 in dosemu. I once wrote another win31 debugger, and
it doesnt work either - as long as it uses toolhelp.dll,
which is used by TDW as well. If it bypasses tooolhelp by
installing its own exception handlers, everything works.

So I examined toolhelp a bit and found:

• it installs handlers for exceptions 0, 6, c, d, e
• it does NOT install handlers for exception 1 and 3 but
• it installs interrupt handlers for int 01 and int 03

Using interrupt handlers instead of exception handlers
should work for exceptions 0-7 according to dpmi specs. The
default handlers for these exceptions should switch back to
the application stack and then call the appropriate interrupt.
I suspect that dosemu doesn't do this, so toolhelp isn't
notified about int 1 and int 3, and therefore TDW is unable
to work.

BTW: since the dpmi specs also says that protected mode
interrupts should be routed to real mode, the exceptions may
finally be reported to the real-mode interrupt handlers. One
may argue if this is useful. Anyway, the win9x host (and
hdpmi) are doing it.

As usual I attached a simple test app. I should mention that
the test fails not only on dosemu, but also with dosx on winxp.

[Stas Sergeev]

Logged In: YES
user_id=501371

Using interrupt handlers instead of exception handlers
should work for exceptions 0-7 according to dpmi specs.
DPMI specs says these exceptions are reflected to
the real-mode interrupts. And not exception 6!

I suspect that dosemu doesn't do this
Dosemu does exactly what DPMI spec says here.

BTW: since the dpmi specs also says that protected mode
interrupts should be routed to real mode, the exceptions may
finally be reported to the real-mode interrupt handlers.
From what I can see from DPMI specs, you are
thoroughly confused. They gets reflected to real-mode
handlers only!

One may argue if this is useful.
Who will argue on what's the spec explicitly says?

Anyway, the win9x host (and hdpmi) are doing it.
Certainly.

As usual I attached a simple test app.
Your app crash with an unhandled exception 6. This
is exactly how DPMI specs say it should work.

I should mention that
the test fails not only on dosemu, but also with dosx on
winxp.
No surprise. Your test-case is ill.

[japheth]

Logged In: YES
user_id=982058

DPMI specs says these exceptions are reflected to
the real-mode interrupts. And not exception 6!

all dpmi hosts I know - including dosx of winxp, the one
exception is dosemu - route exceptions to protected mode
ints. On the other hand, routing from pm ints to real-mode
ints is sometimes implemented for int 1 and 3, but never for
int 0 and 6 (the others I dont know). IMHO this is just a
typo in the docs, because what sense would it make to route
int 00 to real-mode? The app would be terminated in
real-mode, leaving the client with an invalid PSP and the
system crashes.

From what I can see from DPMI specs, you are
thoroughly confused. They gets reflected to real-mode
handlers only!

I was a bit tired I have to admit, but not confused.

Who will argue on what's the spec explicitly says?

If the real-world looks different, one may possibly ignore
the docs :-)

Your app crash with an unhandled exception 6. This
is exactly how DPMI specs say it should work.

it was an int 3, not int 6!

No surprise. Your test-case is ill.

No, dosx is ill. The test-case is bad only because it uses
exception 3, so it is hard to debug. With a similiar
test-case for exception 0 it can easily be shown that dosx

• routes the exception to the pm interrupt
• but calls it with an invalid stack frame if client is 32bit
  (eip + cs +eflags should be on the stack, but dosx pushes
  eip + eflags + eflags!). So the IRET fails.

Exception 00 is a far better case to watch, especially with
win31, because it can be seen that the exception handler is
installed by GDI (to silently cure GDI exceptions), but the
pm interrupt handler is installed from krnl386, which in
turn signals divide errors to the apps. If exceptions were
routed directly to real-mode, this cannot work. So making a
simple win16 test app should prove that dosemu is failing.

[japheth]

Logged In: YES
user_id=982058

In case it was confusing: with "dosx" in the last post I
meant windows xp's dosx, not win31's dosx:

[japheth]

Logged In: YES
user_id=982058

So making a simple win16 test app should prove that dosemu
is failing.

I made and attached this test app. If the exc -> pm int
routing works finally, this app will no longer crash dosemu