Access hardware directly via C#?

[I.P. Freely]

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

 

[Dino Chiesa [Microsoft]]

Hey IP !

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.

 

[Guest]

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.

 

[I.P. Freely]

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?

 

[B0nj]

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?