While testing my Win32 application under wine, I came to the conclusion that some bit-blit ops behave differently from when the same code is running under native Windowds. While the subject will be researched further, as a stop-gap measure I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test?
tia, crd
On Fri, 2005-06-17 at 01:39 +0000, cdr wrote:
While testing my Win32 application under wine, I came to the conclusion that some bit-blit ops behave differently from when the same code is running under native Windowds. While the subject will be researched further, as a stop-gap measure I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test?
This is something that we strongly discourage. You can just add a simple hack for now in your code, while we try to fix it properly in Wine. If you describe the problem, we may be able to fix it fast enough for your purposes.
Hi,
On Thu, Jun 16, 2005 at 09:55:13PM -0400, Dimi Paun wrote:
On Fri, 2005-06-17 at 01:39 +0000, cdr wrote:
While testing my Win32 application under wine, I came to the conclusion that some bit-blit ops behave differently from when the same code is running under native Windowds. While the subject will be researched further, as a stop-gap measure I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test?
This is something that we strongly discourage. You can just add a simple hack for now in your code, while we try to fix it properly in Wine. If you describe the problem, we may be able to fix it fast enough for your purposes.
Indeed, and we also have http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE for that.
Andreas Mohr
Andreas Mohr wrote:
...
I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test?
This is something that we strongly discourage. You can just add a simple hack for now in your code, while we try to fix it properly in Wine. If you describe the problem, we may be able to fix it fast enough for your purposes.
Indeed, and we also have http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE for that.
(I assume the above was meant to read ...we also have [... need] for that...?)
Indeed.
With due respect for wine developers and their excellent work, this may be worth reconsidering.
Wine used to be almost exclusively for end users who had win32 applications (binaries), and wanted to run them under Linux, not only without any help, bu almost "againt the will" of the developers of those applications. I am, on the other hand, a different animal (and, looking around me, I notice my part of the zoo expanding...): a developer who would *like to help* my end user to run those applications under Linux. However, I can not possibly justify a complete re-write. Since wine is (and will remain forever) less than "100% windoze" (we can argue the numbers, but not the principle) the more I can be given a "helping hand" to deal with those residual differences, the more I'll be able to make my Win32 apps available to Linux users.
(int WinelibVersion(); that returns yyyynn - Please, please...)
cdr
Le vendredi 17 juin 2005 à 14:13 +0000, cdr a écrit :
Andreas Mohr wrote:
...
I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test?
Do it the Microsoft genuine downloads'way, even if that's not very robust... Just check for HKEY_CLASSES_ROOT/Software/Wine in the registry.
From: "cdr" cedar@3web.net
(int WinelibVersion(); that returns yyyynn - Please, please...)
We don't support such a thing officially because it will hurt the project: it's always easier to work around stuff rather then fix it properly. And the result will most likely be crippled and people will hate it.
That being said, if you *really* want to do it: -- at compile time: #ifdef __WINE__ .... #endif
-- at runtime: if( GetProcAddress(LoadLibrary("kernel32"), "wine_get_unix_file_name") { ..... }
Dimi Paun wrote:
if you *really* want to do it: -- at compile time: #ifdef __WINE__ .... #endif
-- at runtime: if( GetProcAddress(LoadLibrary("kernel32"), "wine_get_unix_file_name") { ..... }
much appreciated, cdr
cdr wrote:
much appreciated, cdr
Now... would you tell us what the misbehaviour in Wine is your application suffers from?
Since bitblt isn't exactly rocket science this one should be easy to fix... (no?)
Felix
Felix Nawothnig wrote:
cdr wrote:
much appreciated, cdr
Now... would you tell us what the misbehaviour in Wine is your application suffers from?
Since bitblt isn't exactly rocket science this one should be easy to fix... (no?)
It is on my "todo" list. But you must understand our difference in perspective:
You believe my end user should upgrade to new versions of wine where these things are fixed. I believe that if I tell my user: upgrade wine, or forget running my app, I'll be the looser. I will simply not say that to my user, period. Thus, I need to know *both* that I'm running under wine and under what yyyymmdd release "stamp" (BTW, pls keep it that way: it sooo much better than a "version number").
cheers, cdr
cdr wrote:
Now... would you tell us what the misbehaviour in Wine is your application suffers from?
It is on my "todo" list. But you must understand our difference in perspective:
Alright then, I don't think anyone cares if your app has a workaround for a bug which is no longer present in current Wine. :)
Felix
On Fri, 17 Jun 2005 11:19:27 -0400, Dimi Paun wrote:
We don't support such a thing officially because it will hurt the project: it's always easier to work around stuff rather then fix it properly. And the result will most likely be crippled and people will hate it.
That's one side of the coin, the other is that perfect is the enemy of the good. We already lost/pissed off one project, the VST Wine plugin stuff, because we released new versions that broke their software and they couldn't even programmatically check to give nicer warnings.
Realistically, not everybody can fix Wine even if they wanted to. Once you get into the swing of it, it's easy to forget what the learning curve is like. In this case I think a wine_version symbol really would be useful and wouldn't hurt the project much at all.
thanks -mike
From: "Mike Hearn" mh@codeweavers.com
Realistically, not everybody can fix Wine even if they wanted to. Once you get into the swing of it, it's easy to forget what the learning curve is like. In this case I think a wine_version symbol really would be useful and wouldn't hurt the project much at all.
Personally I think we can export a wine_version() function once we hit 0.9, but it's a bit pointless before then. And we are not that far away, in theory we should have one in Q4.
Now, we just have to convince Alexandre to add the export :)
Mike Hearn mh@codeweavers.com writes:
That's one side of the coin, the other is that perfect is the enemy of the good. We already lost/pissed off one project, the VST Wine plugin stuff, because we released new versions that broke their software and they couldn't even programmatically check to give nicer warnings.
Come on, please let's not bring this up again. The bug got fixed as soon as they reported it, and it was *never* part of a released version, so no amount of version checking could have made any difference. Of course checking for the actual bug would have worked, and would have continued working once the bug was fixed. That's the right way to handle that sort of problem, and it doesn't require any version info at all.
On Fri, 17 Jun 2005 22:01:11 +0200, Alexandre Julliard wrote:
Of course checking for the actual bug would have worked, and would have continued working once the bug was fixed. That's the right way to handle that sort of problem, and it doesn't require any version info at all.
Sure, that's a better way to do it when it's possible. I can't quite remember the details but I think the change there was that the wine_init prototype changed so calling it messed up the stack and caused a crash. How would one check for this type of thing?
Good point about it not being in a released version though. I'd forgotten that.
thanks -mike
cdr cedar@3web.net writes:
Wine used to be almost exclusively for end users who had win32 applications (binaries), and wanted to run them under Linux, not only without any help, bu almost "againt the will" of the developers of those applications. I am, on the other hand, a different animal (and, looking around me, I notice my part of the zoo expanding...): a developer who would *like to help* my end user to run those applications under Linux. However, I can not possibly justify a complete re-write. Since wine is (and will remain forever) less than "100% windoze" (we can argue the numbers, but not the principle) the more I can be given a "helping hand" to deal with those residual differences, the more I'll be able to make my Win32 apps available to Linux users.
(int WinelibVersion(); that returns yyyynn - Please, please...)
While clearly the best approach is to fix Wine, I think we can all agree that this isn't always an option. This does *not* mean that you need a WinelibVersion() function, or even a Wine check at all. What you should be doing is find a way to check for the bug itself, not blindly assume that because it's Wine such-and-such version it has the bug.
If you look at the Wine code we have quite a number of workarounds for glibc bugs; not a single one of them checks the glibc version, they all check for the actual bug. As a result we do the right thing whether or not the bug is here, no matter what games distros play with glibc versions and patches.
A version number is even more meaningless in the free software world, since anybody can release modified versions. There simply isn't a linear progression of versions that can be numbered. For instance, the current Crossover release is based on Wine 20040716, this is what a wine -v will report. Does it mean it contains a certain bug or not? You have no way to tell. Some fixes have been merged, others have not. Of course we could make Crossover report a different version, but then it means your app will need to be updated everytime someone releases a modified Wine.
So yes, it's a bit more work to do this right and test for bugs instead of versions, but in the end everybody is better off: you because your app is more robust and won't break as soon as someone changes something in Wine, and us because we can fix the bug without having to worry about breaking apps that assume the bug is here just because they are running on Wine.
-
Alexandre Julliard -
Andreas Mohr -
cdr -
Dimi Paun -
Felix Nawothnig -
Jonathan Ernst -
Mike Hearn