DDK build result different from VS result

Discussion in 'Windows Vista Drivers' started by Hannes, Jan 28, 2005.

  1. Hannes

    Hannes Guest


    Due to the following post, I am trying to convert my VS.NET 2003 kernel
    driver project into a VS.NET 2003 makefile project, so I can compile using
    the DDK compiler, which seem safer and more supproted for kernel development.


    I have noticed, though, that my driver becomes about twice as large (500kB
    vs. 250kB) when built through the DDK compiler. What can cause this?

    I am using Mark Roddy's DDKBUILD utility, and I have carefully ported all
    the compiler flags from the VC project into this new makefile project.

    Now, if I, in my own makefile comment out the call to

    !INCLUDE $(NTMAKEENV)\makefile.def

    and instead write my own makefile, like this:

    !INCLUDE sources


    the driver file now becomes about half the size, 250kB. This is also the
    size I used to get through my old VS project (that was using the VS compiler).

    I have compared the flags sent to 'cl' by examining the two different
    buildfre_w2K_x86.log files generated by the DDK included makefile vs my own
    makefile. It appears that my own makefile passes exactly the flags that I
    intended, while the DDK included makefile passes an extra set of flags to the

    For instance, /G6 is passed, while I actually want /G7. So I end up with a
    warning that /G7 overrides /G6. This I can take, but how about all the other
    flags, can I not avoid all the "default" compiler flags and JUST use my own

    Also, I noticed how 'link' is sent a whole set of flags, EVEN WHEN I add
    in my sources file. Using my own makefile, I get exactly the flags I want
    passed on to the linker, and the outcome is, again, the smaller 250kB rather
    than 500kB.

    I am trying to use maximum optimization, global optimization, and optimize
    for speed, on both builds. All compiled versions of the driver seem to work,
    even though I have not yet tested them for speed.

    Perhaps a bunch of stuff is being stripped in one case, but not the other,
    not affecting the performance of the resulting driver?

    Is it expected for the 2000 FREE DDK build environment to generate larger
    files, or are there more options I can configure, to make it behave just like
    when I write my own makefile? I have studied the documentation for all the
    build macros available to makefile and sources, and I don't see any more that
    could affect my build result.

    Thansk, and let me know if you need more information!

    Any input appreciated,

    / Hannes.
    Hannes, Jan 28, 2005
    1. Advertisements

  2. USE_PDB=1

    After this, the PDB file size is no more impotant to anybody :)
    Maxim S. Shatskih, Jan 29, 2005
    1. Advertisements

  3. Hannes

    Mark Roddy Guest

    I'm confused. The only flags of interest with respect to
    compilation/linking of your driver are in the Sources file, not in the
    VC project file. That is th whole point of ddkbuild - to get your driver
    built using the standard settings from the ddk. So what flags are we
    talking about here?
    Then you are off on your own with an unsupported build process. This
    doesn't mean that your build process is wrong or faulty, it is just
    That would be the flags that Microsoft, for good or bad, has decided are
    the correct flags for compilation/linking of drivers.
    So how exactly are you setting the optimization flags? Better yet, why
    not just leave the flags alone and use the default settings in the ddk?
    Once again you seem to have conflicted goals here. You want to use the
    ddk toolset to get standard results, but you want to override all the
    settings from the toolset so that you can get non-standard results. The
    whole point of using the ddk toolset is to use standard tools with
    standard settings so that the ouput has a reasonable chance of working
    correctly, (ignoring source code defects.)

    Of course there are linker flags that are immune to whatever you set
    LINKER_FLAGS to. Search for LINKER_FLAGS in <ddkdir>\bin\makefile.new to
    get a better understanding of what is going on here. It ain't magic.

    I suggest that you strip all the crap out of your sources file, and
    unless there is some real need to worry about compilation/linking size
    and or speed optimizations, accept what you get.

    I generally worry about compiler and linker settings right after I am
    convinced that all software defects have been eliminated from the
    module, and that there are no algorithmic optimizations left to
    implement, which is to say I never worry about compiler and linker settings.

    Mark Roddy DDK MVP
    Windows 2003/XP/2000 Consulting
    Hollis Technology Solutions 603-321-1032
    Mark Roddy, Jan 29, 2005
  4. Hannes

    Hannes Guest

    I do not see any effect on the generated executable (.sys) file. Was I
    supposed to?
    I do, however, need the PDB file, for debugging post-release issues. This
    brought no change for that one either.

    / Hannes.
    Hannes, Jan 31, 2005
  5. Hannes

    Hannes Guest

    Hi Mark,

    Thanks for your comments. Let me try to clarify your questions below:

    For the past three-four years, I have developed this driver entirely using a
    VS project, and I have found a number of compiler and linker settings that
    have a good effect on our outcome. Now that I am starting a new VS project,
    this time using a VS makefile project and ddkbuild, I have made an attempt to
    translate all these settings (which have taken years to refine) into settings
    that now go entirely into the sources file. No more settings in VS, it's all
    in the sources file now.

    Ok, thanks. It's good to hear that. I was just making my own makefile to
    prove that my driver *CAN* fit into 250kB. I'm still puzzled why the
    supported ddk build makes it twice as big...

    These are my flags, and I wish they were the ONLY flags applied:

    USER_C_FLAGS=/nologo /Gz /GF /FD /EHsc /MT /QI0f /TP

    Performance is our highest priority with this driver, so I don't wanna take
    chances on weird build flags or twice as large .sys files....at least not
    without understanding what the differences are.

    We are running solely on Pentium 4 and Pentium M, so I certainly don't want
    to optimize using /G6 (which is Pentium 1-3 compliant) - so I don't
    understand why DDK enforces /G6...?

    Also the size of the output file worries me. We have a stable product that
    has been running for years, at 250kB. I want to understand why the file
    suddenly becomes 500kB, and I am also looking for some reasasurance that it's
    not gonna affect our performance.
    Thanks for that point. I thought using the DDK compiler was enough to be
    "supported", but if it also takes only using a subset of compiler settings
    and optimizations, I realize I am much more limited. It's hard to do real
    benchmarking on our product, why I am trying to optimize as far as I can
    based on the documentation of compiler and linker options.

    Thanks for all your input, it is highly appreciated.

    / Hannes.
    Hannes, Jan 31, 2005
  6. Hannes

    Hannes Guest

    Hi again,

    Thanks for the tip from Mark Roddy of looking through the included
    makefiles, to find out why certain compiler flags are added to my
    compilations. I have now stripped my sources file down significantly, and I
    am left with these few 'extras' in there:


    SOURCES=<list of my files>

    Can I consider my build environment "supported" at this point, or do I need
    to get rid of more flags?

    Also, I am looking at some flags passed to the linker, and I am wondering if
    these can cause problems to me?


    I want my build as optimized as possible, so seeing -debug in there worries
    me a little. The documentation is not clear on whether this will generate a
    less optimized driver?

    And - what is /functionpadmin:5? "Minimum Function Padding" ? It seems
    related to incremental linking, but the DDK also sends "INCREMENTAL:NO" to
    the linker, so this seems contradictory.

    Finally, I see
    being passed to the linker - I assume this is not an optional flag? (yes,
    the .pdb file indeed gets compressed on my file system).

    Again, any input appreciated.


    / Hannes.

    PS. The output spm.sys file is still 500kB, twice the size of the VS build
    result of 250kB...
    Hannes, Feb 1, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.