Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sourceware.cygnus.com
Message-ID: <19990831064509.78758.qmail@hotmail.com>
From: "Emanuele Aliberti" <ealiberti@hotmail.com>
To: bianchi@pc-arte2.arte.unipi.it, ealiberti@hotmail.com
Cc: cygwin@sourceware.cygnus.com
Subject: Re: kernel mode debugging
Date: Tue, 31 Aug 1999 08:45:08 CEST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

[native applications with gcc/win32]
>Don't think so. At least not in the beta 20.1 I have. And the CRC used is
>theoretically proprietary (though I have seen at least a - virus? - guy
>presenting code to implement it).

Can you send me a reference to get that pseudo-CRC code?

[kernel debugging]
>While in kernel mode, you must also consider that there are even drivers
>who "know" they can safely use some registers and memory locations (i.e.,
>they neither save nor restore them) because of their class mode
>counterparts being written with MS C/C++. This is mostly what I was
>thinking about when mentioning hidden assumptions.

That seems a bit risky, even for MS. I know the executive exports many data 
symbols, but I always assumed they are read-only for thirdy party modules. 
About register, perhaps you saw a __fastcall in the debugger, and that seems 
exactly a piece of code that does NOT save/restore registers (at least that 
was my feeling the first time I met it). I don't belive your assertion be 
true: how could the SMP kernel cope with the expected intricacies such a 
piece of code has when dealing with synchronization, if it could only place 
its trust in the VC++ compiler, which has a static view of the system?

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com