PE CRC et al.

[Federico Bianchi <bianchi@www.arte.unipi.it>]

[CRC code for PE executables - needed for driver developement]

It used to be on the Virogen page, http://virogen.cjb.net, but this is no
more the case. I just sent Emanuele the appropriate file (I am not
posting it to the list because I don't like sending binaries unless
strictly necessary).

[hidden assumptions]

It actually happened a friend had a Tally laser printer driver which
didn't work under NT SP3 debug build because, as you DDKers know, the
latter _intentionally_ messes up registers and some memory locations which
were apparently crucial to the correct working of the driver itself (Tally
eventually updated it for other reasons, but this bug was not recorded on
their history log). Fact is, when you compile a class driver you are
effectively binding to another one; I have never tried it myself, but I
would not be surprised if NT managed to do this on the same CPU. And there
are even  lots of drivers bypassing HAL altogether (Matrox!)... In
general, you have to take in account some people are going to do
_EVERYTHING_ they can to squeeze up some more performance, even if this
means breaking the theoric system rules. To be fair, this is actually not
the case with non-DDK libraries such as Numega's, OSR's or BlueWaters' (to
mention but a few), because they are effectively shielding your code from
the core SPIs by providing their own ones.

[kernel debugging]

_AND_ there is the symbols issue. How are you going to do even the
plainest debugging without being able to resort to *KD, WinDBG or SoftICE?

Just to do assembly-level debuggin, you would need to:
- write a gcc symbols -> Microsoft DBG file converter (this is actually 
  not that difficult, testing being the troublesome part)
- context-switch between Microsoft/Intel-style assembler and AT&T-like GAS
  (or NASM, which is much more comfortable anyway) at any time

[C++]

And as soon as you enter even a single C++ function, there is the issue
with name mangling.

[Summary]

As you see, making a gcc-based DDK for NT is as daunting as it can be. I
like GCC a lot. I do like Cygwin (it is the only C/C++ compiler I have
been using in the latest three months). I do like NASM, both for its
(mostly) clean syntax and its flexibility (writing small Win32, Linux and
FreeBSD routines on a DOS machine and being able to use mostly the same
source with just a few conditionals is great). MSVC has lots of problems
(and an impressive floating point performance, to be fair), and MASM
quirks have passed into hacker folklore for a long, but when your code is
mostly dealing directly with Microsoft systems I think there is no
practical substitute to them.

Best regards to you all

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================


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