qt patch for winnt.h
Thu Jul 25 15:00:00 GMT 2002
> > >Perhaps you would prefer this better. I changed the ifdef to be
> > >feature-centric as opposed to project-centric. Perhaps this is a
> > >more to your liking?
> > I don't understand why the project needs a non-standard definition for
> > HANDLE unless they are using it in some other context than the Windows
> > one. It is defined as a void * in my MSVC headers so why would
> > anyone try to use anything else?
> qt is a multiplatform framework and they defines HANDLE different on
> (the sample code is from qt-3, but qt-2 uses the same strategy).
> In short the windows, mac, and qt embedded releases uses "void *" the x11
> release uses "ulong"
> // "handle" type for system objects. Documented as \internal in
> // qapplication.cpp
> #if defined(Q_WS_MAC)
> typedef void * HANDLE;
> #elif defined(Q_WS_WIN)
> typedef void *HANDLE;
> #elif defined(Q_WS_X11)
> typedef unsigned long HANDLE;
> // qt embedded
> #elif defined(Q_WS_QWS)
> typedef void * HANDLE;
> The problem is now, that we are compiling under Q_WS_X11, which defines
> as ulong, but we are using the w32api too, which defines HANDLE as void *
> (because we are using some native win32 functions), so we have the choose.
> tried the void * definition, but in the X11 context this results many
> problems, which produces very bad compatibility problems with the original
> source, so I've choosed the x11 handle context, which causes the know
> with the w32api winnt.h header. So we patched the winnt header, which
> much less headache :-)
> > I do prefer feature-centric ifdefs, but I don't think that adding this
> > particular definition of HANDLE to the windows headers makes sense.
> I think too, but you have another solution yet. :-)
I would suggest adding the patch for winnt.h to the source distribution for
qt and let the user apply it themselves if they wish to compile KDE on their
systems. If necessary we can add a configure check to ensure the patch has
been applied (and remind the user to do it if it hasn't been). This step
should be documented in the appropriate README, of course. There is
currently a similar check in place to ensure the user is using a compatible
version of libtool.
Chris asked the question why are we using a mixed Cygwin/X and native
Windows environment. One example of where this is necessary is in a Cygwin
specific extension to KDE which shows the Windows drives in the KDE file
dialog and Konqueror. This code needs to get a list of drives on the system,
however a readdir on /cygdrive only shows the list of drives with disks
currently in them (i.e. removable drives without disks don't show up).
Therefore we use GetLogicalDriveStrings in the code and include the
windows.h header, as well as various KDE headers, which in turn include Qt
headers with the conflicting definition of HANDLE. There are other instances
as well, where we have written native implementations for certain Qt
More information about the Cygwin-patches