Win32 vs. .Net/CLR

[Can Balioglu]

Hi everyone,

My question is not a technical one. I'm just curious about the future of
Win32 (and Win64) programming. Most of the books about Win32 from MS Press
(like Programming Windows, Programming Applications for Windows, etc.) are
not published anymore. Almost all new articles in the last few years in MSDN
(and MSDN Magazine) are related to .Net. Do Microsoft want to us to write no
Win32 code anymore?

I'm planning to write a server application which needs to be high
performant. I'm trying to figure out the right platform for it. Either C/C++
over native Win32 using powerful OS features like IO Completion Ports, etc.
or .Net Framework/CLR without the burden of memory management, access
violations, buffer overflows, etc. I'm sure here are many experienced
developers. What is your suggestions? Do you think that CLR provides enough
capability for server side applications or for a real server application
(which needs to handle thousands of clients concurrently) C/C++ is the way
to go? Thanks for all replies...

 

[Nicholas Paldino [.NET/C# MVP]]

Can,

I can't say completely that MS doesn't want you to write unmanaged code
anymore, but if your application is a good fit for managed code, I think
that they would probably prefer that you use that over unmanaged code.
Basically, almost everything except device drivers and low-level OS stuff
should be written in a managed language.

As for your needs, you will probably find that using .NET will make
things very easy for you, and you can still be very performant. The fact
that you don't have to worry about memory management, and code access
security are a big plus, asd the environment is also easier to develop in
than most.

The .NET framework takes advantage of IO completion ports in a few
situations (the Socket class, namely), but if you ever needed to call an API
function, you can easily do that through the P/Invoke layer (and the interop
story for .NET is the best I have seen for any technology, hands down).

If you provide more details about your particular application, then we
can provide specific input as to where .NET will be of help to you, and how
to go about doing it.

Hope this helps.

 

[Can Balioglu]

Thanks a lot for your answer.

Actually it will be a SIP (Session Initiation Protocol) application server
and will act as a gateway between IP based networks and public switched
telephone networks. It also will handle the encoding/decoding of voice data
between separate networks. There are already SIP servers in the market
(mostly for Unix systems written in C++ or Java), but except MS Live
Communication Server there is no pure SIP server optimized for Windows
environment. I'm experienced both in native and managed programming. As you
already mentioned .Net Framework cuts the development efforts enormously but
I still have the prejudice against it when it comes to a real server
application. For example I'm not sure about the performance of a managed
codec implementation. Maybe the reason is that I haven't seen a "managed"
server product from Microsoft or any other big company until yet.

 

[Nicholas Paldino [.NET/C# MVP]]

Can,

But you have. If there are solutions on Unix for Java, then that is a
"managed" application. From a high level, it's the same thing. A managed
solution should be able to handle your needs on a windows platform.

 

[Can Balioglu]

As I said it's a question against my prejudice But you're right. Again
thanks a lot for your answers.

 

[Nicholas Paldino [.NET/C# MVP]]

Can,

Just to let you know, your managed code isn't managed for too long.
Eventually, it gets compiled into native code, and that is run.

Also, from a memory management standpoint, if you have a server that is
constantly handling that many requests simultaneously, then your GC is going
to get into a nice little groove and tune itself rather nicely (due to the
steady number of objects in all generations, 0, 1, and 2).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

As I said it's a question against my prejudice But you're right. Again
thanks a lot for your answers.

 

[Magnus Krisell]

If the codec is a bottleneck for the performance of the server, you would
probably want to write that part in native code to take advantage of
hardware SSE-instructions. I don't have any experience writer server
applications but I have implemented some DSP algorithms and SSE
can make a huge difference in such cases. A future version of the CLR
might (will?) take advantage of this automatically, but to my knowledge
the current versions doesn't.

I'm all for managed code for everything but low level performance
critical stuff.

- Magnus