Greetings my dear friend,

Let's say I wanted to write an application that talks directly to a
network card. For example, say I'm designing a firewall or packet sniffer.
Do I need to use unmanaged code to do this? I'm wondering how I should
arrange the "division of labor" between managed and unmanaged code.

Let's make the example even simpler by saying that I want to design a
form with a button on it. When the button is clicked, I want to send a
packet out the ethernet card. The packet needs to be sent by talking
directly to the Ethernet card drivers, not via a standard interface like
Winsock [yes, I know that there's no practical reason to design such an
application -- it's just an example]..

So my goal is to make all of my code "managed" except what absolutely
MUST be unmanaged. So the form would be designed in C# -- as would be the
handler for the button... but when the button is clicked, I'll need to talk
to a network driver. So at that point, I'll need to use unmanaged C++ (??).
How would I handle this? As far as I know, I can't mix managed C# and
unmanaged C++ in the same assembly (can I?)... Would I design a totally
separate C++ DLL which exposes a SendPacket() method?

I'm not asking for any specific code, just general *concepts* that I can
research further in the online help, books, etc. I'm just not sure where to
begin.

I.P. Freely

Hey IP !

"I.P. Freely" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...

> So my goal is to make all of my code "managed" except what absolutely
> MUST be unmanaged. So the form would be designed in C# -- as would be the
> handler for the button... but when the button is clicked, I'll need to
talk
> to a network driver. So at that point, I'll need to use unmanaged C++
(??).

Yes, and no.
You can call into existing Win32 APIs (and pretty much any DLL) via
p/Invoke.
You don't have to author those DLLs in unmanaged C++. They could have been
authored in "anything".

> How would I handle this? As far as I know, I can't mix managed C# and
> unmanaged C++ in the same assembly (can I?)...

No, not with the current .NET Framework.

> Would I design a totally
> separate C++ DLL which exposes a SendPacket() method?
>

Yes, why not? and then the DLL needs to be on the path. It need not be
written in VC7.0 or VC7.1 ("unmanaged C++"). You could write it in VC6 or
something else.

> I'm not asking for any specific code, just general *concepts* that I
can
> research further in the online help, books, etc. I'm just not sure where
to
> begin.
>
> I.P. Freely
>
>

> Let's say I wanted to write an application that talks directly to a
> network card. For example, say I'm designing a firewall or packet sniffer.
> Do I need to use unmanaged code to do this? I'm wondering how I should
> arrange the "division of labor" between managed and unmanaged code.
>
As far as I know, only device drivers can access hardware directly on the
modern OS.
Only on Win95, Win98 and WinMe, you could access the hardware directly.

So you will have to create a unmanaged network driver in your example that
does what you want and then you can use managed/unmanaged programs that
connects to this custom driver and executes the things you want.

> So you will have to create a unmanaged network driver in your example that
> does what you want and then you can use managed/unmanaged programs that
> connects to this custom driver and executes the things you want.

So if a pre-existing driver exposes the functionality that I need, I
could talk to that driver from managed code? For example, I could build an
IP packet in C# and send it out the Ethernet card by talking to the network
driver directly? Is a driver just a DLL that can be called using the
P/Invoke method that Dino mentioned?

> Let's make the example even simpler by saying that I want to design a
> form with a button on it. When the button is clicked, I want to send a
> packet out the ethernet card. The packet needs to be sent by talking
> directly to the Ethernet card drivers, not via a standard interface like
> Winsock [yes, I know that there's no practical reason to design such an
> application -- it's just an example]..

....no, there isn't. If you wait till a situation when you actually need to
do that
comes along, you may soon get the impression that one will never exist.

> So my goal is to make all of my code "managed" except what absolutely
> MUST be unmanaged. So the form would be designed in C# -- as would be the
> handler for the button... but when the button is clicked, I'll need to
talk
> to a network driver. So at that point, I'll need to use unmanaged C++
(??).
> How would I handle this? As far as I know, I can't mix managed C# and
> unmanaged C++ in the same assembly (can I?)... Would I design a totally
> separate C++ DLL which exposes a SendPacket() method?

Yes. This is the most direct way to call C++ code directly from C#. The only
other way is COM, which involves more overhead.

>
> I'm not asking for any specific code, just general *concepts* that I
can
> research further in the online help, books, etc. I'm just not sure where
to
> begin.

Think about what you *actually* want to do?