tags:

views:

360

answers:

10

I have been told that Windows programming can be done using either .NET, or MFC or C++ with the Windows API as described in "Programming Microsoft Windows" book

I have a few questions, listed below:

  1. Would it make sense for .NET developers to learn Windows Programming as taught in Charles Petzold's - Programming Microsoft Windows book?

  2. Have you come across any scenario in your projects when you found that the api provided by .NET did not address your needs and you had to go "one level lower" in the abstraction?

  3. Is the kind of programming Raymond Chen talks about in his blog the same as the one taught in the "Programming Microsoft Windows" book.

I am a web developer (ASP .NET) and have become very interested in Smart Clients.

+1  A: 
  1. Not necessary, but good information.
  2. Only in the past when .NET did not support COM ports.
  3. I don't know his blog.

have fun.

There is no need for you to learn MFC. Go with .NET and don't look back.

Tim
A: 

Learn .NET windows programming because 95% of the things you will do (maybe even higher) are covered by the framework. For the rest, just ask on SO and someone will help.

keithwarren7
+4  A: 

Charles Petzold, the guru of Win32 programming, says he has little need to program at the Win32 level any more since .NET came out. He's certainly not avoiding Win32 because he doesn't want to learn it; he literally wrote the book on it. If he feels little need to go below the .NET layer, there must not be much need to.

John D. Cook
"says he has little need to program at the Win32 level any more since .NET came out." - I think he says that since he already know so much of it... :-). Sometimes it is easy to underestimate the value of hard won experience and knowledge.
Nick
A: 
  1. I would say yes, with the argument that you need to know your tools. Otherwise, no. You can probably do just fine if you stick to .NET.

  2. I needed to make a toolbar for Internet Explorer and was advised againt using .NET (because of this), so for some specific things I still think that "pure" Windows programming is preferred.

  3. I don't know his blog.

jmoeller
You shouldn't write Windows Explorer extensions with .Net for the same reason.
Slapout
A: 

I am a huge fan of .NET for Windows programming. If you are going to write software that will go into other environment then .NET may not be a solution.

I love C# because what other language will allow you to write code for desktop, website, mobile (phone / pda), and gaming platforms (Zune / Xbox).

There are plenty of newbie C# books so just pick one and get started. However after the basics there aren't many advanced C# books, However two really great advanced C# books are Effective C# and More Effective C#.

My two copper.

Bobby Cannon
A: 
  1. The Petzold book covers the ins and outs of the Win32 API. Even if you use MFC, deep down, it's just a OO wrapper for the Win32 API. Reading this book can be nothing but a benefit to any Windows developer.
  2. If it's not exposed by COM, then you're out of luck.
  3. Raymond Chen's OldNewThing blog mostly deals with anecdotes about why some things in the Win32 API are the way they are.
Bullines
A: 

No matter what your method, you should understand the concepts of the windowing system. It's been a long time since I've read Petzold but he's a good author. My favorite book is "Win32 Programming" by Rector and Newcomer. (although it glosses over some of the UI window classes)

As far as programming methods go:

MFC is evil and bloated. C++ -- I've programmed in raw Win32 before & it's ok for small projects but rather cumbersome. The WTL template library makes it a lot easier.

If you are fluent in .NET then I suppose that would be the way to go (though personally I won't touch it or C#).

I've changed my mode of GUI app programming in recent months, primarily because I plan on buying a Mac soon and I would rather build an app in something that is cross-platform. Mozilla's XUL is pretty easy to work with, and I'd consider either that or Java Swing wayyyy before I'd work on a Windows-only application again.

Jason S
+1  A: 

To answer your second question, yes. Sometimes you do have to do a PInvoke to call a Windows API that doesn't yet have a .Net equivalent. There are web sites that will help with this, like PInvoke.net. The Win32 api has been around for a long time and even .Net relies on it under the hood (for now, anyway).

Slapout
+5  A: 

Yes, yes and yes. It certainly makes sense for .NET developers to learn Win32, and the best way do that is probably from Petzold. That doesn't mean it's necessary to learn Win32, but it makes sense to do so, both to give you a better understanding of what goes on under the hood, and because sometimes you may need to dig into the native API.

And yes, I've come across many scenarios where I had to use Win32 code. Some of them have been remedied in recent versions of .NET, but especially on mobile devices, there are still many areas not covered by .NET. Most commonly, anything really OS-specific tends to be not exposed in .NET. Want to put something on the Today screen on a smartphone? Win32. Want to make a baloon tooltip in the system tray on your desktop? Win32.

And yeah, Raymond Chen talks about the Win32 API, which is what Petzold documents in his book as well. Of course, Chen usually talks about the ugliest, weirdest, quirkiest and most inconsistent parts of it on his blog, but then again, it is a remarkably ugly, weird and quirky and inconsistent API, so his code is fairly representative after all. ;)

jalf
A: 

There are only so many days in the year and you do not want to eat them up learning older technologies "just in case." If you are writing a standard business or consumer application, then .NET will almost certainly do everything that you need. Indeed, when you consider the sheer size and scope of .NET as well as the other technologies that you'll need to master (database, distribution, source control, bug management, etc.) then you will certainly want to be careful with your time.

With respect to "Smart Clients" - I understand how attractive this type of technology looks and I really wanted to go this route a few years ago (e.g. ClickOnce app deployment, etc.). However, I would strongly suggest you avoid going down that path!

Why? Well, our experience is pretty instructive. We produce both Windows apps and Web apps and both still sell well. However, we also permit the Windows apps to act as a kind of "smart client" - working with a hosted DB service that we offer (no, it is not one-click deployment but it shares the same appeal to potential customers). Quite simply, offering this service isn't worth the extra pixels on the price list. The vast majority of companies interested in purchasing Internet-enabled apps want a pure port 80 (Web app) / remotely hosted solution. Firewalls and corporate policies that lock down desktops essentially strangle any but the most popular Smart Client. And the people who want our Windows apps just don't want to be tied to the Internet - they want everything on their own network and a one-time purchase.

In a related vein, one of the other technology companies in our space made a huge commitment to Smart Clients across its product line. It has proven disastrous for them and they had to scramble like mad to climb down from their Smart Client commitment and back onto a pure Web app.

To the extent that you wish to escape the constraints of HTML and even AJAX, I would look into Silverlight or AIR.

Mark Brittingham