Related
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.
I have a few years of experience writing Unix command line tools (no GUI experience) in python, C and C++, and only recently crossed into the GUI world (Cocoa and IOS only). I've learned quite a bit of objective-C and am getting to understand how cocoa MVC works. However, one of the apps I am developing needs a Windows version and I was wondering what a good place to start would be given that I have absolutely no Windows development experience.
I was thinking about using Visual C++ 2010 Express as my development platform (because it's free and because I don't need to learn C++). My application is relatively simple, it will have only two windows and spend most of the time running in the background. It will however need to communicate with the OS (load dll's etc) and an online server (HTTP methods) and I'm not sure whether Visual C++ Express edition gives me access to the required API's. Would a Windows Forms application suffice? Am I going about this the wrong way? Do I need to learn C#? Any advice will be appreciated.
If you are already happy with proper c++, visual Studio C++ express should suit you fine. Given that you are not making a complicated GUI, you don't even need to dip into the managed code - C++ express allows you to create proper c++ console and GUI apps. You also don't need to install the platform SDK - it is part of VS C++ express.
Not being managed C++, you will be able to share source files between your various projects. managed c++, despite the c++ in the name, really is a different enough language that it will be annoying to work with if you simultaneously have to deal with iso C++.
--
Note: The native windows API is a C api, not a C++ framework. So it does not provide a rich set of classes in a coherent framework to deal with. On the other hand, while, large, it is actually quite simple to work with.
Also: Given that you are already familiar with Mac development, there is a LGPL (iirc) package called CFLite that builds on windows and that implements the C api that underlays the Objective-C Cocoa API.
If you use its abstratcions you can share a greater part of code between windows and Mac (and other platforms).
Other C++ IDE's you might want to consider:
Code::Blocks
QT Creator
both of which can be configured to use the MINGW port of GCC to windows.
you'll be better off with c++ than c# if you need more "low-level" stuff. Loading dlls (that is, libs) is simple (pragma comment lib...), as is pure HTTP transfer and communication.
So, VC++ with windows form will suffice, and it is "very c++".
You have access to all global APIs, and loading specific apis like http requires only two lines: one to include wininet header, and other lib (libs are actually "references" to dlls).
If you go the C++ Express way then you need to install Windows SDK separately, and set it up for Visual Studio to use it. And you can't use MFC.
I would however, suggest C#, because it feels like putting little toy bricks together. Easier to debug and maintain. Problem with C# is that it has so many library functions that you can not possibly know if what you want is already made to a function. But that's why we are here :-) If you feel that something you want to do should already exist then ask a question about it. One notable feature that C# lacks is zip archives (it has something similar, but not quite). For zips you can use public libraries, like SharpZipLib or DotNetZip.
If I were you, I wouldn't jump into a whole new API so quickly. Have you considered using Python on Windows? Most of the Python packages I've seen are also available for Windows, so you'll feel at home. And if you need some GUI, you can opt for wxPython, pyGTK or something similar.
For Windows specific things, you can always use ctypes. Especially if they're as simple as loading a DLL.
have you considered approaching Adobe AIR? it allows you to deploy on Mac, Linux, Windows, iOS, etc. communicating with and launching native processes has been possible since 2.0 and the the latest 2.5 SDK can target Android OS and TVs. with your experience you should be able to pick up ActionScript3 / MXML in no time.
additionally, there are a handful of free IDEs you can use with the Flex and AIR SDKs. or, if you're a student or low-income developer, you can get a free copy of Flash Builder 4 from Adobe: http://www.adobe.com/devnet-archive/flex/free/
edit: i believe deploying AIR applications on iPhone requires Flash Professional CS5, which includes the packager for iPhone options. at the same time, i've read that AIR and other cross-compilers for iOS are painfully slow, so it's perhaps best to develop natively in Objective-C for iOS.
Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
Update1: 2012-12-17:
While native C++ still isn't officially supported for Windows Phone 7, Windows Phone 8 now supports native C++ code so you can more easily port your existing C++ codebase(s) to Windows Phone 8 (as well as Windows 8 and Windows desktop apps).
While there isn't 100% compatibility between the Windows8/Phone8 platforms and API's right now, I expect the two platforms to become increasingly integrated over the next couple of releases.
This is especially true now that one of the key barriers to closer cooperation between Windows and other groups at Microsoft recently left the company ;)
Update2: 4/15/2014:
As per the recent announcements at //BUILD/ 2014, you can now start building "universal" apps in C++ & XAML, C#/VB & XAML or JavaScript & HTML that will run on Windows 8.1, Windows Phone 8.1 and Xbox One! For more details on building Windows Phone 8.1 Universal Apps, read this article.
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port.
We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
It is on the horizon finally!
So a survey sent to windows phone developers about their future
development preferences and XNA isn't mentioned once in the Survey (A
survey sent to windows phone developers - did I mention that)
They do however ask:
How would you prefer to use C++ in your mobile apps/games?
Develop apps/games that are C++ from top to bottom (UI, business logic, and platform
APIs)
Use C++ for business logic and then write platform abstraction layer
Use C++ for business logic use 3rd party runtime engines
I don’t want to use C++
For the last few years i have been working as a web developer. So my desktop development skills are a little rusty. I am aware of Adobe AIR, winforms, WFP and silverlight 3.0. I was wandering what other UI frameworks/technologies people are using to implement desktop applications.
Depends on what you want to do. Some of the bigger toolkits for creating GUIs (among others) are QT (http://www.qtsoftware.com/products/), GTK (http://www.gtk.org/) and wxwidgets (http://wxwidgets.org/). Each of them allows you to code in a couple of different languages and use the GUIs on different platforms. There are plenty other toolkits though, which might fit your needs better (eg. more leight-weight ones).
AIR is pretty cool, I've enjoyed writing projects for it as there are a lot less limitations compared to winforms. winforms is quick and easy to use though in Visual Studio.
I think the list you've got is pretty good to start with.
Chrome. Our "desktop" UI is browser-based.
there's lots of different GUI stuff, SWING for java and .net forms are common.
besides what you listed, you'll also hear about Win32 and MFC (both c++), Tk (which is common with scripting languages like perl/python), the hardware languages OpenGl, glu, and glut (cross platform), DirectX (windows), and X Window System (X11) on linux (and Mac) and Cocoa and Carbon on Mac.
There are many others, but these are ones that I've seen used regularly.
WinForms is the default platform used to develop desktop applications using .NET framework (and Visual Studio 2002, 2003, 2005 and 2008). It's really a wrapper around the Win32 API that deals with CreateWindow and managing the messages sent to that window.
WinForms uses GDI/GDI+ technology while WPF (an exciting new platform offering a LOT of potential) utilizes GDI/GDI+ and DirectX (some parts at least, such as bitmap effects, transitions, fading).
Silverlight is a toned down Web version of WPF. Silverlight 3.0 allows developers to create a rich internet experience without the need to run the application inside a browser. Definitely something to keep an eye out for!
In terms of GUI design, I depend heavily on QT right now (py and c++ QT).
I recommend an excellent book: Rapid GUI Design with QT
I haven't tried it yet, but JavaFX sounds pretty cool.
It depends on the langage and the platform you're programming for. For C++, you can use either : Qt and its RAD tool: Qt designer, GTK+ / gtkmm or wxWidgets among others..
I'm a C programmer with lots of server code experience (AIX, HPUX, some Linux) I need to write a GUI program for Windows (2000, XP, Vista, 7) which requires CAD-like drawing functions and lots of data entry forms (it's a specialised engineering app). I've written some Win32 code many years ago using Gupta SQLwindows (now Centura Builder). The bosses have decreed that it "must be" compiled code. My perception is that C+SDK could do the job but with considerable effort and that C# + Windows Forms would be more capable, but I'm a bit concerned about the .Net framework requirement.
Based upon your experiences, What would you suggest?
If .Net, which version? 2.0, 3.0, 3.5 ??
I'm not familiar with Centura Builder, so I am not sure at what level of abstraction your prior Windows programming experience is. If you choose the native code route using C/C++ and Win32, be sure to buy a copy of Programming Windows by Charles Petzold. Reading the first few chapters of this book can help you decide if you want to go the native code route as well.
If you choose the .NET Framework and C#, and if you do not need the version 3.5-specific features (such as LINQ for database access), I recommend choosing version 3.0. It is a built-in component on Windows Vista, so you don't have to package the runtime with your program installer unless you have to support Windows XP (which you probably do, so never mind :). With version 3.0, you get Windows Presentation Foundation (to use instead of or along with Windows Forms), which gives you a lot of graphical capability without a lot of effort. I'm not knowledgeable about CAD, so I don't know if WPF would provide the drawing functions that you need, but it may provide a great platform upon which you can write your own drawing routines.
EDIT: I missed your Windows version requirements on first reading, particularly the Windows 2000 requirement. I guess you'd have to go with .NET Framework version 2.0 and Windows Forms. I have to ask, though: Wouldn't it be cost-effective to improve your engineers' productivity by upgrading their eight-year-old machines to something newer and faster and therefore get rid of your Windows 2000 support requirement?
If you're going the .NET route, you will have to use .NET 2.0 because .NET 3.0 and above is only supported for Windows XP and above (Vista, 7, 2003, 2008).
I personally wouldn't sweat the .NET framework requirement. It's a one time install on each machine, that can be streamlined through Windows updates if needed.
If you don't want .NET, Qt + C++ is definitely the way to go; it certainly beats C and Win32. .NET still allows much faster development than even Qt though. Qt has the advantage of being fast and easy to deploy (no .NET requirement), and makes portability much easier (if you want to port to Linux or Mac).
If you must use native code then I would strongly suggest RAD Studio from Codegear / Embarcadero, it's a studio product that ships with Delphi (the object oriented language that evolved from Turbo Pascal) and C++ Builder, if you are already familiar with C/C++ then it's going to be very simple for you to pick it up. The Visual Component Library that is shared by both languages is extendable, powerful and RAD.
If you are able to use Managed code, then C# with Winforms is easy to use, WPF may be a better UI choice long term, but it has a steeper learning curve.
Depending on the complexity requirements of the CAD-like drawing, I'd go with C# + Windows Forms, or even more preferrably, C# + WPF.
WPF would make the drawing much, much cleaner than trying to do it in GDI. This is especially true if you're going to do some 3D "drawing", as you can do a lot of (simple) 3D objects directly in WPF. C# will make your GUI programming much more productive than trying to do it in C/C++ with the windows API directly (or even MFC).
Personally, the .NET requirement is minimal in my opinion, but that's really up to the powers that be in your organization...
If it must be compiled code than I would recommend WTL of MFC but it would be much more faster (in terms of develeopment cost) to use C# + WinForms or WPF.
You can do everything with C or C++ / Win32 api
(Win32 samples for CAD-like drawing are in MSDN..)