MSVCRT calling convention issue

While debugging a game which only installs if we use the windows msvcrt, I have identified the problem but dont know how to fix it!

The problem revolves around the function MSVCRT_type_info_raw_name. This is
defined as stdcall, but disassembling the windows version, it clearly shows
use of a calling convention I had never heard of, 'thiscall'. According to
the MSDN, thiscall is stdcall BUT the 'this' pointer on x86 machines is stored
in the ECX register.

How can we fix this?

My thought: Change the definition to not take a ptr arg, and define a local,
this as being in the ECX register, but (a) I dont know how to do this, and
(b) is not a solution for winelib applications.

For now I can continue having put the msvcrt.dll from another machine in, but
it would be nice to solve this issue. I'd also guess it affects more than just
that one function.

Regards,
Jason

[Uwe Bonnes]

> > > > > "us" == us   writes:

us> While debugging a game which only installs if we use the windows
    us> msvcrt, I have identified the problem but dont know how to fix it!
    us> The problem revolves around the function
    us> MSVCRT_type_info_raw_name. This is defined as stdcall, but
    us> disassembling the windows version, it clearly shows use of a calling
    us> convention I had never heard of, 'thiscall'. According to the MSDN,
    us> thiscall is stdcall BUT the 'this' pointer on x86 machines is stored
    us> in the ECX register.

us> How can we fix this?

us> My thought: Change the definition to not take a ptr arg, and define
    us> a local, this as being in the ECX register, but (a) I dont know how
    us> to do this, and (b) is not a solution for winelib applications.

us> For now I can continue having put the msvcrt.dll from another
    us> machine in, but it would be nice to solve this issue. I'd also guess
    us> it affects more than just that one function.

We have the -register adder in the spec file. Look at e.g. how
__CxxFrameHandler is defined in msvcrt.spec and implemented in
dlls/msvcrt/cppexcept.c.

Great, I also noticed an error in some function of the MSVCRT_type_ group of
calls with Altera's Quartus package, but couldn't figure out...

Bye

> > The problem revolves around the function
> > MSVCRT_type_info_raw_name. This is defined as stdcall, but
> > disassembling the windows version, it clearly shows use of a calling
> > convention I had never heard of, 'thiscall'. According to the MSDN,
> > thiscall is stdcall BUT the 'this' pointer on x86 machines is stored
> > in the ECX register.
> We have the -register adder in the spec file. Look at e.g. how
> __CxxFrameHandler is defined in msvcrt.spec and implemented in
> dlls/msvcrt/cppexcept.c.

Thanks Uwe - I took a look, but cannot see what this actually does
(nor how to use it). It appears the spec entry means we end up with
an extra layer of indirection, but I really cant see how else it works!

Regards,
Jason

[Uwe Bonnes]

> > > > > "us" == us   writes:

>>> The problem revolves around the function
    >>> MSVCRT_type_info_raw_name. This is defined as stdcall, but
    >>> disassembling the windows version, it clearly shows use of a calling
    >>> convention I had never heard of, 'thiscall'. According to the MSDN,
    >>> thiscall is stdcall BUT the 'this' pointer on x86 machines is stored
    >>> in the ECX register.

>> We have the -register adder in the spec file. Look at e.g. how
    >> __CxxFrameHandler is defined in msvcrt.spec and implemented in
    >> dlls/msvcrt/cppexcept.c.

us> Thanks Uwe - I took a look, but cannot see what this actually does
    us> (nor how to use it). It appears the spec entry means we end up with
    us> an extra layer of indirection, but I really cant see how else it
    us> works!

Have a look at winebuild.man.

All the occurances of type_info should be replaces like in the patch for
MSVCRT_type_info_raw_name below. I am not sure if we need to add the -i386
flag.

Will you do the cleanup and submit the more complete patch?

Bye

[Uwe Bonnes]

> > > > > "Uwe" == Uwe Bonnes  writes:
> > > > > "us" == us   writes:

...

us> Thanks Uwe - I took a look, but cannot see what this actually does
    us> (nor how to use it). It appears the spec entry means we end up with
    us> an extra layer of indirection, but I really cant see how else it
    us> works!

Not really another layer of indirection. After the arguments ( which must be
constant, no varargs), a copy of the registers file is added on function
entry, so we can access them, and on exit, these register file is copied
back to the actual register. A normal return value resided in Eax.

Bye