Windows Driver Kit (WDK) Documentation Blog

Posting a CHM for each doc release would be helpful to many developers.  Please reconsider the current policy.

Only releasing a CHM version at major milestones is one thing, but what you effectively mean is that you WITHDRAW the CHM version at the next minor update after a major milestone. It's beyond me why you sometimes release in the dreadful HXS format but not in the friendly and useful CHM format, but removing the latest CHM version at the same time is a great disservice to the community. At least you should put up a warning that the CHM will be removed after a while.

If for some reason you can't update the CHM version at each publication, could you not at least leave the last published CHM available? Slightly out of date usable documentation is better than up to date unusable documentation ...

Hi,

I'm sorry to start blabbering here instead of sending this to the correct email address, but I have been trying for some time now to find a way of submitting this bug on the WDK website and failed to do so.

Anyway, we did notice a very undesirable default behavior in the WDKs in that

LINK_TIME_CODE_GENERATION=1

is being set inside the makefile.new for *any* WIN64 build. This is done unless NTTESTENV is set to something else but 0. If, however, NTTESTENV is set, other side-conditions apply and since we don't want to modify the WDK itself every time a new one is released, it would be very nice to be able to override this behavior from the SOURCES file somehow.

The problem we have with this is, that previously we were able to compile static libraries and give them to licensees of our product. Now the x64 version is giving us headaches because the makefile.new literally enforces /LTCG even though we want to make sure it's not enabled (needless to say our product is not OpenSource). On the customer's end this shows as them being unable to link, because the LTCG requires the source to be "in place" (actually in the very same path as on the build machine) for "optimization" purposes.

Thanks for consideration.

As for the CHM discussion, we also find CHM more useful in general because it's "monolithic" (or differently put "self-contained").