Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 9 Jan 2002 16:47:18 +0300 From: egor duda X-Mailer: The Bat! (v1.53 RC/4) Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <66149490876.20020109164718@logos-m.ru> To: Jean le Roux CC: egor duda Subject: Re: w32api header problems In-Reply-To: <20020109133833.A20443@infosat.net> References: <20020109115348 DOT A14411 AT infosat DOT net> <67136319166 DOT 20020109130747 AT logos-m DOT ru> <20020109133833 DOT A20443 AT infosat DOT net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Wednesday, 09 January, 2002 Jean le Roux jean AT infosat DOT net wrote: JlR> On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: >> Hi! >> >> Wednesday, 09 January, 2002 Jean le Roux jean AT infosat DOT net wrote: >> >> JlR> I need to include /usr/include/w32api/winbase.h in order to use the >> JlR> GetVolumeInformation(...) system call under windows. >> >> JlR> However, as i metioned in an earlier mail, DWORD seems to not be >> JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems >> JlR> the whole include chain is a bit funny.. there are lots of >> JlR> inter-dependencies which are not satisfied. >> >> JlR> Does anyone have any words of wisdom to make life a little easier, or >> JlR> do I simply have to test for, and include, all the headers in w32api ? >> >> you ought to >> >> #include >> JlR> I've done this but seems to leave my code in a tangle :) JlR> I suddenly have parse errors in my own header files, on normal JlR> function declerations. I can only deduce that windows.h is leaving an JlR> open ifdef or has unterminated strings or something silly. it's easy to find out what the reason is. gcc has a very useful option '--save-temps'. it instructs preprocessor, compiler and assembler to leave their temporary files in place, so if you compiling, say, zzz.c, you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- output of compiler) and zzz.o (compiled binary object). You want to look into zzz.i it shows what your source file turns into, and it's almost always easy to see why. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/