Windows API for VISTA, 7 & Beyond

Question

Is there any fundamental differences in the WinAPI/Win32? Is there any additional knowledge required to take advantage of new OS features?

Are there any pitfalls which someone who's coded Win32 apps in the past might fall in?

I'm not talking about Silverlight, that's a whole different ball of wax. (I don't have the VS that supports that at work yet.)

Edit: Drew has a pretty good answer so far, but what's critical for a programmer to know? i.e. What should be in an appendix to Charles Petzold's book? (Theoretically)

Answer 1

Nothing special. The old stuff pretty much works as it did. There are some new APIs, but nothing earth shattering (and following the old Win32 conventions). So everything you know from Vista is still true for Win7.

Now, there are some new guidelines regarding user experience (touch screen, libraries (user experience stuff, not programmer stuff)), but the API style is the same.

Answer 2

There are new API's for each.

There is additional knowledge, though it may not be required, you should be familiar with 64-bit and multi-threaded application development to name a few. The higher level constructs such as Direct2D, .NET etc., etc., are what require the adjustment in knowledge, not necessarily the lower level APIs.

Answer 3

There are of course lots of new APIs that you should be aware of to make sure you have the tools you need. Beyond that, there are some changes to note.

Philosophical changes
Large parts of the old win32 APIs focused on C-style APIs where handles were passed around. Nowadays, many of the new APIs being developed are COM-based, so boning up on COM and ATL would be worthwhile.

You might also want to take note of the new API style if you're writing your own libraries, which is a bit more consistent and avoids things like hungarian notation.

Replacements
Generally, don't assume that the methods you knew about 10 years ago are still state-of-the-art; they all still exist, so you won't necessarily be told you're doing it wrong. Check MSDN to see if it refers you to something better, and use the latest SDK so that you'll get deprecation warnings for some functions. Especially, make sure string functions you're using are secure.

Specifically, one 'replacement' API is Direct 2d, which is a DirectX-style API for UIs. If you're writing graphics code for Windows 7, you should consider Direct2d over GDI, which has a programming model that is compatible with, but very different than, GDI's. Direct 2d may be ported back to Vista.

Also, instead of using win32-style menuing, consider using the Ribbon, which will be available for Vista as well as Win7.

If you're using the common controls library, make sure to use v6, not the default of v5.

Finally, make sure you're not unnecessarily calling things that require admin privileges, as that will prompt UAC.

All I can think of for now.

Answer 4

You have the choice: traditional C/C++ or use the newer .Net framework languages (C# / VB.net / Python.net and more). For the latter, knowing the framework is more important than the implementation. You're isolated (in general) from pointers, threading, buffers and memory management and apart from a few differences in syntax once you know the framework it's portable between languages (ie, you could easily pick up VB.net programming if you're a C# guy as most of what your apps will do is call parts of the framework). You can create a class in C#, use it in a VB.net program and reference the same class out of a Powershell cmdlet for example.

The old-style C interfaces are still for Win32 there but unless you've got a specific need to use them (legacy code, Direct X, device drivers for example) I'd look at the newer stuff. As for things like WPF, there isn't even a direct route in via unmanaged code - you have to jump through all sorts of ugly interop hoops.

Answer 5

Integrity levels are also a good thing to learn about. Depending on the nature of your application, if it attempts to do anything involving other processes that are running on the OS, it is important to know about this. This technology prevents processes at a lower integrity level from interacting with processes that are running at a higher integrity level. This includes messaging, hooks, DLL injection, opening handles, and many other techniques.