Using build.exe to compile application against __cdecl symbol dll.

Discussion in 'Windows Vista Drivers' started by Vladimir Vassilev, Mar 18, 2009.

  1. Hello,

    I am working on a project involving both driver and user space applications.
    We use the 6001.18002 WinDDK build environment.

    I am trying to compile apllication which is linked to a third party dll
    compiled with __cdecl default calling convention. The header file does not
    have explicit __cdecl definitions for the symbols and since the default
    build.exe calling convention is __stdcall there is a conflict. The /Gz option
    is added by default to the compiler options and adding
    USER_C_FLAGS=$(USER_C_FLAGS) /Gd to the sources file results in a error
    stating incompatible options.

    My question is how to tell the build.exe tool to not use the /Gz as default
    compilation option?
     
    Vladimir Vassilev, Mar 18, 2009
    #1
    1. Advertisements

  2. Vladimir Vassilev

    Pavel A. Guest

    Better add __cdecl's in the .h file.

    -- pa
     
    Pavel A., Mar 18, 2009
    #2
    1. Advertisements

  3. I would edit the DLL's header to specify explicit calling convention, this is always a good idea.
     
    Maxim S. Shatskih, Mar 18, 2009
    #3
  4. Vladimir Vassilev

    Tim Roberts Guest

    Pavel and Maxim are both correct. The RIGHT solution is to add __cdecl to
    the declarations in header file. Anything else is just asking for trouble.
    And you should be able to convince yourself that doing so will not harm
    ANYTHING, as long as the DLL really was compiled __cdecl.

    Having said that, however, it is possible to change the default by adding
    this to your sources file:
    386_STDCALL=0
    "0" means __cdecl, "1" means __stdcall, "2" means __fastcall.
     
    Tim Roberts, Mar 19, 2009
    #4
  5. Vladimir Vassilev

    Pavel A. Guest

    Tim Roberts wrote:
    ..........
    IIRC, this option was intended for systems like WinCE (CEPC) that use
    cdecl convention.


    -- pa
     
    Pavel A., Mar 19, 2009
    #5
  6. Vladimir Vassilev

    vl_vassilev Guest

    Yes this is the answer I was looking for. I found it by examining the
    makefile.def but it is usefull to have it available in this forum. In
    the cases where you have third party library compiled with .NET which
    uses __cdecl as default calling convention (in my case this was Qt)
    you would not go editing the Qt header files adding __cdecl so this is
    a absolutely necessary option and I do not see why MSDN does not have
    it documented.

    Vladimir
     
    vl_vassilev, Mar 20, 2009
    #6
  7. you would not go editing the Qt header files adding __cdecl so this is

    You _would_ do this, and it is even better to resumbit the edits back to Qt maintainers.

    The proper Windows DLL's header file must use the macro like WINQTAPI or so, explicitly defined either to __cdecl or to __stdcall by some project option. This gives the flexibility of building Qt itself both with __cdecl or __stdcall, as also the user's flexibility (the user just uses the WINQTAPI value which was defined when building a DLL).

    For UNIX builds, WINQTAPI should be defined to nothing.
     
    Maxim S. Shatskih, Mar 20, 2009
    #7
  8. Vladimir Vassilev

    Tim Roberts Guest

    And why not? *I* certainly would. I would be repairing Apple's bug. Do
    you think they are going hunt you down if you do this?
     
    Tim Roberts, Mar 22, 2009
    #8
    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.