I would really like to second almost everything that andreaplanet wrote, but for additional, different reasons. I work for a company that still supports for some old, not yet retired products, Windows 95 2nd edition up to Windows 7 now with latest and greatest builds. We heavily rely on a custom log file infrastructure that our support personnel uses to analyze what's going on on customer sites. We are talking about a product that runs on dozens of millions of corporate desktops and servers world wide, 24x7x365. As long as an app of ours will not be able to write to its log file, that it runs on Wine, instead of, say XP, no support personnel of ours will be able to distinguish real Windows XP from Wine's "illusion" of Windows XP, so we will never be able to support Wine, period, end of story. In a private project of mine I currently follow this approach: Users will have to specify the Wine version they are running, as a command line parameter. If they don't, the app will either not work or crash with current versions of Wine. There is no other way, otherwise I cannot work around limitations that Wine has, but I believe will not get fixed any time soon, given the fact that I submitted bug reports almost a year ago. It would be a helluva lot easier if there were a way to get the Wine version and let my app apply its compatibility code paths with a priori knowledge it has about certain Wine versions. Hey, I have to do the same thing for Windoze9x vs. NT vs. Windows 2000 vs. XP vs. W2K3 server vs. ..... why does Wine make it so hard for me to help my apps make the best use of it? -- Stefan
