tags:

views:

159

answers:

5

I have been learning windows API from online and PDF books but I hear of people using sdk and visual studio programs. What should i do? API I'd create but extremely complex. Would I benefit from learning the API or should I get a sdk or program that writes to code for me? I have msc++e but I don't think it comes with those benifts

+5  A: 

You definitely want to use Visual Studio over using the Windows SDK directly for GUI programming. You can download Visual Studio Express edition to try it out first.

If you want something simpler you can take a look into .NET programming, or if you want to stay with C++ that's fine as well and you can use straight Win32 API or MFC programming. In most cases you probably don't want direct Win32 GUI programming nor MFC but if you do, consider buying a book from Charles Petzold (on Win32) or Jeff Prosise (on MFC).

Brian R. Bondy
I'd almost give a -1 for mentioning the evil MFC kludgy hack macro rubbish with so many bugs you end up writing mostly win32 direct anyway.
Greg Domjan
@Greg: It's not that bad, but compared to .NET programming both are very hard.
Brian R. Bondy
Having been an MFC programmer for many many years, I'd definitely recommend learning .NET over MFC. It's not that MFC was so bad, it's more that .NET is that much better.
Avalanchis
@Avalanchis: Agree Winforms and WPF are lightyears ahead in simplicity and development time savings.
Brian R. Bondy
This doesn't even answer the question.
Noah Roberts
@Noah Roberts: Maybe your interpretation of the question.
Brian R. Bondy
DO NOT start a new program using MFC. It's not really supported anymore. You should ONLY use MFC in a maintenance situation.
Michael Kohne
@Michael Kohne: Can't say that without knowing the OPs specific situation. Perhaps for example he is programming for Win PE in which case .NET is not available. I made mention of .NET programming though in case it is true that the OP just doesn't know what to start with.
Brian R. Bondy
@Michael Kohne: I don't agree that MFC isn't really supported any more, nor that it shouldn't be considered whatsoever. Here's a link with some information about VS 2010's new features for C++ and MFC: http://msdn.microsoft.com/en-us/magazine/ee336130.aspx. There are still some advantages to not having to install a large runtime environment. For example, the ability to compile an app into a single EXE that will run on nearly any Windows system without requiring any additional files is still a very powerful feature.
Avalanchis
+10  A: 

Although learning the raw Windows API certainly has its usefulness, I'd suggest you learning a toolkit like Qt (http://qt.nokia.com).

Vitor Py
QT is a great option for writing platform independent apps.
Avalanchis
QT is a great option for writing apps.
caspin
+1  A: 

The best answer to your question can depend on many things.

I've been developing applications for the Microsoft Windows platform for nearly twenty years, and I've utilized everything from straight Windows API, Turbo Pascal, MFC, Borland C++ builder, and Visual Basic.

I've tried many cross-platform toolkits including as wxWidgets and QT and these most certainly have their place and are excellent options for creating apps that will run on more than just Windows.

In general, if you're ONLY wanting to target the Windows platform (Mono Project notwithstanding), IMHO using the C# language to target the .NET platform with Visual Studio is probably the easiest and full-featured environment you will find for building Windows apps today.

You get an excellent set of tools and a wealth of documentation and probably most importantly a very large base of experienced programmers to draw upon when you have questions.

.NET also supports C++ and a variety of other languages to suit your needs. If you need low level access to the Win32 API, you can access the APIs directly using pinvoke. If you need even lower level control you can reference managed or unmanaged DLLs from your .NET application.

Avalanchis
+4  A: 

In the case of windows, the SDK and the Win32 API refer to pretty much the same thing. The SDK is all the crap you need to target the API (this is always what an "SDK" is). When you're using a non-VC compiler on windows (or a cross-compiler) you have to download the SDK in order to write win32 programs.

There's very few situations in which targeting the Win32 API itself is useful. You usually want to work at a higher level with an API like MFC, WTL, or WX (I include WX because for windows it's actually a wrapper for Win32). There are also libraries that do their own thing and just draw everything themselves (all owner drawn windows) like Qt, GTK, etc.

If you're working with a windows specific library you'll still end up touching the Win32 API occasionally but only small parts of it. You'll save a LOT of time just letting those parts turn up instead of actually trying to learn the API itself. Nobody that isn't insane or being tortured into submission writes raw Win32.

Noah Roberts
+1  A: 

I know fewer and fewer people writing native apps, especially for a single platform, and especially when that platform is Windows. While there's obviously still demand for this, I'm not sure I'd want to invest a lot of effort today in learning the particulars of the Windows API.

I'd look at something like Titanium that let me use web tools. It's pretty high-level, it's fast enough for pretty much anything I do, it's open-source, and it's cross-platform (even onto the web). I've seen apps (before Titanium) that are written as webpages that ship with their own rendering and javascript engine, too.

Ken