[repost] Static initialization of native code in CLI/native mixed environment

[bvisscher]

I posted this recently in microsoft.publi c.vc.language and was
redirected
here.

I also searched this ng and found some relavant threads.

The most relavent I found was:

http://groups.google.com/group/micro...919fdc1ee07313

(static unmanaged object in mixed exe)

The solution seems to be to either set the linker's /entry to the
mangled
name of int main(array<Syst em::String^> ^)) or to have an int WinMain
that calls the managed style main. The latter actually seems
preferable
since I don't want to have to memorize the manged name, but this still
seems like a bug to me (you could also default to console app but that
ususally isn't acceptable).

Is this still the consensus on the state of this issue?

This still seems like a bug to me. Either in the compiler or the
wizard,
but which is it? Should I be expected to know that I have to have a
WinMain for a mixed exe? Where is this documented?

[original post follows.]
I have recently been sentenced to the task of getting a Windows
Forms application to work with static libraries that contain native
code. This isn't working.

What is happening is that the first statically allocated object with a
nontrivial destructor is being registered with atexit. However, the
atexit function utilizes a pair of pointers that aren't setup
correctly. In debug it breaks at the following line of code in
dbgheap.c:

/* validation section */
_VALIDATE_RETUR N(pUserData != NULL, EINVAL, -1);

If I "pop the stack" I can see that __onexitbegin and __onexitend are
0. Elsewhere, in comments in the sources that come with MSC
(e.g. mcrtexe.c) I read that in a main program these should be
initialized to -1.

I have been able to work around this with the following code:

typedef void (__cdecl *_PVFV)(void);
extern "C"
{
_PVFV *__onexitbegin= (_PVFV*)-1;
_PVFV *__onexitend=(_ PVFV*)-1;
}

in the same .cpp file that has a C++/CLI main function implemented
with the Pascal style pointer/reference whatever they are ("^")
thingies.

This works in Win2k but apparently not on XP.

Which leads me to believe that perhaps native and managed code can be
mixed but that they must reside in separate DLLs? One of the articles
I have found in MSDN seems to suggest that problems of this kind are
resolved via DLLmain which would seem to support this suggestion.

Has anyone else experienced this problem? Is it not possible to link
a main program compiled with /clr with static libraries that aren't?

Thanks in advance for any insight.

[Marcus Heege]

Hi,

as far as I can tell now, the VC project Wizard for a "Windows Forms
Application" creates a project that does not depend on the CRT, because
assemblies with CRT initialization can not use certain features of the
Visual Studio 2005 component model. I am currently researching this because
I am currently writing a book about C++/CLI and one chapter is about CLR and
CRT initialization of assemblies. I will blog about this soon. So far, I can
only recomment you to split your application into the EXE project that calls
Application.Run and a DLL project compiled with /clr:safe that provides the
forms and controls.

Marcus Heege

<bv*******@bell south.net> wrote in message
news:11******** **************@ v46g2000cwv.goo glegroups.com.. .

I posted this recently in microsoft.publi c.vc.language and was
redirected
here.

I also searched this ng and found some relavant threads.

The most relavent I found was:

http://groups.google.com/group/micro...919fdc1ee07313

(static unmanaged object in mixed exe)

The solution seems to be to either set the linker's /entry to the
mangled
name of int main(array<Syst em::String^> ^)) or to have an int WinMain
that calls the managed style main. The latter actually seems
preferable
since I don't want to have to memorize the manged name, but this still
seems like a bug to me (you could also default to console app but that
ususally isn't acceptable).

Is this still the consensus on the state of this issue?

This still seems like a bug to me. Either in the compiler or the
wizard,
but which is it? Should I be expected to know that I have to have a
WinMain for a mixed exe? Where is this documented?

[original post follows.]
I have recently been sentenced to the task of getting a Windows
Forms application to work with static libraries that contain native
code. This isn't working.

What is happening is that the first statically allocated object with a
nontrivial destructor is being registered with atexit. However, the
atexit function utilizes a pair of pointers that aren't setup
correctly. In debug it breaks at the following line of code in
dbgheap.c:

/* validation section */
_VALIDATE_RETUR N(pUserData != NULL, EINVAL, -1);

If I "pop the stack" I can see that __onexitbegin and __onexitend are
0. Elsewhere, in comments in the sources that come with MSC
(e.g. mcrtexe.c) I read that in a main program these should be
initialized to -1.

I have been able to work around this with the following code:

typedef void (__cdecl *_PVFV)(void);
extern "C"
{
_PVFV *__onexitbegin= (_PVFV*)-1;
_PVFV *__onexitend=(_ PVFV*)-1;
}

in the same .cpp file that has a C++/CLI main function implemented
with the Pascal style pointer/reference whatever they are ("^")
thingies.

This works in Win2k but apparently not on XP.

Which leads me to believe that perhaps native and managed code can be
mixed but that they must reside in separate DLLs? One of the articles
I have found in MSDN seems to suggest that problems of this kind are
resolved via DLLmain which would seem to support this suggestion.

Has anyone else experienced this problem? Is it not possible to link
a main program compiled with /clr with static libraries that aren't?

Thanks in advance for any insight.

the poblem that you describe is related to