Windows Programming in C++

Being a C#/Java programmer, I really need to know a fact: Has Windows Programming with Win32SDK/MFC/wxWidget become antiquated?

What is the status of popularity of these technologie开发者_开发技巧s in software industry now?

Being a C#/Java programmer, do I need to learn Win32SDK/MFC/wxWidget now?

I think that learning the Win32 SDK is useful because it helps you understand how Windows works internally. I found learning about hooks and subclassing very fascinating. So if it interests you then you should go for it. However, you probably don't need to know Win32. It's not yet antiquated today but it may be in the future.

I never had much interest in MFC because it requires the paid version of Visual Studio.

Yes, learn Win32, even if don't ever intend to write or maintain C/C++ apps.

No, don't bother learning MFC/wxWidget now. MFC does come with its source code, so you can study how some classes implement wrappers for Win32, but that is more interesting to C++ programmers. MFC is has decreased in popularity, though Visual Studio continues to support this older tech. Learn MFC/wxWidget only for an as-needed basis, if you need to maintain some older code.

With C#/Java, you can solve a lot of problems, but there are times when you will need to use Win32 directly to achieve some task. for a variety of reasons. Maybe some functionality is simply missing from .NET/Java, or has a bug that can be avoided by going directly to Win32. Maybe your particular problem to solve has unusual or strict requirements, and you would consider writing a portion of your app in native code using some Win32 calls as necessary. Lots of examples/situations really.

Another reason to learn Win32 is that both .NET/Java are higher level abstractions (which is in itself a good thing), but it really does help to understand the internals for these reasons:

1. You get an appreciation of how much work .NET/Java do for you. Of course, you can do the same things in C/C++, but it takes a lot more work. Consider these two compelling .NET technologies, WPF and WCF, which do a lot work for you.
2. You will better understand resource management. Specifically, both .NET/Java are garbage collected environments, but you must deterministically release OS resources (explicitly calling Dispose), for such things as network connections, window handles, kernel objects, and plenty more. You should never rely on the garbage collector to release these objects for you, since the GC is non-deterministic.
3. Debugging, knowing the internals seriously helps here.
4. Knowing Win32 can sometimes help explain the API design in .NET at least. Some parts of the .NET API are modeled on Win32 API, but some parts of the .NET API are extreme improvements over some truly heinous Win32 API designs (consider the API for using GDI for example).
5. Finally, knowing Win32 can help solve performance problems in your apps.

Win32 won't become antiquated, until the Microsoft's popular operating systems are based on something else. At one point, Microsoft was going to replace Win32/64 with .NET in Vista, but this didn't pan out. Even for whatever replaces Win32/64 is the future, you still need to understand the OS SDK. At the risk of sounding like a salesman, I will say that learning Win32 will in fact help you write more robust applications and will greatly aid your debugging skills, two important items to help you stay employed. I would never hire a windows programmer who doesn't have at least some experience with Win32.

I would suggest "Windows via C/C++" by Richter/Nasarre, as one example of a good book on Win32 (yes, it's obviously geared towards C/C++, but these authors do an excellent job explaining Win32).

Hope this helps.

I think Win32/64 SDK will never be antiquated, as drivers or other low level programs won't be written in .NET or Java because of the performance requirements. If you are going to develop in .NET, then MFC or wxWidget is useless for you.

I develop in .NET regularly, and sincerely, every program I've ever created in .NET called some Win32 API functions. So learning Win32/64 SDK isn't pointless, but is time-consuming.

I am an architect and I recommend that all new projects use newer technologies, like .NET or Java. The difference in productivity is tremendous, at least according to my own experience with C++ and .NET.

There are two exceptions: - I work for a software company and we are bound by the requirements of our customer, usually including the programming environment. So, if a customer only has people knowing, say, MFC, we will make an MFC project. But this is becoming rarer and rarer. If we have the choice, we will go with .NET or Java. - You have a team with expert people in these older technologies and they are quite productive with them.

There's plenty of work for people like you, so I'd advise not learning these for job purposes. We have some MFC apps, but that's partly because it's what we had and partly because we had more faith in C++ performance, and performance is very important for them.

I wouldn't call C++ or MFC antiquated, but there's relatively less new work in it. (I would very much like to never support another Win32 program, though.) The new C++ standard should be out in 200B, and people will continue to work on it, and Microsoft has been adding new classes to MFC, so obviously there's continued interest and continued work.

For professional development, I'd suggest you learn something different, but that would be something like Lisp or Haskell, rather than C++, and as far as I can tell there's no particular virtue in knowing MFC.

Realistically Microsoft forces business to use their latest and greatest technologies. There will always be work for someone who knows both technologies because someone has to port legacy code.

Many small devices (phones) or games require lighter solutions. If you intend to work in those areas you will definitely need those technologies.

You need to decide where you want to go. Once you have a map then you can lay in the right supplies for the journey.

I found Java horrendous to work with compared to Win32. Someone needs to cut about ninety percent of the inbuilt libraries.

I wouldn't call Win32 and such antiquated. As other people have said, it really depends on the app. As a game developer, I use Win32 less and DirectX a hell of a lot more. I could double or triple my Windows code, and it would still be an extremely small portion of the project.

However, if you're writing a primarily interface application with a relatively small and lightweight backend, .NET might well be a good choice for you.

As for Haskell, I just found that to be a truly terrible language in pretty much every respect. It seemed to me that it served some abstract mathematical definition of "functional", rather than a real definition of "programmable-in".

Win32 SDK is nowadays used in niche markets, where more modern technologies can't be used for some reasons (legacy Win32 systems, games, system drivers, Windows Embedded systems). If you aren't planning on pursuing a career on these markets, I wouldn't bother learning Win32 now. It is not that is useless and has no new things to teach you, but let's face it, there are so many new technologies coming out even at the time we speak. I have a dozen of technologies/languages in my waiting list to start learning and experimenting with. You can certainly find more interesting and more career favorable technologies to learn.

Performance critical apps (games) typically use C++ Win32 API.

C# and .NET are actually built on top of the Win32 API. To access some of the advanced features of Win32 that aren't exposed through C# and .NET you use Pinvoke to manually expose a C Win32 function to your C# app.