definitely true, but still we kept seeing a bunch of bug reports
after each release - and I'm not sure if we even had any RC testing period during the last release cycle ?
Also, Gijs doesn't really count as a regular end user, despite him using Windows - he's probably building from source and is a long-time FlightGear contributor and developer. So basically we need to get more people involved, especially Windows folks.
Personally, I also don't really use Windows very often - usually, FredB helped a lot with Windows testing, but he seems to be busy at the moment. And I think TheTom also had to use a VM or dual-booting to test canvas things on Windows.
While do know how to build FG from source, I still find it to be a major issue on Windows, but I promise to look into it again once I find some time to look into your superbuild stuff.
On the other hand, it's a matter of exposure and wide-spread testing, too - most "developer-minded" users wouldn't use path names like those causing these problems here, most us grew up in times where a file name was 8 characters + 3 for the extension
Now, apart from adding 3rd party debugging libraries like BreakPad to FlightGear, one of the more straightforward things to try would be using the built-in HTTP client support (either the xmlhttprequest fgcommand or Tom's new cppbindings) to make the SG_LOG() macro post critical errors (SG_ALERT and above) to some pastebin (or even the wiki), so that we actually get some information - even by people just running the software, without them having to be involved in the forum, issue tracker, devel list etc.
I think libz is linked in anyways, so compressing logs and uploading them would be an option to get more reports from our uninvolved Windows users