Only one type of Unmanaged code?

[Sparhawk]

Hi,

my company is going to migrate a large VC++ application to .NET to
make use of Windows Forms (the old class library is not updated any
more). We are not planning to migrate the rest of the code which works
well.

I understand the basic concept: our code is unmanaged, Windows Forms
is Managed and Unmanaged may not call Managed code. I read about
Wrappers, PInvoke, Runtime Callable Wrappers for COM and about It just
Works (IJW). But I still have some unsolved questions.

1. If I write a managed wrapper for an unmanaged class, I use a
pointer of the unmanaged class in my managed class. Doesn't that make
my Managed Class Unmanaged? In which cases are pointers allowed in
Managed code?

2. If I compile my old code with the /clr switch (IJW) I get MSIL
code, which is unmanaged. Does this mean, that there are two types of
unmanaged code, one native (cpu dependent code), one MSIL? This would
probably answer 4. & 5. as well.

3. Is the __nogc completely optional? It seems that every class
without __gc gets an __nogc implicitly.

4. What does #pragma unmanaged do? Does it have the same effect as
writing __nogc?

5. I can't call Managed Code from Unmanaged Code. But (in the easy
examples) if I have an unmanaged function and a managed function in
the same file, the unmanaged one may call the managed one. Is there a
rule in which cases Unmanaged may call Managed?

6. Our code uses multiple inheritance. Does that mean that it can't be
compiled as Unmanaged MSIL (using IJW, /clr)?

Thanks in advance, those questions keep bugging me.
Kay

[Carl Daniel [VC++ MVP]]

Sparhawk wrote:

Hi,

my company is going to migrate a large VC++ application to .NET to
make use of Windows Forms (the old class library is not updated any
more). We are not planning to migrate the rest of the code which works
well.
If your program has an elaborate UI built on MFC, you might consider waiting
for VC8, which will have seamless interop between MFC and Windows forms
(e.g. simple hosting of a WinForms control within an MFC window and
vice-versa).
I understand the basic concept: our code is unmanaged, Windows Forms
is Managed and Unmanaged may not call Managed code. I read about
Wrappers, PInvoke, Runtime Callable Wrappers for COM and about It just
Works (IJW). But I still have some unsolved questions.

1. If I write a managed wrapper for an unmanaged class, I use a
pointer of the unmanaged class in my managed class. Doesn't that make
my Managed Class Unmanaged? In which cases are pointers allowed in
Managed code?
No, it doesn't make your class unmanaged. It's a managed class with data
member of value-type (pointer) that happens to point to some unmanaged
memory. As far as the CLR is concerned, it's no different than a 32 bit
integer.
2. If I compile my old code with the /clr switch (IJW) I get MSIL
code, which is unmanaged. Does this mean, that there are two types of
unmanaged code, one native (cpu dependent code), one MSIL? This would
probably answer 4. & 5. as well.
If you compile existing C++ code with /clr you get managed code that
manipulates unmanaged data.
3. Is the __nogc completely optional? It seems that every class
without __gc gets an __nogc implicitly.
That depends on whether you're operating under the influence of #pragma
managed (the default with /clr) or #pragma unmanaged.
4. What does #pragma unmanaged do? Does it have the same effect as
writing __nogc?
Yes. It causes everything not explicitly marked __gc to be implicitly
marked __nogc.
5. I can't call Managed Code from Unmanaged Code. But (in the easy
examples) if I have an unmanaged function and a managed function in
the same file, the unmanaged one may call the managed one. Is there a
rule in which cases Unmanaged may call Managed?
You just named one. That's the principal behind IJW - within an MC++
compiland, managed can call unmanaged and vice-versa and It Just Works.
6. Our code uses multiple inheritance. Does that mean that it can't be
compiled as Unmanaged MSIL (using IJW, /clr)?

No. It means that your inheritance hierarchy cannot be expressed in terms
of the CLR concept of inheritance. Normal C++ code (lacking any __gc
qualifiers), when compiled with /CLR exposes neither inheritance nor even
classes to the CLR. It's simply code targeting a different "machine
language" (the CLI) that has complete control over the data it references.

-cd