Fog Creek Software
Discussion Board

Windows GUI Programming for a Unix Programmer

Hello Joel,

I am an experienced C/C++ Unix programmer with little to no programming experience on the Windows platform.  I found your "Biculturalism" review/essay quite interesting as well as the recent "Learning Microsoft platforms" thread started by Unix Guy.  Unix Guy was interested in doing many things and as a result you gave him a very broad plan for approaching the Windows platform.  I have a much more specific question that will hopefully yield a much more specific answer.

I am quite comfortable developing GUIs using the C-based Gtk+ toolkit on Unix platforms.  I have done a few simple Swing GUIs in Java and am also familar with the Perl and Python TK interfaces.  I would like to learn how to develop GUI applications for Windows.  Nothing fancy at first:  a simple GUI-based "Hello World" program that stores data in a flat text file would be nice.

What is the best place for me to start given my previous experience?  I am interested in hearing about both wizard based approaches and approaches where I program directly against a lower level API.  Should I start with Visual Basic, stick with C/C++ or jump directly to C#?  Do you have any suggestions for books that focus on GUI programming?  Are there any questions that I should be asking that I am not!?


(another) Unix Guy
Monday, March 15, 2004

I am personally a big believer in starting with the low level tools. Once you understand the anatomy of the platform, you're welcome to use the high level tools for productivity.

So, I would start with Petzold and the Win 32 API in C (not even C++). That's the moral equivalent of learning programming starting with K&R C.

Joel Spolsky
Fog Creek Software
Monday, March 15, 2004


I've been interested in much the same question for a long time.  I just read (and bookmarked BTW) this thread:

Which recommends Rector and Newcomer's "Win32 Programming" book over Petzold's.  Do you know this book?  How do you compare the two?

Ken Klose
Tuesday, March 16, 2004

(another) Unix Guy,

What you'll end up learning is how to write non-portable code.  Is that your intention? Everything that Microsoft has done over the past 20 years is designed for lock-in. That is, if you do things their way you can never go back.

Taking code from MS tools makes it extremely difficult to port to Unix or Mac, whereas most Unix GUI tools are also ported to MS Windows. You can get Perl and Python for PCs, WxWin or WxPython for Windows GUIs and IDEs like Boa Constructor.

All these things maintain portability as their primary goal. Sun's entire Java business plan (despite constantly shooting itself in the foot) is designed for cross-platform portability. But Microsofties don't want that. They want to maintain their monopoly.

That being said, however, since 90% of the market is Microsoft you really should know how to use their tools.
Just hold your nose while doing it.

Tuesday, March 16, 2004

When you say "Microsoft tools" you're apparently referring to the "wizards" of Visual Studio, or to application framework provided by MFC. Nobody forces you to do these things, and Petzold doesn't even mention them.

On the other hand, writing Win32 code isn't inherently any more or less portable than writing X11 or Mac code. Just isolate the API calls and you'll be fine.

Chris Nahr
Tuesday, March 16, 2004

May I mention wxWidgets ( nee wxWindows. It uses native GUI elements on its platforms, GTK+ on Unix, Win32 on Windows and whatever on Mac OS and OS/2. Its a moderately clean OO framework that does much more than just GUI stuff. It has threds, file access, networking, etc. For example when creating a configuration file it creates a dot file under Unix and on Win32 it uses the registry.

I've used it for a while and I had to make one small non platform specific change when I went from Linux to Windows due to a compiler difference. The change was valid on both platforms.

If your aim is to understand the Win32 platform at some great depth then its not relevant but if you "want to get things done" (tm) then its one avenue.

Advert over.

Tuesday, March 16, 2004

> I am personally a big believer in starting with the low level tools.

Yes (I started with assembler) but perhaps not in this instance.

Speaking as an experienced C++/Win32API/MFC programmer who has started to use .NET, I don't think that Win32 API experience is especially relevent to using C# and .NET ... the .NET framework does a good job an insulating you from the Win32API ... and C# is easy to use if you know C++.

So, unless you have some other reason to avoid C# and .NET (e.g., if you want cross-platform), then I'd recommend starting with those, and skipping the Win32API.

Christopher Wells
Tuesday, March 16, 2004

In response to old_timer's portabilty comments, your last sentence pretty much sums it up:  if I ever emerge from the Unix ghetto and need to work on a Windows app I want to know what my options are.

I will take a look at the Petzold, Rector and Newcomer Win32 books at Borders.  I will also sneak a peak at the C#.NET books.

Chris's comment comparing Win32 to X11 is interesting to me.  I have considerable experience with the Gtk+ GUI toolkit which  is layered on X11.  Am I correct in assuming that the various .NET flavors are different layers of abstraction over the Win32 API?

Thanks to everyone who has taken the time to respond...I appreciate it.

(another) Unix Guy
Tuesday, March 16, 2004

> Am I correct in assuming that the various .NET flavors are different layers of abstraction over the Win32 API?

MFC and the ATL (which are C++ libraries/frameworks) are fairly thin veneers over the Win32 API; so thin that it might well be worthwhile to know the underlying Win32 API.

Whereas I think that the .NET framework does such a good job at insulating you from the Win32 API that it seems to me you could do a lot of .NET programming without knowing anything about the Win32 API.

The "various .NET flavours" by the way are several languages ("managed C++" which is C++ with memory management; C# which is like a mix of C++ and Java; and VB.NET which is like C# with a Visual Basic-like syntax), all of which compile to a common p-code and which can all use a the same class library (called the ".NET framework"). This class library provides components, including GUI components, for you to use.

Another aspect of .NET programming is the IDE: which offers great auto-completion and so on, and easier access to things like "COM" components than I found with pure C++.

So I think I'd recommend .NET over anything else, for various reasons, though I don't know what your requirements are beyond "Hello World". The two chief drawbacks of .NET seem to be: less portable than other solutions (since you're writing in an MS-specific programming language); getting the .NET framework installed on the end-user machine (20+ MB, which matters to people whose customers get their software from slow internet connections).

In case it matters, when I was looking for a job last year there were more advertisements for .NET Windows programmers than for the other kinds.

Christopher Wells
Tuesday, March 16, 2004

>> I am personally a big believer in starting with the low level tools.

> Yes (I started with assembler) but perhaps not in this instance.

Ah, you jest.  Yet what you say can be done easily; look at

i like i
Wednesday, March 17, 2004


If the various .NET languages all use the same class library then what, besides language syntax (what I like) and company policy (what my employer likes), would drive me to go with one language versus the other?

(another) Unix Guy
Wednesday, March 17, 2004

I think that virtually the only difference between C# and VB.NET is the syntax: that anything you can do in one you can do in the other; so that it's only a matter of whether you like VB syntax, with key-words like "dim" and "end if", or prefer a C++-like syntax with semi-colons and braces and so on. Note that since they compile to the same p-code, classes written in one language can use (call, contain, inherit from, etc) classes written in the other.

I haven't used "Managed C++". Looking at the help, it seems to contain a lot of extra reserved words (like __sealed, __value, etc) to give it access to .NET features. Starting a new program from scratch, I chose C# (a language designed for .NET) over C++. A good reason for choosing "managed C++" instead of C# might be if you have existing C++ code that you want to recompile, with minimal source code changes, for .NET.

Apart from these three, there seem to be other language flavours too (e.g. J#, which I guess is aimed at Java programmers migrating to .NET).

.NET supports your invoking "unmanaged" code (which uses pointers and could use the Win32 API directly) but I haven't done that yet.

Web-based programming is another aspect of .NET (using I think "ASP.NET" to write runs-in-browser software), but I don't know anything about that either.

Christopher Wells
Wednesday, March 17, 2004

> could use the Win32 API directly
Actually I don't know how to use the Win32 API, or whether it can be used, from .Net managed code.

Christopher Wells
Wednesday, March 17, 2004

GTK+ runs on Windows as well as Unix, so you could just keep using what you already know.  Perl-Tk and Python-Tk also run on Windows.

Personally, I have found Python-GTK on Windows to be quite a good way to write things.

Tim Evans
Wednesday, March 17, 2004

"Actually I don't know how to use the Win32 API, or whether it can be used, from .Net managed code."

You can, and it's actually pretty simple, as long as you don't need to pass complex data structures.

Chris Nahr
Thursday, March 18, 2004

This discussion has been quite enlightening for me.  I feel that I now have enough background to choose my own path.  Thanks to all who have taken the time to respond!

(another) Unix Guy
Thursday, March 18, 2004

I think you already have all the technical background you need.

If you've already worked with GTK+ in C, Java Swing, and Perl/Python Tk, then IMHO you already know most of what you need to know about the technical aspects of GUI programming (in any platform).

But what you DON'T know is how to design GUI applications that LOOK like Windows. When should you use an MDI container window? Should you have dockable toolbars? Should you use wizards?

I know many many unix developers, who are now designing GUIs in the windows world, but they still look like GTK apps, because of the layout style (even though they use native win32 look-n-feel).

My recommendation to you would be to study the style of windows GUIs, and then pick up any win32 toolkit (wxwindows, QT, .NET, etc.) and work on developing well-designed interfaces.

Benji Smith
Friday, March 19, 2004

Writing a GTK app using wxWindows in C++ on Unix then porting it to Windows might allow you to compare/contrast the platform that you know with the one that you don't.  You are bound to learn some differences in the porting process, especially if you go the extra distance to make it a first rate Windows app by adding Windows specific code.  You also won't have to read a bunch of stuff from books that are meant for rank beginners (though you could probably read pretty fast through them anyway).

Daniel Howard
Tuesday, March 23, 2004

RealBasic 5.5 will let you compile to Win32, MaxOS X, MacOS 8/9, and Linux. It ain't C++, but it'll get the job done.

A Fellow Software Developer
Thursday, March 25, 2004

Check out Boa Constructor! It's a pretty good cross platform RAD tool in wxPy.

Jonas B.
Monday, March 29, 2004

*  Recent Topics

*  Fog Creek Home