__fastcall functions in a static lib, cant be called from managed code ??

[andrea catto']

I have this giant library, it's static and it's all compiled in __fastcall
fashion.
I can not call any of those functions from winforms...
even doing a wrapper off the main class, I still cant call it....
how do I overcome this issue ?

 

[cody]

What about

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

 

[andrea catto']

I hear you,
the problem is.
for most of us developers in transition with a bunch of code/legacy.....

we are not encouraged to migrate because there's WAY too much to do to
migrate/migrane !!!

as far as I heard it's possible to do this transition smoothly and
transparently, with IJW, but in my case it's just marketing buzz... it's
more like IJDW (it just doesn't work).

in my current programs,
I only need to #include "mylib.h", add the static.lib to the project
settings and I finally call the damn function.

What about

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

I have this giant library, it's static and it's all compiled in __fastcall
fashion.
I can not call any of those functions from winforms...
even doing a wrapper off the main class, I still cant call it....
how do I overcome this issue ?

 

[Ronald Laeremans [MSFT]]

The fastcall calling convention is not supported by the CLR. If you have
source for the library the easiest thing to do is to recompile it with a
different calling convention.

Ronald Laeremans
Visual C++ team

I hear you,
the problem is.
for most of us developers in transition with a bunch of code/legacy.....

we are not encouraged to migrate because there's WAY too much to do to
migrate/migrane !!!

as far as I heard it's possible to do this transition smoothly and
transparently, with IJW, but in my case it's just marketing buzz... it's
more like IJDW (it just doesn't work).

in my current programs,
I only need to #include "mylib.h", add the static.lib to the project
settings and I finally call the damn function.

What about

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

I have this giant library, it's static and it's all compiled in __fastcall
fashion.
I can not call any of those functions from winforms...
even doing a wrapper off the main class, I still cant call it....
how do I overcome this issue ?

 

[cody]

The fastcall calling convention is not supported by the CLR. If you have

source for the library the easiest thing to do is to recompile it with a
different calling convention.

So what is that in your opinion:

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

a placebo?

 

[andrea catto']

if it is not, IT SUCKS,......
I am a Microsoft lover myself........
but. this totally susks...
IJW is bs then...

The fastcall calling convention is not supported by the CLR. If you have
source for the library the easiest thing to do is to recompile it with a
different calling convention.

Ronald Laeremans
Visual C++ team

I hear you,
the problem is.
for most of us developers in transition with a bunch of code/legacy.....

we are not encouraged to migrate because there's WAY too much to do to
migrate/migrane !!!

as far as I heard it's possible to do this transition smoothly and
transparently, with IJW, but in my case it's just marketing buzz... it's
more like IJDW (it just doesn't work).

in my current programs,
I only need to #include "mylib.h", add the static.lib to the project
settings and I finally call the damn function.

What about

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
I have this giant library, it's static and it's all compiled in __fastcall
fashion.
I can not call any of those functions from winforms...
even doing a wrapper off the main class, I still cant call it....
how do I overcome this issue ?

 

[andrea catto']

well the problem is that there is a HUGE amount of merely static libraries
that have been compiled in a __fastcall fashion.
this is my case....
and if I have to sit here and recompile, provided I am lucky eough to have
the code, or create dlls....
it WON'T WORK !!!
sorry to use capital letters, but this is a huge inconveniece that Microsoft
has to overcome instead of kicking programmets in the butt, __fastcall us a
Microsoft invention, they should suppore it somehow....
__fastcall afterall is nothing but a way to pass arguments to the functions,
if I am not mistaken by using registers instead of the stack.
it's simple assembler that I can even write.

The fastcall calling convention is not supported by the CLR. If you have
source for the library the easiest thing to do is to recompile it with a
different calling convention.

So what is that in your opinion:

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

a placebo?

 

[Ronald Laeremans [MSFT]]

From the "CallingConvention Enumeration" help topic in the documentation:

FastCall This calling convention is not supported.


<http://msdn.microsoft.com/library/d...nteropservicescallingconventionclasstopic.asp>

Ronald

The fastcall calling convention is not supported by the CLR. If you have
source for the library the easiest thing to do is to recompile it with a
different calling convention.

So what is that in your opinion:

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

a placebo?

 

[Ronald Laeremans [MSFT]]

So am I safe in assuming that you do not have access to source for this
library? In that case the best you can do is to write a wrapper for this
function.

Whereas fastcall used to have significant benefits several years ago, on
modern architectures it does not tend to be a significant performance win
and marking all functions as fastcall might very well make the application
slower overall. Which is the main reason this calling convention is not
supported in the CLR.

Ronald

if it is not, IT SUCKS,......
I am a Microsoft lover myself........
but. this totally susks...
IJW is bs then...

The fastcall calling convention is not supported by the CLR. If you have
source for the library the easiest thing to do is to recompile it with a
different calling convention.

Ronald Laeremans
Visual C++ team

I hear you,
the problem is.
for most of us developers in transition with a bunch of
code/legacy.....

we are not encouraged to migrate because there's WAY too much to do to
migrate/migrane !!!

as far as I heard it's possible to do this transition smoothly and
transparently, with IJW, but in my case it's just marketing buzz...
it's
more like IJDW (it just doesn't work).

in my current programs,
I only need to #include "mylib.h", add the static.lib to the project
settings and I finally call the damn function.


What about

[DllImport("test.dll", CallingConvention=CallingConvention.FastCall)]

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
I have this giant library, it's static and it's all compiled in
__fastcall
fashion.
I can not call any of those functions from winforms...
even doing a wrapper off the main class, I still cant call it....
how do I overcome this issue ?

 

[cody]

So am I safe in assuming that you do not have access to source for this

library? In that case the best you can do is to write a wrapper for this
function.

Whereas fastcall used to have significant benefits several years ago, on
modern architectures it does not tend to be a significant performance win
and marking all functions as fastcall might very well make the application
slower overall. Which is the main reason this calling convention is not
supported in the CLR.

So why is there a FastCall in the enum?

 

[Ronald Laeremans [MSFT]]

Because it is a valid calling convention. Initially there was some thinking
it might be supported in a future version, but that looks very unlikely now.

In another part of the thread I posted the documentation that stated it was
not supported.

Ronald

So am I safe in assuming that you do not have access to source for this
library? In that case the best you can do is to write a wrapper for this
function.

Whereas fastcall used to have significant benefits several years ago, on
modern architectures it does not tend to be a significant performance win
and marking all functions as fastcall might very well make the
application
slower overall. Which is the main reason this calling convention is not
supported in the CLR.

So why is there a FastCall in the enum?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk