How soon does Qt support the newest version of Microsoft Windows after Microsoft starts selling them?
traderdev last edited by
To the long-time Qt Windows developers out there:
I am an MFC developer who is highly considering switching over to Qt, but I am worried that when "Windows 9" or "Windows 10" comes out that a Windows-only Qt app won't work on the newest version of Windows until the Qt programmers can get a new release out a few months after Microsoft ships "Windows 9" or "Windows 10".
Looking back at the history of Windows ship dates, how long after Microsoft started selling each successive version of windows (Windows XP, Windows Vista, Windows 7, Windows 8, Windows 8.1, etc.) did Qt applications work on the newest Microsoft OS?
Has there ever been a delay between a Microsoft Windows desktop OS ship date and the date when Qt apps could work on the newest version of Windows, or was it always possible to rebuild your Qt application on the newest version of Qt and publish a version of your application that was compatible with the newest version of Windows on the Windows launch date?
If your answer depends on which features I will need: my app will be like a drag and drop diagramming or drawing app (like Visio or Microsoft Paint), with a lot of painting to the screen and some basic edit controls (property grid, text box, context menu, etc.) and the user will be able to save their diagrams or drawings, load them, edit them, etc.
Thanks in advance!
I will answer in two ways:
There is no delay at all. Qt applications compiled for Windows XP continue to work on Vista, 7, 8, 8.1, without any need to compile them again. However, MS usually updates the default UI style, and that sometimes needs to be updated in Qt, too. In such cases, the first release after the release of new Windows usually contains all the necessary changes (the more developer preview builds MS releases, the better: Qt devs can prepare in advance). New Qt version is released every 6 months (with 1-3 patch releases in between. Those can bring support for "refreshed" Windows style)
If MS does something nasty (think WinRT/ Metro/ Modern UI), it takes much longer to bring in support, sometimes ever a few years
In general,Windows runs applications that have been compiled in previous versions of Windows, as long as they don't use any dirty tricks. The Windows API is pretty stable, and usually does not break old interfaces.
A case in point is a shareware painting program that I use since Windows 3.1, which still works on Windows 7. It just looks old-fashioned.
I am not aware that Qt uses dirty tricks with the windows API that would hinder migration. For example, Qt applications compiled on Windows XP will run fine on Windows 7.
traderdev last edited by
sierdzio and Asperamanca,
Thank you both for the excellent information, and for taking the time to help. You answered my question perfectly.
This is the best answer I could have hoped for. This means that Qt apps are no less forward compatible than MFC apps on Windows, since WinRT wasn't meant to be compatible with old desktop apps anyway! Fantastic!
I keep looking for what is wrong with Qt, like "what's the catch", and I keep coming up with nothing!
Thank you both again,
Well, what's the catch? (Take this with a grain of salt, it's coming from a heavy Qt user and fan)
- For some people, the licensing options may not be what they need.
- If you need the utmost performance, working on a lower level may be the way to go
That said, I am developing an application that sounds similar to what you are doing (basically a graphical editor for inserting and editing pre-defined objects as well as graphics and text). I am using GraphicsView, and am very happy with it.
In some cases, if you really need a very specific behavior, you either have to write loops around the Qt code, or change the Qt sources and compile it yourself. But that's no different to any other library I know - except that with MFC the 2nd option isn't available.
msue last edited by
Well with the VS compiler you have at least the MFC sources, but - as there is no solution-file (.sln) for them - you have no easy way to compile them yourselves and - I assume - also not the right to distribute self-compiled versions of them.
But many things are changing: MS made parts of .NET open source begin of this year, and removed the license catch that it may only run on WINDOWS. There may come other surprises as well.
Interesting. An old dog learning new tricks? I like.