New header winternl.h

[Patrik Stridvall]

> On Sun, 8 Sep 2002, Jürgen Schmied wrote:
> 
> >
> > > And do what?
> > > As I said above wintrnl.h can't include ntddk.h.
> > >
> > > Of course we can just include it as it is and don't use it...
> > I would do nothing as long as nobody needs it. There are 
> many *.h files
> > in the SDK that we don't have and nobody missed them till today.
> 
> Missing headers are making the lives of Winelib users pretty hard: the
> first time they try to compile their application they get tons of
> errors. They first wonder what they are doing wrong, then why 
> Wine does
> things differently from Windows, is there a hidden reason, 
> and then how
> the hell they are going to fix the headers and their messy 
> dependencies
> and whether they should not rather completely give up.

Fully agreed. Every header that it missing or wrong 
(even if fixing it is trivial) is a potential:
"Sorry boss, I tried to compile our application with WineLib
but it didn't work. So we can't port our applications using
WineLib.".

> Now, I'm not saying we should spend all our time trying to 
> make sure our
> headers are perfect rather than improving binary emulation. As with
> everything this is a question of balance.

I have being planning a long time to write a Perl script that compares
the Microsoft SDK headers with the Wine headers. I just haven't got
around to do it... So don't hold your breath.

> Now concerning this header, since it's so new (and quite useless) it
> certainly isn't going to be a problem soon and as you pointed out we
> definitely have other header issues to tackle first. Still if we can
> find an easy nice solution, let's go for it (unfortunately that does
> not appear to be the case).

The easy solution is to include the header just as I have submitted it
and not use it at all or rather postponing the problem of using it or not
to the future. If it exists somebody might get some ideas, some day...

Note that you can use it as long as you don't include ntdef.h or ntddk.h
as well so the non-core DLLs should be able to use it without any problem.

Nether the less I would strongly advise that the non-core DLLs doesn't
use it either unless it REALLY, REALLY, REALLY must...