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)
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.
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.
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.
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.
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.
Related
It seems that the Win32 API (the C API for native Windows applications) is becoming more and more overtaken by more modern frameworks and toolkits, including Microsoft's own WPF and Qt.
If the programming language is not a concern -- if you're not set on a managed environment, or a functional programming style, etc. -- does Win32 API bring anything to the table? Is there any functionality that one can implement with Win32 API that's not available with WPF or other frameworks?
I know it's possible to mix Win32 code into WPF/managed software, so one doesn't have to choose one or the other. But what are some examples of needing to break out Win32 API when developing a program in a higher-level language/framework?
Another more specific example is "windows hooks".
I needed to hook some socket programs at some point and the only possible way was windows api.
To elaborate i wanted to receive all communication received on some listening socket on a different one. Doing this requires hooks
Certainly.
All the frameworks are written in terms of the Win32 API. The frameworks cover 80-95% of what programmers need to do, but if you need really low-level control over something, you'll need to drop to the underlying Win32 API. Some examples would be:
precise control over text rendering (via DirectWrite),
detailed control over speech recognition using SAPI (there are literally dozens of interfaces not exposed through System.Speech),
low-level networking code (i.e., anything not HTTP related),
Practically anything audio related, if you're interested in performance.
... and don't forget about direct hardware access like "WinUSB" and debugging functionality (writing programs that act as debuggers).
The Win32 API is nowhere close to be taken over by any framework at the moment.
If that was the case, most of the API would not be updated by Microsoft. Instead, lots of new interfaces are added and updated.
There are framekorks like Qt, but, unless what you need to create is trivial, you will eventually use the API, especially for new graphics libraries, audio, video, usb, ribbon, sockets, network, COM automation, biometrics, encryption, digital signatures, security, scripting, etc.
Actually, most libraries are quite outdated and, while you can create an application that relies mostly on worker threads and not on the interface, building a nice, modern and useful application today certainly requires the API. So investing on a framework that would only cover a minimum part of your application is not worth the learning curve, these frameworks mostly target really new and unexperienced windows developers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
On Windows there a few libraries that allow you to intercept calls to DLLs:
http://www.codeproject.com/kb/system/hooksys.aspx
Is it possible to do this on Mac OS? If so, how is it done?
The answer depends on whether you want to do this in your own application or systemwide. In your own application, it's pretty easy; the dynamic linker provides features such as DYLD_INSERT_LIBRARIES. If you're doing this for debugging/instrumentation purposes, also check out DTrace.
You can replace Objective-C method implementations with method swizzling, e.g. JRSwizzle or Apple's method_exchangeImplementations (10.5+).
If you want to modify library behavior systemwide, you're going to need to load into other processes' address spaces.
Two loading mechanisms originally designed for other purposes (input managers and scripting additions) are commonly abused for this purpose, but I wouldn't really recommend them.
mach_inject/mach_override are an open-source set of libraries for loading code and replacing function implementations, respectively; however, you're responsible for writing your own application which uses the libraries. (Also, take a look at this answer; you need special permissions to inject code into other processes.)
Please keep in mind that application patching/code injection for non-debugging purposes is strongly discouraged by Apple and some Mac users (and developers) are extremely critical of the practice. Much of this criticism is poorly informed, but there have been a number of legitimately poorly written "plug-ins" (particularly those which patch Safari) that have been implicated in application crashes and problems. Code defensively.
(Disclaimer: I am the author of a (free) APE module and an application which uses mach_inject.)
Is there, by chance, an emerging Haskell UI framework for Windows?
I recently took up looking over the language, and from what I see, it would be for great little "one-off" applications (elaborate scripts).
However, without a good UI framework I can't see it getting in under the smoke and mirrors of the more obvious contenders.
I've read that there are many frameworks, but none are full-featured.
I'm just wondering if this is something that's on the rise, or is it simply too difficult to get enough developers going in the same direction with one?
The two main frameworks are wxHaskell and Gtk2Hs. Both of these have been used for real work. From what I know my preference would be Gtk2Hs because it handles resources properly (i.e. uses the GC). wxHaskell requires the programmer to release widgets once they are no longer required, so you can get all the classic memory leaks and stale pointer screws with it.
The problem with both is that everything is in the IO monad. This reflects the fact that they are comparatively thin wrappers around existing GUI libraries for imperative languages. Of course this means you are no worse off than you would be writing a GUI in an imperative language, but you are hardly much better off either.
There are some interesting experimental libraries to be found on Hackage, including Grapefruit and Conal Elliott's "Tangible Values" ideas in GuiTV. Both of these try for a more declarative approach.
(Disclaimer: I am the wxHaskell maintainer)
Both wxHaskell and Gtk2Hs are more or less complete. That's to say, both wrap a great deal of the functionality provided by their underlying libraries. They also both, as mentioned earlier, require a rather 'imperative' style of programming in the IO monad.
There have been many discussions on the relative merits of each. I would say that wxHaskell is the easier of the two to get working, especially on Windows, as it can be installed via cabal (see http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)
The FRP frameworks (Grapefruit and others) provide a more 'functional' style of programming, at the cost of having much reduced widget coverage. I have the feeling that this is still an open research area, and not really ready for 'prime time'.
In practice, I've never had resource management issues with wxHaskell, although I agree that it's possible, and is an area handled better by Gtk2Hs, which uses reference counting in the underlying library.
For completeness, I should also mention that a Qt binding (QtHaskell?) also exists - it is relatively young, but apparently reasonably complete.
I rather feel that the Haskell community, small as it is, would do well to fix on one GUI framework, but accept the difficulty of this (e.g. licensing, support for all OS platforms etc.).
Also you can use wxWidgets (i mean C++ library) with Haskell. Here is an example: https://bitbucket.org/afiskon/hs-a-star-gui/src Such approach has some advantages over wxHaskell: 1. You can use UI generators (Code::Blocks, wxFormBuilder) 2. Your application takes less disk space 3. You can use all features of wxWidgets.
It should also be noted, that last version of wxHaskell uses wxWidgets 2.9, which probably will never be ported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431
Are you choosing not to use managed code for any new applications for Win32? Why? Are there resources you need that aren't available from the CLR?
(Note "New" - not enhancements to existing codebases.)
One significant reason is ease of deployment. I can build a Win32 application (using MFC or WTL libraries), and with static linking there are no dependencies on external libraries (yes, I know that static linking is not the recommended approach).
Users can install and run this application without having to install anything else first: no framework library required, and no DLL hell. For comparison, read these posts from the author of Paint.Net to see how painful it can be for a user to install a .Net application.
I guess my last reason to write Win32 is portability. C++ compiles on all platforms, simply and without crazy dependencies. So for portable code, I still end up needing to access Win32 for the GUI.
I'm not bypassing .NET to do Win32 programming. I am bypassing both of them to do Java programming since I want my applications to run on as many platforms as possible. Windows may control a majority of the market but I don't see any reason to cut out even small possibilities for profit, especially since I can write Java code much faster than C++ or C# (that's based on my ability, not a reflection of the languages themselves).
Neither .NET not Win32 give me that cross-platform ability at the moment. They may eventually, with Mono, but I still consider that less-than-production-ready and there's still a question over its future in my mind.
At my workplace there are some old-timers who prefer using MFC because that's what they are familiar with. A few days ago we were to create a simple app and, naturally, they wanted to whip it out in MFC. Only that "whipping out" would have taken about a week and we needed the app in a day. I can't really blame them - old habits die hard. Eventually we went with C# and let the MFC-ers fiddle with the GUI design (which they much appreciated).
Yes and no. I use C++/CLI if I need to do any Win32/COM stuff. C++/CLI is wonderful. Our UIs are entirely .NET, but occasionally we do have need to use straight C++.