Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Tue, 31 Aug 1999 09:40:41 +0200 (CEST) From: Federico Bianchi To: Emanuele Aliberti cc: cygwin AT sourceware DOT cygnus DOT com Subject: PE CRC et al. In-Reply-To: <19990831064509.78758.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [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: =================================================== !DISCLAIMER!: my e-mail reflects _my_own_ opinions! =================================================== -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com