Friday, July 18, 2014

"Invalid parameter" debug messages when using wxGLCanvas

While debugging a problem with wxGLCanvas today, I noticed that every run of the OpenGL cube sample resulted in several copies of the following message in the MSVS debug output window:

Invalid parameter passed to C runtime function.

Now this is an error message just as I love them: it's worrisome enough to make you feel like you ought to do something about it, but without any information allowing you to find out what, actually, should be done. Luckily, there are not that many ways to write to the debug output under Windows and putting a breakpoint on OutputDebugStringA() (surprisingly used instead of OutputDebugStringW() that I tried first) discovered that the debug message was given from deep inside GDI ChoosePixelFormat() function which ends up calling wglChoosePixelFormat() in opengl32.dll which, in turn, calls into ATI driver DLL (atioglxx.dll) which ends up calling _wcscpy_s() with a NULL parameter which is clearly a bug, but it's not our bug.

So, finally the problem is not related to wxWidgets, even if you will see it every time you use wxGLCanvas with (this, buggy, version of) ATI OpenGL drivers. But at the very least I now know that if I see this message again, I can set a breakpoint on {,,msvcrt.dll}__invoke_watson function, using MSVS debugger idiosyncratic syntax, and directly see where does the problem occur. Hopefully this can be useful to someone else too and maybe it will save you some time chasing bugs in ATI code.

Ah, and the original problem which started all this? It turned out to be bogus. Today hasn't been very productive so far...

Sunday, July 13, 2014

Some kind of a record

Today we closed two bugs in wxWidgets. Nothing surprising so far, except if you look at the bug numbers and realize that they are two thousand something while the latest ticket in the Trac is 16379. And these bugs were both opened more than 9 years ago, in February and May 2005 respectively. I'm sure that the fact that we are fixing bugs 10 years later must mean something, I'm just not sure what exactly. Do we not care enough about bugs to fix them so late? Do we care very much about them, enough to still fix them after all this time? Are we hopefully short on resources? Are we just very good at allocating our meagre resources efficiently so as to combine both bug fixing and still making some progress (which would never happen if we decided to not add any features until all existing bugs are fixed)? All of the above?

One thing is clear though: please keep reporting bugs in wxWidgets and if they seem to be ignored, know that there is always hope that they will be fixed one day. Next status report coming in 2050...

Monday, June 16, 2014

Which version of MSVS do you (still) use?

As you might know, we've recently dropped support for VC98, and now I've started thinking about which versions of MSVC we should support in wxWidgets 3.1.0 release. Even for 3.0, we only provide binaries for 2008 and later, and by the time 3.2 is out, Microsoft will probably have released at least a couple of more compiler versions, so we will probably have to drop at least it to from the list of binaries by then. I don't really think we are going to fully drop support for it though, doing it for only a 7-8 year old compiler would be quite out of character. But who knows?

And, in fact, I'd very much like to know more about the versions of the compilers that wxWidgets users really use. So here is a small poll, please take a few seconds to click on the earliest version of MSVC that you still use:

surveys

And, if you have any trouble with voting here, you can also do it directly from the poll page.

Thanks in advance!

3.0.1 released

We have just released wxWidgets 3.0.1, a bug fix release in 3.0 branch. The release files can be downloaded from either SourceForge or our FTP mirror as usual, and as less usual, but is the case for the last few releases, we provide not only the sources and documentation, but also the binaries for the selected Windows compilers.

This release is 100% compatible with 3.0.0, i.e. any code which compiled and worked with 3.0.0 continues to do so with 3.0.1 and so upgrading to 3.0.1 doesn't require any changes and hence is recommended for all 3.0.0 users: basically, without any extra effort on your part (even make or project files don't need to be updated as the libraries use the same names in 3.0 branch), you get more than a hundred bug fixes and improvements.

The release announcement has some details about the changes in this release, but there were really too many of them to list them all, so you should consult the description of the most important changes in the change log directly to really appreciate the scope of the work gone into this release (and the change log doesn't contain relatively unimportant fixes).

Finally, in addition to the bug fixes, if you are using Microsoft Visual Studio 2012 or 2013, there is an extra reason for upgrading to 3.0.1: this release includes the project and solution files for building the library with these compilers, so you don't need to upgrade Visual Studio 2010 projects manually any longer. These projects have been contributed by Artur Wieczorek and I'd like to use this opportunity to thank him for this and numerous other enhancements and bug fixes, especially in wxMSW, as Artur managed to eradicate many bugs that I couldn't fix since many years and is responsible for a good part of the 100+ bug fixes mentioned above. Thank you!

Monday, June 02, 2014

Help with testing 3.0.1

We plan to release 3.0.1 on June 15 (this year, before the jokes start coming in). There have already been a lot of changes since 3.0.0, with many important bug fixes in all three main ports, including tons of corrections to everything bitmap/alpha-related in wxMSW by Artur Wieczorek who managed to eradicate swathes of long-standing bugs, so we'd like to make these improvements available as soon as possible. However we'd also like to ensure that we haven't broken anything since 3.0.0. And while we are relatively confident that the ABI hasn't changed, the behaviour of the code is another matter and some new bug(s) could have been introduced in almost half a thousand commits since 3.0.0.

Which is why it would be really great if as many people as possible could test the 3.0 branch sources before 3.0.1 is done, in two weeks time. Regressions are usually found quite quickly after each release, which is great, but it would be even better if we could find at least some of them before releasing it. So if you are using 3.0.0, please grab the latest 3.0 branch sources using either Subversion (https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH) or Git and let us know if you see any new problems.

Thanks in advance!

Friday, May 16, 2014

Spring Cleaning

Everything comes to an end. Even support for MSVC6, a.k.a. Microsoft Visual Studio 98, which subtly hints at just exactly how old this compiler was. I wouldn't be surprised if wxWidgets were the last open source library to still support it 15 years after its initial release but now, finally, it's over and 3.2 release will require just barely ten year old MSVC7 or maybe even MSVC8 if nobody uses VC7 any more (but up to at least a year ago, some people were still actually using VC6, which is why it was, and remains, still supported in 3.0 release, although with quite some functionality not available for it).

In addition to dropping support for VC6, which was the really important change as it means we can, finally, write the code in wxWidgets itself in something resembling standard C++, we also officially stopped supporting Windows 9x (95/98/ME) in wxMSW port. Windows XP remains supported however as the differences between it and later Windows versions are much smaller than those with Win9x.

Finally, another port bites the dust: this time it was wxPM, the port of wxWidgets to OS/2. As far as I know, neither the port nor the platform itself are used since quite some time and the last real contribution to it dates from almost 5 years ago.

Edit: I am on a tear, since writing the initial version of this post, I've also removed support for the obsolete OpenWatcom and DigitalMars compilers as well as positively ancient (last century) MinGW versions. At this rate, there will be nothing left to remove soon, so I am going to really stop now.

All in all, a good day of work:

% git diff --shortstat master@{yesterday} 1756 files changed, 12868 insertions(+), 190758 deletions(-)

Monday, April 21, 2014

Accepted GSoC 2014 Projects Announced

wxWidgets is participating in the Google Summer of Code again this year and we are very glad to announce that this year 6 projects have been allocated for us, which is the most we have ever had!

We had many excellent proposals this year and unfortunately even in spite of getting so many slots, not all of them could have been selected, but here is the list of the ones that were:

  • Chaobin Zhang will add support for "new" (since Windows Vista) taskbar features under Windows such as progress display indicator, jump lists, buttons and so on.
  • Haojian Wu will integrate support for Chromium backend into wxWebView to provide a backend that could be used on all platforms in addition or instead of the native one.
  • Mariano Reingart will continue improving wxQt port and will look into the possibility of bringing wxWidgets to Android via Qt bridge.
  • Alexandru Pana will work on implementing Direct2D and DirectWrite-based version of wxGraphicsContext, which should result in much better performance and, for text output, quality than the current GDI+-based implementation.
  • Nikola Miljkovic will lay the grounds of wxAndroid port: this is the most difficult but also arguably the most exciting project.
  • Sun Boxiang will work on improving wxUniv port and in particular make it good enough to be used for simple UI under Android.

As usual, big thanks to Google for organizing the Summer of Code and best of luck to all the students!

Tuesday, April 01, 2014

Announcing the Great Rewrite

It has become increasingly clear during the last few years that the current wxWidgets code base is simply too out of date for the present day connected, mobile, cloud-based computing world. So, after a deep and careful consideration, we have decided to launch a new project, wxWidgets 2020, which will allow us to remedy this.

The major change to be done in the framework of this project is to switch the implementation language of the library. Clearly, nothing worthwhile can be written nowadays in anything other than JavaScript. While we unfortunately wasted our chance to port wxWidgets to Java in the nineties and thus completely missed the Java desktop revolution, we still can correct this by using JavaScript which, as a language, combines the unparalleled elegance and efficiency of Java with great scripting support (as obviously follows from its name). JavaScript is clearly the language of the future as in addition to the its brilliant success on the client side, it is now even displacing the pinnacle of software engineering which is PHP on the server side, thanks to amazing innovations such as reimplementation of the best features of Windows 3.1 in node.js. Moreover, by using JavaScript we will finally be able to increase the visibility of wxWidgets by hopefully appearing more often in security advisories, which was difficult for us so far due to the total lack of support for XSS and CSRF in C++.

Of course, we, wxWidgets developers, take the backwards compatibility seriously and so we have also thought of a couple of the current users of the library who might have some existing C++ code. Luckily, migrating it to wxWidgets 2020 should be easy to do as you'd simply need to recompile it using asm.js which will be proven to work flawlessly as soon as we test it. And if it ever doesn't, there is always the fall back solution of continuing to run the existing code unchanged inside a virtual machine running inside the web browser -- after all, the modern hardware is largely fast enough to allow doing this, and it would be a pity to keep these CPUs idle.

Finally, the most difficult aspect of this decision was, as usual, choosing the name. After a long and agonizing discussions, we agreed on 2020 which gives us a reasonable amount of time before the release (while releasing wxWidgets 3.0 did take more than 6 years, we are confident that things will happen much faster now that we have the magic of JavaScript at our disposal). And if we miss that deadline, we can always pretend that the name was just a play on "Web 2.0" (only twice as much). As you can see, we have thought of everything. Watch this space!