Changing calling convention

Hi,
I need to change the calling convention of the DDK compiler. It defaults to the option /Gz (stdcall calling convention) when I run build on my driver. Even when I try to put /Gd (cdecl calling convention) option in my sources file, I am not able to override the /Gz option and the compiler errors out with this:
cl : error D2016 : ‘/Gd’ and ‘/Gz’ command-line options are incompatible

Is there a way to override this?
TIA!

On Jun 15, 2007, at 1:21 PM, xxxxx@intel.com wrote:

Hi,
I need to change the calling convention of the DDK compiler. It
defaults to the option /Gz (stdcall calling convention) when I run
build on my driver. Even when I try to put /Gd (cdecl calling
convention) option in my sources file, I am not able to override
the /Gz option and the compiler errors out with this:
cl : error D2016 : ‘/Gd’ and ‘/Gz’ command-line options are
incompatible

Is there a way to override this?
TIA!

If you’re exporting functions, it’s easiest to just decorate them
with the calling convention you want, like so:

int __cdecl f() {}

Will that work for you?

-sd

No unfortunately I am inheriting some thousands of functions and I can’t go around changing all of them.

Well, actually you can … but it will take some work to get there …
unless you don’t have the source in which case you’re pretty well SOL. E
ven if you do manage to compile, you still have to link your driver via the
DDK, which likely the linker will barf when you attempt to link to the
DDK.libraries.

Just curious, but where did this chorus of thousands of functions come from?


The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
> No unfortunately I am inheriting some thousands of functions and I can’t
> go around changing all of them.
>

I’d be inclined to use a macro to fix it. Can you add a macro similar
to NTSYSAPI in the ddk headers? Could be probably be done pretty
quickly with a little perll/ruby/etc script and a creative regex or two.

I thought there was a way to set calling convention via a supported
build macro - look through makefile.new and see if you see one.

Just remember that the WDK defaults to stdcall, so you could easily
run into trouble if you try to force it to cdecl. It might work, but
I wouldn’t recommend it.

-sd

On Jun 15, 2007, at 1:27 PM, xxxxx@intel.com wrote:

No unfortunately I am inheriting some thousands of functions and I
can’t go around changing all of them.


Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Aaaah, found it! Thanks to Steve, makefile.new has a xxx_STDCALL=0 (xxx = MSC/386/ etc.) and 0 = cdecl, 1 = stdcall.

BTW, to answers Gary’s question, I don’t have to link to the DDK libraries as I am writing a driver that uses the DDK compiler but runs on a different platform.

Do not do this. All kernel’s functions are __stdcall.

So, instead, declare your functions as __cdecl explicitly.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi,
> I need to change the calling convention of the DDK compiler. It defaults to
the option /Gz (stdcall calling convention) when I run build on my driver. Even
when I try to put /Gd (cdecl calling convention) option in my sources file, I
am not able to override the /Gz option and the compiler errors out with this:
> cl : error D2016 : ‘/Gd’ and ‘/Gz’ command-line options are incompatible
>
> Is there a way to override this?
> TIA!
>

> All kernel’s functions are __stdcall.

Well, actually there are some kernel exports that use _fastcall (for example, IofCallDriver()), but, in this context, it just does not matter - I just wonder why the OP may want to use _cdecl in a Windows driver…

Anton Bassov

xxxxx@hotmail.com wrote:

> All kernel’s functions are __stdcall.
>

Well, actually there are some kernel exports that use _fastcall (for example, IofCallDriver()), but, in this context, it just does not matter - I just wonder why the OP may want to use _cdecl in a Windows driver…

I believe that he said he was interfacing to a large existing library
that he did not control. He also said that his target was not really a
Windows driver; he was using the DDK and the build environment to build
a binary for somewhere else.

There is a standard “sources” switch to select this, as he discovered.
Almost all of the DDK headers have the appropriate declarations to force
the right calling sequence, so he shouldn’t really have any trouble,
regardless of the /G compiler switch.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> He also said that his target was not really a Windows driver;

Actually, I just missed this part - the OP did not mention it in his original post. However, at this point one more question arises - assuming that his sources get successfully compiled into .obj files, what is the OP going to do when it comes to linking these .obj files into a final binary??? Let’s face it - DDK/WDK is meant to be used for building software that runs under Windows NT. Therefore, a binary that it produces is going to be in PE format - although the particular flavour of it depends on TARGETTYPE that is specified in the ‘sources’ file, still it is invariably going to be PE file. Is his target platform going to recognize it???

Anton Bassov