Re: interrupts in when in NT version

2002-10-26 Thread Zsolt Rizsanyi
I have forgotten to cc this discussion to wine-devel. But who is interested 
can catch up from this mail.

On Saturday 26 October 2002 14:07, Eric Pouech wrote:
Could somebody answer/test if calling interrupt int 0x01 is allowed
from a win32 program in WinNT environment? I would pretty like to
know that!
  
   I don't think it is
 
  Should I write then a patch, which would deny calling of int 0x01 from
  win32 code when winver is NT?
  Would that be applied?

 the rule of thumb is: if there's a program which depends on this to be
 implemented, then yes patch will be applied
 otherwise, leave it as it is

Tough all safedisc programs depend on this, I have decided not to make an 
official patch. The reason is that additional info is needed for a proper 
fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an 
int 0x01 call. But it should be checked what exceptions are raised on 
different windows versions when int 0x01 is called. And maybe the same should 
be done with other interrupts.
It would be good if somebody could make that test program. Else I will keep 
the non proper fix.

   it was allowed on Win9x, and is used in this context IIRC as a ring 3
   to ring 0 transition code (how to create a cheap call gate)
 
  How good it would be if I could understand what you are speaking about :(
  But could you explain what a call gate is?
  If it is too long, then dont bother tough...

 I'll try to make it short
 context:
 - i386 have 4 levels of privilege = ring 3 (less privilege) up to ring
 0
 - certain operations are only allowed at ring 0 (or 1)
 - user code runs in ring 3
 - kernel code runs in ring 0 (to be exact, NT had been designed to have
 kernel in ring 0, and device drivers in ring 1, but this has been
 altered - some drivers run in ring 0 too)
 - you can always call into a less priviledged level (ring 0 = ring 3
 for example)
 - the other way around requires what is known as call gates (ring 0 for
 example defines the entry points in some way)
 - most of the interrupt handlers run in ring 0

 what the safedisc code was doing was:
 0/ code is running in ring 3
 1/ install an interrupt handler for division by zero (IIRC)
 2/ trigger the division
 3/ have the interrupt handler called, but this is done in ring 0, even
 if the code has been loaded from a user space program. here, in the
 interrupt handler, you can do any ring 0 operation you want

 that's why I called it a cheap call gate (no real call gate has been
 installed, and the code run in ring 0 isn't decided by the kernel but
 the app)

 NT doesn't allow this to run. step 1 is not allowed (only the kernel can
 decide to change an interrupt handler, which makes lots of sense)

Thanks for the detailed explanation.

And for completeness I will include here the explanation of Laurent Pinchart 
why a safedisc program calls int 0x01 :
 - the last attempt to detect a debugger uses int 0x01 (enter SMM/ICE mode),
 which checks if an external hardware emulator is connected to the
 processor. I haven't been able to understand what the code is supposed to
 do.

Regards
Zsolt






Re: interrupts in when in NT version

2002-10-26 Thread John K. Hohm
 Tough all safedisc programs depend on this, I have decided not to make an 
 official patch. The reason is that additional info is needed for a proper 
 fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an 
 int 0x01 call. But it should be checked what exceptions are raised on 
 different windows versions when int 0x01 is called. And maybe the same should 
 be done with other interrupts.
 It would be good if somebody could make that test program. Else I will keep 
 the non proper fix.

You may think me a rube, but I just made a test program that calls an arbitrary
interrupt and prints the exception information.  I don't set up any registers,
so perhaps it generates an exception when it ought not in some cases, but anyone
else is free to improve it.  Source and a VC6-compiled MSVCRT-using version,
along with results for all 255 interrupts on Windows XP Professional, is here: 

  http://petra.trnty.edu/~jhohm/intexcep.zip




Re: interrupts in when in NT version

2002-10-26 Thread Rizsanyi Zsolt
On Saturday 26 October 2002 17:36, John K. Hohm wrote:
  Tough all safedisc programs depend on this, I have decided not to make an
  official patch. The reason is that additional info is needed for a proper
  fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on
  an int 0x01 call. But it should be checked what exceptions are raised on
  different windows versions when int 0x01 is called. And maybe the same
  should be done with other interrupts.
  It would be good if somebody could make that test program. Else I will
  keep the non proper fix.

 You may think me a rube, but I just made a test program that calls an

What do you mean by rube? According to my dictionary rube means:
rube n.: AmE slang someone, usually from the country, who has no experience of 
other places and thinks in a simple way

I dont understand while would you be a rube?

 arbitrary interrupt and prints the exception information.  I don't set up
 any registers, so perhaps it generates an exception when it ought not in
 some cases, but anyone else is free to improve it.  Source and a
 VC6-compiled MSVCRT-using version, along with results for all 255
 interrupts on Windows XP Professional, is here:

   http://petra.trnty.edu/~jhohm/intexcep.zip

Thanks for your work. It proves my assumptions at least in the winXP case, and 
I assume it is the same in nt40.
It would be nice if somebody could run this program on a win9x system. (I only 
have win2k available here).

Thanks
Zsolt






Re: interrupts in when in NT version

2002-10-25 Thread Joerg Mayer
On Thu, Oct 24, 2002 at 12:26:15PM +0200, Zsolt Rizsanyi wrote:
 But the recent interrupt changes tend to cause cvs conflicts and to break it.
 This patch is supposed to work only if winver is nt40 so very probably this 
 applies only to NT.
...
 I would like if this could be fixed properly and that would work with the 
 safedisk patch, if thats possible.

and on 28 May 2002 18:58:51 -0700, Alexandre wrote:
Laurent Pinchart [EMAIL PROTECTED] writes:

 There are two patches in there. The first one sets a fault handler for the
 SharedUserData. This looks fine to me, and will probably be applied when
 memory/emulate.c will be applied.

It still isn't clear to me why you need a fault handler at all. You
could simply put the right data into it at allocation time.

 The second one has been written by Alexandre to fix the process suspension at
 creation time. Once again I'd like to hear from him to know what he doesn't
 like about the code, as he's the one who wrote it :-)

The main problem is that it isn't generic enough, it only applies to
the create process request but other requests have the same problem
and should be fixed too. I'll work on a more general solution.

I looks like the more general solution was never done due to time/lack of nagging
reasons?

  Ciao
 Jörg


--
Joerg Mayer  [EMAIL PROTECTED]
I found out that pro means instead of (as in proconsul). Now I know
what proactive means.




Re: interrupts in when in NT version

2002-10-25 Thread Alexandre Julliard
Joerg Mayer [EMAIL PROTECTED] writes:

 and on 28 May 2002 18:58:51 -0700, Alexandre wrote:
 The main problem is that it isn't generic enough, it only applies to
 the create process request but other requests have the same problem
 and should be fixed too. I'll work on a more general solution.
 
 I looks like the more general solution was never done due to time/lack of nagging
 reasons?

Well it's part of the finalize server protocol task that's supposed
to be done for 1.0. So it will get done eventually...

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: interrupts in when in NT version

2002-10-25 Thread Rizsanyi Zsolt
On Friday 25 October 2002 13:46, Joerg Mayer wrote:
 On Thu, Oct 24, 2002 at 12:26:15PM +0200, Zsolt Rizsanyi wrote:
  But the recent interrupt changes tend to cause cvs conflicts and to break
  it. This patch is supposed to work only if winver is nt40 so very
  probably this applies only to NT.

 ...

  I would like if this could be fixed properly and that would work with the
  safedisk patch, if thats possible.

 and on 28 May 2002 18:58:51 -0700, Alexandre wrote:
 Laurent Pinchart [EMAIL PROTECTED] writes:
  There are two patches in there. The first one sets a fault handler for
  the SharedUserData. This looks fine to me, and will probably be applied
  when memory/emulate.c will be applied.
 
 It still isn't clear to me why you need a fault handler at all. You
 could simply put the right data into it at allocation time.
 
  The second one has been written by Alexandre to fix the process
  suspension at creation time. Once again I'd like to hear from him to
  know what he doesn't like about the code, as he's the one who wrote it
  :-)
 
 The main problem is that it isn't generic enough, it only applies to
 the create process request but other requests have the same problem
 and should be fixed too. I'll work on a more general solution.

 I looks like the more general solution was never done due to time/lack of
 nagging reasons?


Yes. Alexandre has not yet did the proper fix for the problems on thread 
suspension.
I dont really know the reasons, but maybe it was the lack of nagging :)
I think I'm the only one who uses this safedisc patch, and I was not too loud 
about that.

But this (thread suspension) has nothing to do with interrupts.
As much as I know the int 0x01 is called by the program to test if it has a 
sane environment (check to see if the program is not debugged).

Could somebody answer/test if calling interrupt int 0x01 is allowed from a 
win32 program in WinNT environment? I would pretty like to know that!

Thanks
Zsolt




Re: interrupts in when in NT version

2002-10-25 Thread Eric Pouech
Rizsanyi Zsolt a écrit :
 
 Could somebody answer/test if calling interrupt int 0x01 is allowed from a
 win32 program in WinNT environment? I would pretty like to know that!
I don't think it is
it was allowed on Win9x, and is used in this context IIRC as a ring 3 to
ring 0 transition code (how to create a cheap call gate)
A+