468,121 Members | 1,457 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,121 developers. It's quick & easy.

Non public wrappers on unmanaged C functions & C++ class

Hello,

in the last few days I've made my first few attempts at creating mixed
C++ managed-unmanaged assemblies and looking afterwards with ILDASM
at what is visible in those assemblies from a managed point-of-view
I've noticed that:

1) for each managed and unmanaged C function (not C++ classes) I get a
public managed static method (defined on a 'Global Functions' class)
in the generated assembly with an export name of the form
xyz.FunctionName, where xyz looks like a C++ mangled random name. As
global methods of this 'Global Functions' class also appear the main
and _mainCRTStartup functions and any other C library function that
gets used inside the defined managed or unmanaged C functions. In my
simple sample applications, for example, I'm using the printf C
standard library function inside my definined functions and when
looking at the generated assembly with ILDASM I find a public managed
static method with the same name.

2) for each unmanaged C++ class I get a public managed structure
(value class) with no managed method visible. Including any C++
standard library (such as iostrem, string, ecc.) in a project also
adds a lot of managed objects in the form of public managed
structures (value classes). And this happens even if none of the
included C++ standard library classes gets used in the defined
managed/unmanaged C++ classes.

All of the above happens when compiling assemblies in release mode and
having specified to have the compiler produce NO debugging
information. Incredibly I discovered that even for release compiled
assemblies some debugging information still is produced and inserted
into the assembly. Look under "Project Properties -> C/C++ ->
General" and set Debug Information Format to Disabled to stop debug
info from being placed into your assemblies.

Now, what I'd like to do is:

(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but
most of all

(2) I'd like to have all these managed structures (value classes)
created around my managed/unmanaged C functions and unmanaged C++
classes to be PRIVATE and NOT PUBLIC as their are created now.

I've tried defining as static both the managed and unmanaged C
functions but this does not seem to change anything. As for the C++
unmanaged classes it seems that access specifiers (public, private,
protected) may only be applied to managed classes and so on this
front I have not been able to do anything.

Can anyone help me out???
Thx

Bob Rock

Nov 17 '05 #1
2 1775
Bob,

This is hardly a complete response to your question but, regarding 2, if you
look at the managed value types that the compiler generates to represent
your native classes you will see that they contain no members. The have a
size that is accurate, and that is all. Aside from their name and size,
nothing is exposed about your native types to the managed side. That they
are empty means that noone could really do much with those types without the
header files that declare them - if that is what you are partly concerned
about.

Bern McCarty
Bentley Systems, Inc.

"Bob Rock" <ye********************@hotmail-dot-com.no-spam.invalid> wrote in
message news:40**********@127.0.0.1...
Hello,

in the last few days I've made my first few attempts at creating mixed
C++ managed-unmanaged assemblies and looking afterwards with ILDASM
at what is visible in those assemblies from a managed point-of-view
I've noticed that:

1) for each managed and unmanaged C function (not C++ classes) I get a
public managed static method (defined on a 'Global Functions' class)
in the generated assembly with an export name of the form
xyz.FunctionName, where xyz looks like a C++ mangled random name. As
global methods of this 'Global Functions' class also appear the main
and _mainCRTStartup functions and any other C library function that
gets used inside the defined managed or unmanaged C functions. In my
simple sample applications, for example, I'm using the printf C
standard library function inside my definined functions and when
looking at the generated assembly with ILDASM I find a public managed
static method with the same name.

2) for each unmanaged C++ class I get a public managed structure
(value class) with no managed method visible. Including any C++
standard library (such as iostrem, string, ecc.) in a project also
adds a lot of managed objects in the form of public managed
structures (value classes). And this happens even if none of the
included C++ standard library classes gets used in the defined
managed/unmanaged C++ classes.

All of the above happens when compiling assemblies in release mode and
having specified to have the compiler produce NO debugging
information. Incredibly I discovered that even for release compiled
assemblies some debugging information still is produced and inserted
into the assembly. Look under "Project Properties -> C/C++ ->
General" and set Debug Information Format to Disabled to stop debug
info from being placed into your assemblies.

Now, what I'd like to do is:

(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but
most of all

(2) I'd like to have all these managed structures (value classes)
created around my managed/unmanaged C functions and unmanaged C++
classes to be PRIVATE and NOT PUBLIC as their are created now.

I've tried defining as static both the managed and unmanaged C
functions but this does not seem to change anything. As for the C++
unmanaged classes it seems that access specifiers (public, private,
protected) may only be applied to managed classes and so on this
front I have not been able to do anything.

Can anyone help me out???
Thx

Bob Rock

Nov 17 '05 #2
This is true, but it's also true that you can't even name mangle a
mixed-mode C++ assembly without paying $800 for one of the commercial
obfuscators. Which means that your managed classes reveal pretty much their
source code, and your unmanaged classes make it obvious what they do. I
suppose you could code in mangled names, but our Mac guys would go beserk if
I checked in a load of cross platform classes called A, B and C.... :-)

Steve

"Bern McCarty" <be**********@bentley.com> wrote in message
news:eD**************@TK2MSFTNGP09.phx.gbl...
Bob,

This is hardly a complete response to your question but, regarding 2, if you look at the managed value types that the compiler generates to represent
your native classes you will see that they contain no members. The have a
size that is accurate, and that is all. Aside from their name and size,
nothing is exposed about your native types to the managed side. That they
are empty means that noone could really do much with those types without the header files that declare them - if that is what you are partly concerned
about.

Bern McCarty
Bentley Systems, Inc.

"Bob Rock" <ye********************@hotmail-dot-com.no-spam.invalid> wrote in message news:40**********@127.0.0.1...
Hello,

in the last few days I've made my first few attempts at creating mixed
C++ managed-unmanaged assemblies and looking afterwards with ILDASM
at what is visible in those assemblies from a managed point-of-view
I've noticed that:

1) for each managed and unmanaged C function (not C++ classes) I get a
public managed static method (defined on a 'Global Functions' class)
in the generated assembly with an export name of the form
xyz.FunctionName, where xyz looks like a C++ mangled random name. As
global methods of this 'Global Functions' class also appear the main
and _mainCRTStartup functions and any other C library function that
gets used inside the defined managed or unmanaged C functions. In my
simple sample applications, for example, I'm using the printf C
standard library function inside my definined functions and when
looking at the generated assembly with ILDASM I find a public managed
static method with the same name.

2) for each unmanaged C++ class I get a public managed structure
(value class) with no managed method visible. Including any C++
standard library (such as iostrem, string, ecc.) in a project also
adds a lot of managed objects in the form of public managed
structures (value classes). And this happens even if none of the
included C++ standard library classes gets used in the defined
managed/unmanaged C++ classes.

All of the above happens when compiling assemblies in release mode and
having specified to have the compiler produce NO debugging
information. Incredibly I discovered that even for release compiled
assemblies some debugging information still is produced and inserted
into the assembly. Look under "Project Properties -> C/C++ ->
General" and set Debug Information Format to Disabled to stop debug
info from being placed into your assemblies.

Now, what I'd like to do is:

(1) hide, if possible, any managed objects (value classes, arrays and
fields) created around my unmanaged C functions and C++ classes, but
most of all

(2) I'd like to have all these managed structures (value classes)
created around my managed/unmanaged C functions and unmanaged C++
classes to be PRIVATE and NOT PUBLIC as their are created now.

I've tried defining as static both the managed and unmanaged C
functions but this does not seem to change anything. As for the C++
unmanaged classes it seems that access specifiers (public, private,
protected) may only be applied to managed classes and so on this
front I have not been able to do anything.

Can anyone help me out???
Thx

Bob Rock


Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by david chang via DotNetMonster.com | last post: by
6 posts views Thread by nicolas.hilaire | last post: by
2 posts views Thread by Jon Slaughter | last post: by
18 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.