[Development] Header file cleanups

[BRM]

> From: Joerg Bornemann <joerg.bornemann at nokia.com>

>On 01/03/2012 16:43, ext BRM wrote:
>
>> For years, Microsoft advocated the use of simply including the "windows.h" header file. However, this ultimately led to a very very big problem - one that ended up with circular dependencies between user space and kernel space. It also cost them a lot of money to correct in their own code - having first developed a version of Windows that while it works was so poorly performing they couldn't deliver it at a cost of 3 years of development, only to throw it out and start over with major efforts towards reducing the dependency levels and another 3 years of development to produce what because Windows Vista, and follow on to Windows 7 at substantially less work. As a result, they also no longer advocate the use of 'windows.h' (they seem to have removed it from the newer SDKs), and the header levels have broken down. The new structure they have is far more resilient, leaner, and easier to work with. (Note, this was just one of the many issues they had during
>>   the development of what became Vista. But it was a big issue.)
>
>Just out of interest: what is 
this "new header structure" you're talking about?


It's been a while since I've really hit the issue hard. I have always been one for simplicity and directness in code - and Windows.h (while simple) is certainly not direct in that it results in the inclusion of every API within Windows. And yes, while you can manage that some by use of a few pragma defines,  you can do even better by simply using only the required headers.

The issue with the inclusion of everything under the sun is that it encourages mixing of APIs in ways that will make a mess out of the dependency structure for the applications using it - which is exactly what MS ran into - with 1500+ dependency levels and circular dependencies between Kernel Land and User Space. They're still cleaning up the mess at the higher levels, but only with projects like MinWin were they able to do it at the lower levels through many man months at that. After 6 years, it's still an ongoing effort to continue reducing it.

So why start a situation that could lead to that kind of interdependencies within Qt or Qt applications? The effort has been put into modularize Qt so that developer's don't need to link (or even build) every library Qt provides. The use of a single header - like Windows.h or gtk/gtk.h - to get the whole API would only go against those efforts, and before you know it there will be various libraries that will have interdependencies that we didn't want. Yes, we might be able to catch that in the various builds we do, the reviews, etc; but it only increases the requirements that we have to be vigilant about catching such things. Why make extra work for ourselves?

As Qt grows - and I'm sure it will continue growing in size - why not manage it in a way that can further that growth instead of requiring us to be extremely vigilant about protecting the modularization and abilities that brings? Let's make it easy to minimize the dependencies; and easy and clear to maintain.

>AFAICS I'm still asked
 to include windows.h even the documentation additionally tells me where
 a function is declared.

That wasn't always the case.

They've actually done a great job since they started the effort to what because Vista in making it clearer about what you need to include if you don't want to use Windows.h. At one point, all MSDN would say was "Header: Windows.h"; now you can find out that its in WinDef.h, WTypes.h, WinBase,h or wherever it is actually declared and you can easily get to the use of minimal headers.

$0.02

Ben