Dave Pickles asked for some support on the implementation of FormatMessage, with the FORMAT_MESSAGE_FROM_SYSTEM option. This allows error codes (for example) to be presented in a more human readable fashion.

One issue raised was the way to create the message tables (there are resources anyway, so can be added to any module). Bertho Stultiens pointed out that they are not implemented at all. MS has a separate message compiler and I did not want to implement that yet.

However Uwe Bonnes (and Dave later with some code) proposed to store (at least for the system message table - the one containing the textual representation of system error codes - to use some arrays (two indexes are used: message ID and language ID). However, all agreed that providing a message table compiler would be a neat thing to have.

Andreas Mohr, while toying with a code example from Petzold's Windows Programming book, ran into some bad behavior in Wine.

After some investigations (from Corel's Serge Ivanov and Thuy NGuyen), it turned out that the program had the same behavior under Windows...

Anyway, Andreas posted a patch to enhance EndDialog() behavior regarding bad window handles.

Ian Schmidt reported two bad Wine quotes from the News: The added layer of Wine code--an open source implementation of Windows 95/Microsoft Windows NT application programming interfaces--causes native Windows applications to run more slowly and with less stability on Linux, says Richard Manly, director of product marketing for Applix.

You can find a full article from PC World.

Later on, Linux Today posted also it appears Corel has switched gears and will now ship PE binaries as their final product. That's pretty discouraging for WineLib - could we get a post-mortem from someone at Corel?

Applix, and some of its products, can see in Wine a competitor. So spreading FUD (Fear, Uncertainty, Doubt) about it is an usual marketing practice. However, that's rather a good thing that commercial entities start being negative at Wine: it's a sign Wine is getting better and better !!

Alex Korobka reminded with an old issue (#6) with a reference to WinTach running on Wine that indicated that drawing functions were more or less on par with Windows but window manipulation was a lot slower.

Jeremy White from CodeWeaver put up a $2.500 CoSource request to run properly WinBench 99 under Wine: It would be nice to have some real data to counter the FUD (or at least some real data to indicate what work we have to do).

Corel's Gavriel State gave the last word Just watch our tree - we're putting lots of guns on optimization now. 8-), and regarding the future of WineLib (versus running Windows code, aka PE loader):Purely a matter of timing - several things we wanted to see weren't coming together in time, so for the initial release we're using the PE loader. It really makes no difference whatsoever from a performance perspective, it's purely a user perception issue. It's doubtful that users of our suite will even know they're running it under WINE unless they run a 'ps'...