Re: [PATCH] Allow building of kernel32.dll with w32api

Casper Hornstrup <[email protected]>
Newsgroups gmane.comp.gnu.mingw.patches
Message-ID <[email protected]>
man, 2002-06-17 kl. 05:11 skrev Danny Smith:
> 
> ----- Original Message -----
> From: "Casper Hornstrup" <[email protected]>
> To: <[email protected]>
> Sent: Sunday, 16 June 2002 02:23
> Subject: [MinGW-patches] [PATCH] Allow building of kernel32.dll with
> w32api
> 
> 
> > This patch makes it possible to build a kernel32.dll by defining
> WINBASEAPI to not be attribute dllimport. The patch also moves a few
> structures that will be
> > shared between the SDK and DDK to a central location in order to avoid
> potential
> > conflicts when including headers from both developer kits at the same
> time.
> >
> >
> 
> I am not keen on this because, when possible, we attempt to put
> definitions where MS doc's say they are.
> The patch you propose may well be logical and harmless, but it sets a
> precedent for moving things around just to facilitate one project. That
> could soon get out of control.
> 

I understand and agree that definitions should be where they are
documented to be.

> Couldn't we "centralise" the troublesome definitions within current
> header locations (where MSDN docs say they are)  but protect with
> defines.
> 
> Danny

I'm finding more "shared" definitions every day and would hate to have
that many #ifdef's lying around. I will first try to just #include the
needed w32api header files from the DDK. The DDK will depend on w32api
anyway for the "base" definitions (basetsd.h, ntdef.h, etc.). That would
cause larger compile times, but I guess it does not matter so much when 
apple's precompiled header patch gets into gcc. If everything fails we
can try to centralize and protect definitions with #ifdef's.

Casper



_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.