Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

COD listing fails for AMD64 under DDK 7600??

Tom_UdaleTom_Udale Member Posts: 12

Greetings,

I am feeling a little dense here but I cannot get a cod listing for my 64 bit driver builds. I am using

USER_C_FLAGS=$(USER_C_FLAGS) /Fa$(O)\ /FAcs

It works fine for 32 bit builds but there is nothing for 64 bit builds. I looked in the log files and it is certainly in there.

Does the 64 bit compiler not respond to FA?

Best,

Tom

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,836

    I hate to answer a question with a question... but here goes:
     
    Why are you using the Windows 7600 DDK and not a newer version?
     
    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,715
    via Email
    Tom_Udale wrote:
    > I am feeling a little dense here but I cannot get a cod listing for my 64 bit driver builds. I am using
    >
    > USER_C_FLAGS=$(USER_C_FLAGS) /Fa$(O)\ /FAcs
    >
    > It works fine for 32 bit builds but there is nothing for 64 bit builds. I looked in the log files and it is certainly in there.
    >
    > Does the 64 bit compiler not respond to FA?

    Greetings, Tom.  Yes, it absolutely does.  I just added your line to one
    of my 7600 projects and it produced .cod files as expected.

    Double-check that you have the backslash following the $O.  Without
    that, the files will all get written as amd64.cod.

    By the way, if you just have a one-shot need for the .cod files, the
    easiest way is to use the magic CL environment variable:
        set CL=/FAsc
        build

    The contents of CL are appended to every compiler command line.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,715
    via Email
    Peter_Viscarola wrote:
    > I hate to answer a question with a question... but here goes:
    >
    > Why are you using the Windows 7600 DDK and not a newer version?

    I've worked for Tom in the past.  He has an ENORMOUS driver with a huge
    legacy burden that literally dates back to the 20th Century. They have a
    highly customized build environment wrapped around "build".  Every DDK
    upgrade is a huge pain in the ass for them, and the transition to Visual
    Studio is going to be extra painful.  He'll come around eventually...

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Jeffrey_Tippet_[MSFT]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 456

    I'm not sure about the DDK build environment, but our internal equivalent had an nmake target for this. So to get the assembler input for a source file named foo.c, you could type nmake.cmd foo.cod. (If your envionment doesn't have nmake.cmd, try nmake.exe.)

    Also useful: a target for the output of the preprocessor. nmake.cmd foo.pp

  • Tom_UdaleTom_Udale Member Posts: 12

    Hi Peter,

    Tim has it right. The main issue is XP drivers. My understanding is that 7600 is the last DDK that permits you to build for XP targets (at least that is what Wikipedia tells me :). My customers are almost all academic research labs and unfortunately the upgrade from XP usually involves a number of hardware upgrades as well (mostly revolving around 3rd party devices with only 32 bit drivers) which they don't usually have the money for after the initial system purchase, so I tend to not throw them under the bus if at all possible.

    I am indeed sorely tempted by the KMDF (we are still writing directly to WDM) and building drivers in Visual Studio. But indeed I ended up writing a rather massive build environment around the DDK/DDKBUILD and VS2010 because the VS2010 batch build was so broken. So beyond coming to terms with leaving some customers behind, there is the issue of reworking the build environment for 83 separate projects, 28 of which are drivers. Sigh... we will get there of course but it is a bit of a process.

    Best,

    Tom

  • Tom_UdaleTom_Udale Member Posts: 12

    Hi Tim,

    I will check out the \ and maybe try the environment variable (because indeed I was just looking at how clever the compiler was regarding array indexing via [] as compared to pointers). Thanks for the tips and sanity check.

    Best,

    Tom

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,836

    My understanding is that 7600 is the last DDK that permits you to build for XP targets

    That is true. However, it’s been my experience that you can use the latest WDK, set the target to Win7, and the resultant drivers will work great. Just, FYI. So you may be stuck with supporting XP systems, but you need not be saddled with an ancient build environment forever.

    Now... the whole big infrastructure thing? THAT is a major thing to overcome.

    Best of luck!

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tom_UdaleTom_Udale Member Posts: 12

    Hi Peter,

    It is funny you should say that because as I have been messing with this FAsc business (no luck on that but no reportable results yet) I noticed that I have been doing exactly this the whole time - building for the Win7 target and installing on XP. And indeed so far no problems. What a knucklehead to a) not realize/remember that and b) not realize the implications. So I guess here I come WDK 8 or, gasp, 10 even!

    Best,

    Tom

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!