So, the time has come to say goodbye to the good’ol non-unicode Windows systems.
Qt has for a very long time had the QT_WA/QT_WA_INLINE(uni, ansi) macros to provide support for both Windows ANSI systems and their Unicode equivalents, and thus supported running Qt applications on old Windows systems without the MSLU (Microsoft Layer for Unicode) installed. It was in our plans to ditch the ANSI code for Qt 4.6, and take the chance to clean up our code, making it more maintainable for the future. With the upcoming Windows 7 I’m sure we’ll still have our share of special-casing the various Windows versions, so it’s time to ditch the old platforms which Microsoft themselves haven’t supported since 2003 (mainstream support ended in 2003, while extended support ended on 11th of July 2006, 3 years ago).
Right after the launch of our contribution model, Milan Burda contacted me and asked if there were any projects open which he could help out with. Within a few days he had whipped up a series of patches, totaling a 15K line diff, which successfully removed the old ANSI code from Qt. And now, after some reviewing, splitting, reorganizing and squashing, and auto-testing of the rebased version of his commits, these patches have finally made it into Qt’s mainline.
Unfortunately, in the reorganization process I failed to maintain the authorship on some of the splits; but rest assure that the whole series, with the exception of commit cfadf08a, is all his! Great work Milan, thanks!
PS:
Should we have, despite the review and auto-test process, and introduced any regressions, please add “[ANSI regression]” to your bug report subject, and I’ll keep a keen eye on those when they come in. As Qt mainline is not a supported release, please use the web form to send these requests.
8 Responses to “Win9x/ME no more..”
*salutes*
Windows 9X:
Gone, but unfortunately, not forgotten.
Why you are removing support for my favored Microsoft system ?!?!?
Is there any affection to the WinCE ports with these patches. I’m not familiar with WinCE, but it likely isn’t UTF-8 either, isn’t it?
Windows CE has all ANSI functions wiped out since the initial release. A few came back after huge request from the development community. But generally speaken, that change doesn’t affect Windows CE at all.
Positive thing is, that we from the Qt for Windows CE team now don’t need to bother about ancient Windows versions anymore, when we need to use native calls.
No program can be called portable unless it has Windows 3.11 version. 64-bit correctness? Win32/Posix differences? Win32/X11/Cocoa graphics API differences? Endianness/structure packing differences? Compiler can’t grok template magic? Come on! That’s EASY !!! Try to do it like the real men do it: keep distinction between NEAR and FAR pointers, allocate your memory in (at most) 64 kb chunks and remember to divide your work into manageable chunks, because other applications want repaint their windows too! COME ON, YOU WUSSIES !!! PROVE YOURSELF WORTHY !!! MAKE WIN 3.11 VERSION OF QT !!! After this, you are ready for AVR port.
So the last version of Qt that supports 9x is/will be…4.5.N?
good to see a proof that Qt is really open to contributions 
@Seb: Windows CE is UTF-16, and this cleaning up actually helps the CE port, since there are less code duplication and ifdefs
@Forrest: You are correct. The Qt 4.5.x series is the last to support Windows 9x/ME/SE. However, we have not tested the current mainline, which will become 4.6 on Windows 9x/ME/SE with the Unicode layer installed. Feel free to try this and let us know how it goes.
@shamaz: Indeed. We love external contributions! And it’s the perfect chance to get something implemented/fixed which the Qt team otherwise doesn’t have the man-power to fix themselves.
@zarazek: We accept patches; but Windows 3.11 I think you can forget.