473,724 Members | 2,248 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Repost - Converting from pure mode to mixed mode Dll

I received no answers about this the first time I posted, so I will try
again. My inability to decipher an MSDN topic may find others who have the
same inability and someone who can decipher and explain it.

I have some questions about the instructions for creating a mixed mode DLL
in the MSDN topic "Converting Managed Extensions for C++ Projects from Pure
Intermediate Language to Mixed Mode" in the "Managed Extensions for C++
Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is already set
up with this option in the linker, and the previous explanation about mixed
mode says "you must modify your DLL to have an explicit entry point". Is
this first instruction correct ?

2) I don't understand the three areas to consider for making further changes
under the topic "Modifying Components That Consume the DLL for Manual
Initializiation ". I am creating a DLL as a "Class Library (.NET)" project. I
have not added in any DLL exports myself using __declspec(dlle xport), and I
expect the end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry points as
opposed to the normal DllMain entry point in unmanaged code, but I have not
manually added a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding __DllMainCRTSta rtup@12 to
the Force Symbol References property. Do any of the three situations apply
to me, or can I just ignore the instructions in this section ? The last
possibility may apply,"Your DLL's consumers can use managed code, and your
DLL contains either DLL exports or managed entry points", so I want to know
if I have to implement the code mentioned in that solution, and then have a
console or Window program manually call my initialize and terminate static
member functions at the beginning and end of their main and WinMain
routines.
Nov 17 '05 #1
9 2590
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
I received no answers about this the first time I posted, so I will try
again. My inability to decipher an MSDN topic may find others who have the
same inability and someone who can decipher and explain it.

I have some questions about the instructions for creating a mixed mode DLL
in the MSDN topic "Converting Managed Extensions for C++ Projects from Pure Intermediate Language to Mixed Mode" in the "Managed Extensions for C++
Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is already set
up with this option in the linker, and the previous explanation about mixed mode says "you must modify your DLL to have an explicit entry point". Is
this first instruction correct ? [ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid the
"loader lock" bug.
(http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).
2) I don't understand the three areas to consider for making further changes under the topic "Modifying Components That Consume the DLL for Manual
Initializiation ". I am creating a DLL as a "Class Library (.NET)" project. I have not added in any DLL exports myself using __declspec(dlle xport), and I expect the end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry points as opposed to the normal DllMain entry point in unmanaged code, but I have not manually added a DllMain, if that is what is meant, other than following the instructions to convert to mixed mode by adding __DllMainCRTSta rtup@12 to
the Force Symbol References property. Do any of the three situations apply
to me, or can I just ignore the instructions in this section ? [ALBERT:] #3 applies to you. Managed entry point in this context is simply
static or
instance method of managed type.
The last
possibility may apply,"Your DLL's consumers can use managed code, and your
DLL contains either DLL exports or managed entry points", so I want to know if I have to implement the code mentioned in that solution, and then have a console or Window program manually call my initialize and terminate static
member functions at the beginning and end of their main and WinMain
routines.

[ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify. Nevertheless,
the answer is yes.
Your clients will explictly have to call ManagedWrapper. minitialize() on
startup and ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.
Nov 17 '05 #2
Albert Szilvasy wrote:
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and explain
it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ? [ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/de...-us/dv_vstecha rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).
OK, I understand and it makes sense. What confused me was asking me to make
a change when there was no necessity to do so, because the standard setup
for a pure mode .NET class library already has the /noentry flag set.
2) I don't understand the three areas to consider for making further
changes under the topic "Modifying Components That Consume the DLL
for Manual Initializiation ". I am creating a DLL as a "Class Library
(.NET)" project. I have not added in any DLL exports myself using
__declspec(dlle xport), and I expect the end-user of my Dll will use
it for the .NET components I have created. I also don't have any
idea what is meant by managed entry points as opposed to the normal
DllMain entry point in unmanaged code, but I have not manually added
a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding
__DllMainCRTSta rtup@12 to the Force Symbol References property. Do
any of the three situations apply to me, or can I just ignore the
instructions in this section ? [ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.


Thanks, that clarifies what is meant by "managed entry points". One usually
thinks of DllMain for DLLs, and WinMain or main for GUI and console apps, as
entry points. Now I understand that the term for "managed entry point" is
any .NET types methods.
The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call my
initialize and terminate static member functions at the beginning
and end of their main and WinMain routines. [ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify.


A managed client could be a .NET WinForms application, could it not ? I am
creating .NET components, so I assume my clients are either other .NET DLLs
or .NET applications.
Nevertheless, the answer is yes.
Your clients will explictly have to call ManagedWrapper. minitialize()
on startup and ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.


If one of my .NET component assemblies uses another of my .NET component
assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions from
within my own ones ? What prevents these routines from being called more
than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike a .NET
Windows Form application which does have a WinMain. Is there a reason to
have this with a mixed-mode DLL, or is it just completely unnecessary in
..NET assemblies ? If a pure mode assembly needs to initialize my assembly by
calling ManagedWrapper. minitialize and ManagedWrapper. mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about how one
tracks startup and shutdown in an assembly dll.
Nov 17 '05 #3
There's no such thing as assembly startup/shutdown. At least, this contract
is not standardized as it was with traditional dlls (i.e. DllMain). I
believe they looking at standardizing something similar but it doesn't
currently exist.

The client of your dll will have to call minitialize before they start using
any other functions in your dll and mterminate after they finished using
your dll.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and explain
it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ? [ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).


OK, I understand and it makes sense. What confused me was asking me to

make a change when there was no necessity to do so, because the standard setup
for a pure mode .NET class library already has the /noentry flag set.
2) I don't understand the three areas to consider for making further
changes under the topic "Modifying Components That Consume the DLL
for Manual Initializiation ". I am creating a DLL as a "Class Library
(.NET)" project. I have not added in any DLL exports myself using
__declspec(dlle xport), and I expect the end-user of my Dll will use
it for the .NET components I have created. I also don't have any
idea what is meant by managed entry points as opposed to the normal
DllMain entry point in unmanaged code, but I have not manually added
a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding
__DllMainCRTSta rtup@12 to the Force Symbol References property. Do
any of the three situations apply to me, or can I just ignore the
instructions in this section ? [ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.


Thanks, that clarifies what is meant by "managed entry points". One

usually thinks of DllMain for DLLs, and WinMain or main for GUI and console apps, as entry points. Now I understand that the term for "managed entry point" is
any .NET types methods.
The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call my
initialize and terminate static member functions at the beginning
and end of their main and WinMain routines. [ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify.


A managed client could be a .NET WinForms application, could it not ? I am
creating .NET components, so I assume my clients are either other .NET

DLLs or .NET applications.
Nevertheless, the answer is yes.
Your clients will explictly have to call ManagedWrapper. minitialize()
on startup and ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.
If one of my .NET component assemblies uses another of my .NET component
assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions from
within my own ones ? What prevents these routines from being called more
than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike a .NET
Windows Form application which does have a WinMain. Is there a reason to
have this with a mixed-mode DLL, or is it just completely unnecessary in
.NET assemblies ? If a pure mode assembly needs to initialize my assembly

by calling ManagedWrapper. minitialize and ManagedWrapper. mterminate, where does it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about how one
tracks startup and shutdown in an assembly dll.

Nov 17 '05 #4
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.
Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have to
do this, but there was no way I could create a pure mode component given the
C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look
at the great standard C++ string class, and attempt to create a string class
for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the
height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and
explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).


OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.

2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That Consume
the DLL for Manual Initializiation ". I am creating a DLL as a
"Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dlle xport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry
points as opposed to the normal DllMain entry point in unmanaged
code, but I have not manually added a DllMain, if that is what is
meant, other than following the instructions to convert to mixed
mode by adding __DllMainCRTSta rtup@12 to the Force Symbol
References property. Do any of the three situations apply to me,
or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.


Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.

The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call
my initialize and terminate static member functions at the
beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.


A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.
Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper. minitialize() on startup and
ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.


If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper. minitialize and ManagedWrapper. mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.

Nov 17 '05 #5
What specifically from std::string do you think is most critically needed?

As far as STL paradigm containers, we hope to have good news for the Whidbey
release.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.
Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have

to do this, but there was no way I could create a pure mode component given the C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look at the great standard C++ string class, and attempt to create a string class for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
> I received no answers about this the first time I posted, so I will
> try again. My inability to decipher an MSDN topic may find others
> who have the same inability and someone who can decipher and
> explain it.
>
> I have some questions about the instructions for creating a mixed
> mode DLL in the MSDN topic "Converting Managed Extensions for C++
> Projects from Pure Intermediate Language to Mixed Mode" in the
> "Managed Extensions for C++ Reference".
>
> 1) The first instruction in converting to mixed mode is to link
> with /NOENTRY. This occurs despite the fact that a pure mode DLL is
> already set up with this option in the linker, and the previous
> explanation about mixed mode says "you must modify your DLL to have
> an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.
> 2) I don't understand the three areas to consider for making
> further changes under the topic "Modifying Components That Consume
> the DLL for Manual Initializiation ". I am creating a DLL as a
> "Class Library (.NET)" project. I have not added in any DLL
> exports myself using __declspec(dlle xport), and I expect the
> end-user of my Dll will use it for the .NET components I have
> created. I also don't have any idea what is meant by managed entry
> points as opposed to the normal DllMain entry point in unmanaged
> code, but I have not manually added a DllMain, if that is what is
> meant, other than following the instructions to convert to mixed
> mode by adding __DllMainCRTSta rtup@12 to the Force Symbol
> References property. Do any of the three situations apply to me,
> or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.
> The last
> possibility may apply,"Your DLL's consumers can use managed code,
> and your DLL contains either DLL exports or managed entry points",
> so I want to know if I have to implement the code mentioned in that
> solution, and then have a console or Window program manually call
> my initialize and terminate static member functions at the
> beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper. minitialize() on startup and
ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper. minitialize and ManagedWrapper. mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.


Nov 17 '05 #6
It isn't that different from components using COM though who also had to
init COM after DLL init and uninitialize before existing.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.
Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have

to do this, but there was no way I could create a pure mode component given the C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look at the great standard C++ string class, and attempt to create a string class for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
See below:
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eP******** ******@TK2MSFTN GP12.phx.gbl...
> I received no answers about this the first time I posted, so I will
> try again. My inability to decipher an MSDN topic may find others
> who have the same inability and someone who can decipher and
> explain it.
>
> I have some questions about the instructions for creating a mixed
> mode DLL in the MSDN topic "Converting Managed Extensions for C++
> Projects from Pure Intermediate Language to Mixed Mode" in the
> "Managed Extensions for C++ Reference".
>
> 1) The first instruction in converting to mixed mode is to link
> with /NOENTRY. This occurs despite the fact that a pure mode DLL is
> already set up with this option in the linker, and the previous
> explanation about mixed mode says "you must modify your DLL to have
> an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
rt/html/vcconMixedDLLLo adingProblem.as p)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.
> 2) I don't understand the three areas to consider for making
> further changes under the topic "Modifying Components That Consume
> the DLL for Manual Initializiation ". I am creating a DLL as a
> "Class Library (.NET)" project. I have not added in any DLL
> exports myself using __declspec(dlle xport), and I expect the
> end-user of my Dll will use it for the .NET components I have
> created. I also don't have any idea what is meant by managed entry
> points as opposed to the normal DllMain entry point in unmanaged
> code, but I have not manually added a DllMain, if that is what is
> meant, other than following the instructions to convert to mixed
> mode by adding __DllMainCRTSta rtup@12 to the Force Symbol
> References property. Do any of the three situations apply to me,
> or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.
> The last
> possibility may apply,"Your DLL's consumers can use managed code,
> and your DLL contains either DLL exports or managed entry points",
> so I want to know if I have to implement the code mentioned in that
> solution, and then have a console or Window program manually call
> my initialize and terminate static member functions at the
> beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper. minitialize() on startup and
ManagedWrapper. mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper. minitialize and ManagedWrapper. mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.


Nov 17 '05 #7
Ronald Laeremans [MSFT] wrote:
It isn't that different from components using COM though who also had
to init COM after DLL init and uninitialize before existing.
I assume you mean "unitinitia lize before exiting".

The most obvious difference is that COM has to be initialized and
uninitialized by a single call for all COM objects. With mixed mode C++ .NET
assemblies, each mixed mode assembly has to be initialized and terminated.
That is a far more onerous situation.

Also there appears to be no entry or exit point in .NET assemblies for
initializing and terminating other assemblies which it is using, since
DllMain does not exist. If the facility is meant for only .NET EXEs to do in
the WinMain ( or main ) routine, this places an extra burden on the creator
of the EXE since some of the mixed mode assemblies with which this has to be
done may not even be used directly by the EXE. It would be much better for
mixed mode assemblies which reference othe mixed mode assemblies to do the
initializing and terminating of those other assemblies, but the lack of
clear entry and exit points preclude this.

Finally, of course, I am still reading that there is a chance for lockup for
mixed mode assemblies even after all the recommendations for initializing
and terminating mixed mode assembles have been made. Nor is there any
explanation of what could still be causing a lockup, nor of any workarounds
for that rare situation. So anyone writing a mixed mode MC++ assembly could
lock up an application using it, and the recourse to it is to tell the end
user that it is MS's fault as if that will excuse on'e own .NET components
or classes in some end users estination.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.


Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
> See below:
> "Edward Diener" <ed******@tropi csoft.com> wrote in message
> news:eP******** ******@TK2MSFTN GP12.phx.gbl...
>> I received no answers about this the first time I posted, so I
>> will try again. My inability to decipher an MSDN topic may find
>> others who have the same inability and someone who can decipher
>> and explain it.
>>
>> I have some questions about the instructions for creating a mixed
>> mode DLL in the MSDN topic "Converting Managed Extensions for C++
>> Projects from Pure Intermediate Language to Mixed Mode" in the
>> "Managed Extensions for C++ Reference".
>>
>> 1) The first instruction in converting to mixed mode is to link
>> with /NOENTRY. This occurs despite the fact that a pure mode DLL
>> is already set up with this option in the linker, and the
>> previous explanation about mixed mode says "you must modify your
>> DLL to have an explicit entry point". Is this first instruction
>> correct ?
> [ALBERT:] Yes, this is correct. You must link with /NOENTRY to
> avoid the "loader lock" bug.
>

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
> rt/html/vcconMixedDLLLo adingProblem.as p)
> The explicit entry point referred to here is the one that you are
> instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.

>
>> 2) I don't understand the three areas to consider for making
>> further changes under the topic "Modifying Components That
>> Consume the DLL for Manual Initializiation ". I am creating a DLL
>> as a "Class Library (.NET)" project. I have not added in any DLL
>> exports myself using __declspec(dlle xport), and I expect the
>> end-user of my Dll will use it for the .NET components I have
>> created. I also don't have any idea what is meant by managed
>> entry points as opposed to the normal DllMain entry point in
>> unmanaged code, but I have not manually added a DllMain, if that
>> is what is meant, other than following the instructions to
>> convert to mixed mode by adding __DllMainCRTSta rtup@12 to the
>> Force Symbol References property. Do any of the three situations
>> apply to me, or can I just ignore the instructions in this
>> section ?
> [ALBERT:] #3 applies to you. Managed entry point in this context
> is simply static or
> instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.

>
>> The last
>> possibility may apply,"Your DLL's consumers can use managed code,
>> and your DLL contains either DLL exports or managed entry
>> points", so I want to know if I have to implement the code
>> mentioned in that solution, and then have a console or Window
>> program manually call my initialize and terminate static member
>> functions at the beginning and end of their main and WinMain
>> routines.
> [ALBERT:] I'm a bit confused here because you said that you only
> have managed clients
> and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

> Nevertheless, the answer is yes.
> Your clients will explictly have to call
> ManagedWrapper. minitialize() on startup and
> ManagedWrapper. mterminate()
> shutdown. This is the explict entry point that is referred to
> above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper. minitialize and ManagedWrapper. mterminate, where
does it do this ? I would have guessed from a DllMain
PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
am confused about how one tracks startup and shutdown in an
assembly dll.

Nov 17 '05 #8
Ronald Laeremans [MSFT] wrote:
What specifically from std::string do you think is most critically
needed?
How about append, assign, compare, erase, find, find_first_not_ of, find,
find_first_of, find_last_not_o f, find, find_last_of, insert, rfind, and
replace; all in nearly any combination, with substrings and offsets which
one could imagine. I realize that System::String has some of this in more
limiting respect, but why not go with what is best and get it over with
instead of trying to maintain backward compatibility.

I know that System::String is immutable, but any of the aforementioned
functionality in std::string which would normally change the string itself,
could return a new System::String in .NET.

You really should have modeled your own System::String after the C++
std::string class, and its rich functionality, rather than the VB and MFC
functionality, which is much poorer and more limiting. It is too bad that MS
did not learn in this regard and settled for much less.

As far as STL paradigm containers, we hope to have good news for the
Whidbey release.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.


Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.

Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
> See below:
> "Edward Diener" <ed******@tropi csoft.com> wrote in message
> news:eP******** ******@TK2MSFTN GP12.phx.gbl...
>> I received no answers about this the first time I posted, so I
>> will try again. My inability to decipher an MSDN topic may find
>> others who have the same inability and someone who can decipher
>> and explain it.
>>
>> I have some questions about the instructions for creating a mixed
>> mode DLL in the MSDN topic "Converting Managed Extensions for C++
>> Projects from Pure Intermediate Language to Mixed Mode" in the
>> "Managed Extensions for C++ Reference".
>>
>> 1) The first instruction in converting to mixed mode is to link
>> with /NOENTRY. This occurs despite the fact that a pure mode DLL
>> is already set up with this option in the linker, and the
>> previous explanation about mixed mode says "you must modify your
>> DLL to have an explicit entry point". Is this first instruction
>> correct ?
> [ALBERT:] Yes, this is correct. You must link with /NOENTRY to
> avoid the "loader lock" bug.
>

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
> rt/html/vcconMixedDLLLo adingProblem.as p)
> The explicit entry point referred to here is the one that you are
> instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.

>
>> 2) I don't understand the three areas to consider for making
>> further changes under the topic "Modifying Components That
>> Consume the DLL for Manual Initializiation ". I am creating a DLL
>> as a "Class Library (.NET)" project. I have not added in any DLL
>> exports myself using __declspec(dlle xport), and I expect the
>> end-user of my Dll will use it for the .NET components I have
>> created. I also don't have any idea what is meant by managed
>> entry points as opposed to the normal DllMain entry point in
>> unmanaged code, but I have not manually added a DllMain, if that
>> is what is meant, other than following the instructions to
>> convert to mixed mode by adding __DllMainCRTSta rtup@12 to the
>> Force Symbol References property. Do any of the three situations
>> apply to me, or can I just ignore the instructions in this
>> section ?
> [ALBERT:] #3 applies to you. Managed entry point in this context
> is simply static or
> instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.

>
>> The last
>> possibility may apply,"Your DLL's consumers can use managed code,
>> and your DLL contains either DLL exports or managed entry
>> points", so I want to know if I have to implement the code
>> mentioned in that solution, and then have a console or Window
>> program manually call my initialize and terminate static member
>> functions at the beginning and end of their main and WinMain
>> routines.
> [ALBERT:] I'm a bit confused here because you said that you only
> have managed clients
> and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

> Nevertheless, the answer is yes.
> Your clients will explictly have to call
> ManagedWrapper. minitialize() on startup and
> ManagedWrapper. mterminate()
> shutdown. This is the explict entry point that is referred to
> above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper. minitialize and ManagedWrapper. mterminate, where
does it do this ? I would have guessed from a DllMain
PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
am confused about how one tracks startup and shutdown in an
assembly dll.

Nov 17 '05 #9
Could one arrange to have the initialisation performed automatically, by
defining a static constructor for every managed class in the assembly, and
making that call the initialisation function (if it hadn't already been
called) ? That would absolve clients from explicitly calling that
initialisation function. Or am I being naive ?

Trouble is, even if that worked, there's no equivalent way to perform the
un-initialisation :-(

S.

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:ej******** ********@TK2MSF TNGP10.phx.gbl. ..
Ronald Laeremans [MSFT] wrote:
It isn't that different from components using COM though who also had
to init COM after DLL init and uninitialize before existing.
I assume you mean "unitinitia lize before exiting".

The most obvious difference is that COM has to be initialized and
uninitialized by a single call for all COM objects. With mixed mode C++

..NET assemblies, each mixed mode assembly has to be initialized and terminated.
That is a far more onerous situation.

Also there appears to be no entry or exit point in .NET assemblies for
initializing and terminating other assemblies which it is using, since
DllMain does not exist. If the facility is meant for only .NET EXEs to do in the WinMain ( or main ) routine, this places an extra burden on the creator of the EXE since some of the mixed mode assemblies with which this has to be done may not even be used directly by the EXE. It would be much better for
mixed mode assemblies which reference othe mixed mode assemblies to do the
initializing and terminating of those other assemblies, but the lack of
clear entry and exit points preclude this.

Finally, of course, I am still reading that there is a chance for lockup for mixed mode assemblies even after all the recommendations for initializing
and terminating mixed mode assembles have been made. Nor is there any
explanation of what could still be causing a lockup, nor of any workarounds for that rare situation. So anyone writing a mixed mode MC++ assembly could lock up an application using it, and the recourse to it is to tell the end
user that it is MS's fault as if that will excuse on'e own .NET components
or classes in some end users estination.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.

Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.
Albert
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
> Albert Szilvasy wrote:
>> See below:
>> "Edward Diener" <ed******@tropi csoft.com> wrote in message
>> news:eP******** ******@TK2MSFTN GP12.phx.gbl...
>>> I received no answers about this the first time I posted, so I
>>> will try again. My inability to decipher an MSDN topic may find
>>> others who have the same inability and someone who can decipher
>>> and explain it.
>>>
>>> I have some questions about the instructions for creating a mixed
>>> mode DLL in the MSDN topic "Converting Managed Extensions for C++
>>> Projects from Pure Intermediate Language to Mixed Mode" in the
>>> "Managed Extensions for C++ Reference".
>>>
>>> 1) The first instruction in converting to mixed mode is to link
>>> with /NOENTRY. This occurs despite the fact that a pure mode DLL
>>> is already set up with this option in the linker, and the
>>> previous explanation about mixed mode says "you must modify your
>>> DLL to have an explicit entry point". Is this first instruction
>>> correct ?
>> [ALBERT:] Yes, this is correct. You must link with /NOENTRY to
>> avoid the "loader lock" bug.
>>
>

(http://msdn.microsoft.com/library/de...-us/dv_vstecha
>> rt/html/vcconMixedDLLLo adingProblem.as p)
>> The explicit entry point referred to here is the one that you are
>> instructed to create further down in the article. (see below).
>
> OK, I understand and it makes sense. What confused me was asking me
> to make a change when there was no necessity to do so, because the
> standard setup for a pure mode .NET class library already has the
> /noentry flag set.
>
>>
>>> 2) I don't understand the three areas to consider for making
>>> further changes under the topic "Modifying Components That
>>> Consume the DLL for Manual Initializiation ". I am creating a DLL
>>> as a "Class Library (.NET)" project. I have not added in any DLL
>>> exports myself using __declspec(dlle xport), and I expect the
>>> end-user of my Dll will use it for the .NET components I have
>>> created. I also don't have any idea what is meant by managed
>>> entry points as opposed to the normal DllMain entry point in
>>> unmanaged code, but I have not manually added a DllMain, if that
>>> is what is meant, other than following the instructions to
>>> convert to mixed mode by adding __DllMainCRTSta rtup@12 to the
>>> Force Symbol References property. Do any of the three situations
>>> apply to me, or can I just ignore the instructions in this
>>> section ?
>> [ALBERT:] #3 applies to you. Managed entry point in this context
>> is simply static or
>> instance method of managed type.
>
> Thanks, that clarifies what is meant by "managed entry points". One
> usually thinks of DllMain for DLLs, and WinMain or main for GUI and
> console apps, as entry points. Now I understand that the term for
> "managed entry point" is any .NET types methods.
>
>>
>>> The last
>>> possibility may apply,"Your DLL's consumers can use managed code,
>>> and your DLL contains either DLL exports or managed entry
>>> points", so I want to know if I have to implement the code
>>> mentioned in that solution, and then have a console or Window
>>> program manually call my initialize and terminate static member
>>> functions at the beginning and end of their main and WinMain
>>> routines.
>> [ALBERT:] I'm a bit confused here because you said that you only
>> have managed clients
>> and managed clients don't have WinMain that you could modify.
>
> A managed client could be a .NET WinForms application, could it not
> ? I am creating .NET components, so I assume my clients are either
> other .NET DLLs or .NET applications.
>
>> Nevertheless, the answer is yes.
>> Your clients will explictly have to call
>> ManagedWrapper. minitialize() on startup and
>> ManagedWrapper. mterminate()
>> shutdown. This is the explict entry point that is referred to
>> above.
>
> If one of my .NET component assemblies uses another of my .NET
> component assemblies, should I specifically call the latter's
> ManagedWrapper. minitialize and ManagedWrapper. mterminate functions
> from within my own ones ? What prevents these routines from being
> called more than once as a pair, or does it not matter ?
>
> Finally I noticed that my .NET component DLL has no DllMain, unlike
> a .NET Windows Form application which does have a WinMain. Is there
> a reason to have this with a mixed-mode DLL, or is it just
> completely unnecessary in .NET assemblies ? If a pure mode assembly
> needs to initialize my assembly by calling
> ManagedWrapper. minitialize and ManagedWrapper. mterminate, where
> does it do this ? I would have guessed from a DllMain
> PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
> am confused about how one tracks startup and shutdown in an
> assembly dll.


Nov 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
4523
by: Ted Miller | last post by:
Hi folks, I'm looking at moving a large base of C++ code to .Net under tight time constraints. The code runs in mission-critical environments, and I am extremely concerned about the loader lock problem and the potential for deadlocks. After pouring over the available information, and trying a few experiments, I am still left with a few questions and issues I hope someone out there can shed some light on.
0
1674
by: Edward Diener | last post by:
I have some questions about the instructions for creating a mixed mode DLL in the MSDN topic "Converting Managed Extensions for C++ Projects from Pure Intermediate Language to Mixed Mode" in the "Managed Extensions for C++ Reference". 1) The first instruction in converting to mixed mode is to link with /NOENTRY. This occurs despite the fact that a pure mode DLL is already set up with this option in the linker, and the previous...
14
2833
by: Steve McLellan | last post by:
Hi, Sorry to repost, but this is becoming aggravating, and causing me a lot of wasted time. I've got a reasonably large mixed C++ project, and after a number of builds (but not a constant number) linking (and sometimes compiling) becomes immensely slow, and task manager shows that link.exe (or cl.exe) is barely using any processor time, but an awful lot of RAM (around 150-200MB). I'm going to keep an eye on page faults since I can't...
13
5050
by: bonk | last post by:
Hello, I am trying to create a dll that internally uses managed types but exposes a plain unmanaged interface. All the managed stuff shall be "wrapped out of sight". So that I would be able to use that dll from pure unmanaged code (for example inherit from classes in that dll). Is something like that possible. I heared something called ManWarp tried that approach. If it is possible, how can I do that. Maybe there is a small litttle
4
5570
by: bonk | last post by:
This article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconconvertingmanagedextensionsforcprojectsfrompureintermediatelanguagetomixedmode.asp seems to be somewhat out of date. Not all of it seem to apply to vs 2005 (beta 2) and c++/CLI. I followed the instructions given there but using vs 2005 beta 2 I get some warnings about depreciation: warning CRT1001: _vcclrit.h is deprecated warning C4996:...
0
1065
by: draskin | last post by:
Hello, I have the following situation: - Text.exe creates a new AppDomain - Test.exe loads mixed mode assembly in a non-default AppDomain - Test.exe calls connect to a TCP/IP socket server which calls into native code to actually create a TCP/IP socket connection - Test code sets up a listener using the mixed mode assembly to be notified asynchronously (i.e. on a different thread) of events. The listener is held onto by a managed...
5
1459
by: Bart | last post by:
Hi, What is the benefit of using the Pure option over the Mixed one. Is there a better performance? We have a lot of stuff in c++ with mfc support en we want to use in our .net apps. With mixed setting we can compile including the mfc part of our code. We can get rid of the mfc code but it will cost us some effort so we can use the pure setting in that case.
5
7267
by: =?Utf-8?B?U2hhcm9u?= | last post by:
I have a class that is writen in unmanaged pure native C++. This class files (h and cpp) are inserted to a managed C++ (VC++ 2005, C++/CLI) DLL compoenet. This DLL compoenet is used in a C# application. My question is: Does the performance of the unmanaged pure native C++ class described above is the same if it was a in a pure unmanaged native C++ DLL component?
3
5391
by: dragonslayer008 | last post by:
I am building a control library in C++/CLI. My project links with a native library and am getting an error that the library cannot work with pure: dxerr.lib(dxerr.obj) : fatal error LNK1313: ijw/native module detected; cannot link with pure modules I am fine switching to CLR mode, but I have a question. If I build the control library DLL in CLR mode, will it still integrate seamlessly into C#/VB projects? Or will I have to change...
0
8741
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9388
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9241
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
6685
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5996
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4504
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3209
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2612
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2149
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.