C# or Windows API?
Well, I want to take a Windows GUI programming class this semester and was looking for some opinions on the topic. I think I want to take either C# or GUI programming w/ C++. I've done a few online tutorials using MFC and whatnot, and have ordered Windows Programming by Charles Petzold, as was suggested by many people on this message board. However, I donno which class would be more useful in the future. I've heard that C++ GUI programming will probably die off sooner or later, because C# and .NET will replace it, and .NET makes it much easier to mix programming languages anyway, so there's no real need for C++ GUI programming. Do you people feel there's some truth to this? Thanks for any opinions. :)
>> I've heard that C++ GUI programming will probably die off sooner or later, because C# and .NET will replace it
Whether your doing Windows GUI programming in .NET, C++, or any language for that matter - they all end up making Win32 API calls to get the job done.
>> C# or GUI programming w/ C++
This is probably more of a personal decision - but here are my two bits...
If "GUI programming w/ C++" means MFC, then I would wait till you have gone through Petzold first - only because MFC is a C++ framework of the C based, Win32 API - so learning the Win32 API first helps alot with being effective with MFC immediatly.
However, Petzold may arrive any day now :)
You could go through the Petzold book while taking the MFC class.
If it isn't an MFC class, and you're comfortable with your C++ skillz, consider the C# class.
I've been spending some time reading the .NET mailing lists at MSDN, and you have to be careful at what Microsoft's engineers tell you.
A few people have asked if the .NET APIs are a wrapper for the Win32 API. The engineers will say no. The engineers will tell you that the .NET APIs are totally new APIs, separate from the Win32 API.
But then, some people asked if the .NET APIs make Win32 API calls, and the engineers reluctantly say yes.
What the engineers mean is that new .NET APIs will wrap existing .NET APIs. But all the existing .NET APIs ultimately make calls to Win32 functions in DLLs like kernel32.dll. In other words, Win32 and MFC will be around for a long time. Win32 isn't going away, and all your applications will still run in the near future.
Microsoft isn't really rewriting the OS in Longhorn, they're doing exactly what Sun's Java does. Adding another application layer to the operating system.
So then is it safe to say that .NET apps won't ever be as efficient as apps using the Win32 API or some GUI library(such as SmartWin, not MFC), since they are just calling functions in the Win32 library?
As it turned out neither class would fit my schedule, so I'll just be going through the Petzold book, and probably try to learn on my own from there. Thanks for your help by the way. :)
The .Net framework has JIT compilation so I wouldn't expect it to be much slower computationaly, if at all.
I guess my opinion is not really needed now, but I would have to tell you to go with C#. Here are my reasons:
1) You will most likely never get hired to write a program using only the win32 API. Even Windows CE supports .NET.
2) Microsoft has said that MFC is dead and not on their road-map for the future. They usually support current release - 2. I don't know where that maps to MFC, but I'm sure MFC isn't far off from becoming unsupported.
3) At the Microsoft Professional Developer's Conference this year, the talk was completely about Longhorn, and how the .NET Framework was going to be the heart and soul of the new OS. They even have an XML filesystem!
4) You will be way more productive and write a lot more capable programs.
Having said that, I hate C# and .NET because I'm an embedded systems programmer. If I'm writing to an API I feel cheated, unless I wrote the API. A lot of programmers get by without knowing the Win32 API. Of course they don't really have a clue about how windows works, but they survive. If you love programming learn everything, but if you want to just make money, learn C#.