Detecting a programm runs using Wine

antoniong · Post by **antoniong** » Wed Feb 04, 2009 12:35 pm

Is there absolutelu no (unofficial) way to detect whether a programm is running using Wine?

In this way a programm could decide to use other routines for those features that do not work fine using Wine.

austin987 · Post by **austin987** » Wed Feb 04, 2009 12:39 pm

On Wed, Feb 4, 2009 at 11:35 AM, antoniong <[email protected]> wrote:

Is there absolutelu no (unofficial) way to detect whether a programm is running using Wine?

In this way a programm could decide to use other routines for those features that do not work fine using Wine.

There are several ways, but it's not recommended. If wine fixes those
bugs in the future, the program may break. File bugs, write testcases
and get the bug fixed properly.

--
-Austin

Charity Abbott · Post by **Charity Abbott** » Wed Feb 04, 2009 1:03 pm

On Wed, Feb 4, 2009 at 12:39 PM, Austin English <[email protected]> wrote:

On Wed, Feb 4, 2009 at 11:35 AM, antoniong <[email protected]> wrote:
Is there absolutelu no (unofficial) way to detect whether a programm is running using Wine?

In this way a programm could decide to use other routines for those features that do not work fine using Wine.

There are several ways, but it's not recommended. If wine fixes those
bugs in the future, the program may break. File bugs, write testcases
and get the bug fixed properly.

--
-Austin

This is done in a round about way already. Lots of programs
(especially games) come with configuration files that turn features on
and off. AppDB tells you what configuration works. The only downside
to this is the user has to know enough to set it up properly. If a
programmer wanted to make it easier for a program to run on Linux, it
really should be ported to Linux rather than working through wine.
Wine is mainly for those uncooperative programmers.

austin987 · Post by **austin987** » Wed Feb 04, 2009 1:07 pm

On Wed, Feb 4, 2009 at 12:03 PM, Charity Abbott <[email protected]> wrote:

On Wed, Feb 4, 2009 at 12:39 PM, Austin English <[email protected]> wrote:
On Wed, Feb 4, 2009 at 11:35 AM, antoniong <[email protected]> wrote:
Is there absolutelu no (unofficial) way to detect whether a programm is running using Wine?

In this way a programm could decide to use other routines for those features that do not work fine using Wine.

There are several ways, but it's not recommended. If wine fixes those
bugs in the future, the program may break. File bugs, write testcases
and get the bug fixed properly.

--
-Austin

This is done in a round about way already. Lots of programs
(especially games) come with configuration files that turn features on
and off. AppDB tells you what configuration works. The only downside
to this is the user has to know enough to set it up properly. If a
programmer wanted to make it easier for a program to run on Linux, it
really should be ported to Linux rather than working through wine.
Wine is mainly for those uncooperative programmers.

Not necessarily. It takes a lot more effort, money and time to port to
a native Linux app. That also leaves OS X/FreeBSD/OpenSolaris users
out in the cold.

Tweaking an app to work both on Wine and Windows is *much* easier.

--
-Austin

antoniong · Post by **antoniong** » Wed Feb 04, 2009 1:21 pm

austin987 wrote: Tweaking an app to work both on Wine and Windows is *much* easier.
--
-Austin

Indeed, but then one needs a way to find out whether or not the app is running using Wine.

austin987 · Post by **austin987** » Wed Feb 04, 2009 2:06 pm

On 2/4/09, antoniong <[email protected]> wrote:

austin987 wrote:
Tweaking an app to work both on Wine and Windows is *much* easier.
--
-Austin
Indeed, but then one needs a way to find out whether or not the app is
running using Wine.

No. They should test their app under Wine itself for bugs.

--
-Austin

Charity Abbott · Post by **Charity Abbott** » Wed Feb 04, 2009 2:23 pm

On Wed, Feb 4, 2009 at 1:07 PM, Austin English <[email protected]> wrote:

On Wed, Feb 4, 2009 at 12:03 PM, Charity Abbott <[email protected]> wrote:
On Wed, Feb 4, 2009 at 12:39 PM, Austin English <[email protected]> wrote:
On Wed, Feb 4, 2009 at 11:35 AM, antoniong <[email protected]> wrote: There are several ways, but it's not recommended. If wine fixes those
bugs in the future, the program may break. File bugs, write testcases
and get the bug fixed properly.

--
-Austin

This is done in a round about way already. Lots of programs
(especially games) come with configuration files that turn features on
and off. AppDB tells you what configuration works. The only downside
to this is the user has to know enough to set it up properly. If a
programmer wanted to make it easier for a program to run on Linux, it
really should be ported to Linux rather than working through wine.
Wine is mainly for those uncooperative programmers.

Not necessarily. It takes a lot more effort, money and time to port to
a native Linux app. That also leaves OS X/FreeBSD/OpenSolaris users
out in the cold.

Tweaking an app to work both on Wine and Windows is *much* easier.

--
-Austin

I would disagree with that unless you're talking about low level
hardware drivers or programs written in assembly. Most of the time, it
just involves interface translation to OpenGL and recompiling for the
architecture. The process for that varies greatly depending on the
program. For some apps, it would be very minimal. For games or 3D
graphic driven programs, it would be more complex.

austin987 · Post by **austin987** » Wed Feb 04, 2009 2:59 pm

On Wed, Feb 4, 2009 at 1:22 PM, Charity Abbott <[email protected]> wrote:

On Wed, Feb 4, 2009 at 1:07 PM, Austin English <[email protected]> wrote:
On Wed, Feb 4, 2009 at 12:03 PM, Charity Abbott <[email protected]> wrote:
On Wed, Feb 4, 2009 at 12:39 PM, Austin English <[email protected]> wrote: This is done in a round about way already. Lots of programs
(especially games) come with configuration files that turn features on
and off. AppDB tells you what configuration works. The only downside
to this is the user has to know enough to set it up properly. If a
programmer wanted to make it easier for a program to run on Linux, it
really should be ported to Linux rather than working through wine.
Wine is mainly for those uncooperative programmers.

Not necessarily. It takes a lot more effort, money and time to port to
a native Linux app. That also leaves OS X/FreeBSD/OpenSolaris users
out in the cold.

Tweaking an app to work both on Wine and Windows is *much* easier.

--
-Austin

I would disagree with that unless you're talking about low level
hardware drivers or programs written in assembly. Most of the time, it
just involves interface translation to OpenGL and recompiling for the
architecture. The process for that varies greatly depending on the
program. For some apps, it would be very minimal. For games or 3D
graphic driven programs, it would be more complex.

To list as well:

Of course. And if you started with a portable interface
(GTK/QT/etc.), it's even easier.

But to tweak to run on Windows and Wine requires little effort for
many apps. If the application uses common APIs with no special tweaks,
most things should work out of the box. More time will likely be spent
testing the app for bugs.

--
-Austin

antoniong · Post by **antoniong** » Wed Feb 04, 2009 3:00 pm

austin987 wrote:On 2/4/09, antoniong <[email protected]> wrote:
austin987 wrote:
Tweaking an app to work both on Wine and Windows is *much* easier.
Indeed, but then one needs a way to find out whether or not the app is
running using Wine.
No. They should test their app under Wine itself for bugs.
-Austin

I think you misunderstand me.

Sometimes people want to write an app that runs in principle using XP but they also want to make this app available for Linux users. The number of these users is lower so it is nor profitable to rewrite the app in a language that can be compiled for native running under Linux.

In these cases products products like Wine are great. One is able to run XP programms with a minimal amount of resource losses. So the user is happy and the manufacturer is ahppy.

The only problem is that there are situations where Wine does not react similar as native XP does. In such cases it is often easy to incorporate within the app 2 solutions. One the native XP way, one such so that Wine does the same thing.

However it is necessary for the app to know whether it is running native XP or Wine.

Waiting for Wine to fix it would mean unnecessary waiting and very likely for a problem that is only contained within 1 particular situation.

Anyway, it is not irregular for programs to check (e.g.) which processor is used and make branches according to that. No problem.

austin987 · Post by **austin987** » Wed Feb 04, 2009 3:04 pm

On Wed, Feb 4, 2009 at 2:00 PM, antoniong <[email protected]> wrote:

austin987 wrote:
On 2/4/09, antoniong <[email protected]> wrote:

austin987 wrote:
Indeed, but then one needs a way to find out whether or not the app is
running using Wine.

No. They should test their app under Wine itself for bugs.
-Austin
I think you misunderstand me.

No, I understand you fine.

Sometimes people want to write an app that runs in principle using XP but they also want to make this app available for Linux users. The number of these users is lower so it is nor profitable to rewrite the app in a language that can be compiled for native running under Linux.

In these cases products products like Wine are great. One is able to run XP programms with a minimal amount of resource losses. So the user is happy and the manufacturer is ahppy.

The only problem is that there are situations where Wine does not react similar as native XP does. In such cases it is often easy to incorporate within the app 2 solutions. One the native XP way, one such so that Wine does the same thing.

However it is necessary for the app to know whether it is running native XP or Wine.

Waiting for Wine to fix it would mean unnecessary waiting and very likely for a problem that is only contained within 1 particular situation.

Right, but if the bug is fixed in Wine later on, then the app may
behave unexpectedly. What if some windows machines have similar bugs
(many often do). They won't receive that fix either.

The proper thing to do would be detect the broken behavior and work
around it, not detect Wine. But if you have a workaround, that should
be the default behavior, so your app works the same in Windows and
Wine.

--
-Austin

David Gerard · Post by **David Gerard** » Wed Feb 04, 2009 5:52 pm

2009/2/4 Charity Abbott <[email protected]>:

This is done in a round about way already. Lots of programs
(especially games) come with configuration files that turn features on
and off. AppDB tells you what configuration works. The only downside
to this is the user has to know enough to set it up properly. If a
programmer wanted to make it easier for a program to run on Linux, it
really should be ported to Linux rather than working through wine.
Wine is mainly for those uncooperative programmers.

Not really. Programming Unix and programming Windows are very
different - if you're experienced in Windows and don't want to spend
years learning a new system, then Wine is an excellent way to serve a
new userbase. VirtualDub is a good example - it's open source, it'll
likely never be ported natively to Linux, but it works well in Wine
and reproducible problems in Wine will likely be fixed.

- d.

antoniong · Post by **antoniong** » Thu Feb 05, 2009 5:04 am

austin987 wrote: Right, but if the bug is fixed in Wine later on, then the app may
behave unexpectedly. What if some windows machines have similar bugs
(many often do). They won't receive that fix either.
The proper thing to do would be detect the broken behavior and work
around it, not detect Wine. But if you have a workaround, that should
be the default behavior, so your app works the same in Windows and
Wine.
--
-Austin

No doubt, your point of view is the correct one and it is the official standpoint.

BUT!

There are people that have only 1 interest and that is that a Windows app they are using can be run under Linux. Also it happens that the programm developer has not much interest in this but is willing to look into the matter and (if easy dooble) is willing to enhance his app to make a divergence based on "Wine yes/No".

If a simple solution like this can be realised than the developer is happy, the user is happy and no one has any else needs to have any problems with it.

More important, the solution would be today and immediate and not dependent of the will of somebody to either correct Wine behaviour or correct a module coming from again another party that has no interest in repairing at all.

It is the will of the user that should count and certainly Wine should not block this.

(And keep in mind that the chance is likely that this problem situation arises in only 1 particular combination that only a handfull of users are experiencing)

austin987 · Post by **austin987** » Thu Feb 05, 2009 11:23 am

On Thu, Feb 5, 2009 at 4:04 AM, antoniong <[email protected]> wrote:

austin987 wrote:
Right, but if the bug is fixed in Wine later on, then the app may
behave unexpectedly. What if some windows machines have similar bugs
(many often do). They won't receive that fix either.
The proper thing to do would be detect the broken behavior and work
around it, not detect Wine. But if you have a workaround, that should
be the default behavior, so your app works the same in Windows and
Wine.
--
-Austin
No doubt, your point of view is the correct one and it is the official standpoint.

BUT!

There are people that have only 1 interest and that is that a Windows app they are using can be run under Linux. Also it happens that the programm developer has not much interest in this but is willing to look into the matter and (if easy dooble) is willing to enhance his app to make a divergence based on "Wine yes/No".

If a simple solution like this can be realised than the developer is happy, the user is happy and no one has any else needs to have any problems with it.

More important, the solution would be today and immediate and not dependent of the will of somebody to either correct Wine behaviour or correct a module coming from again another party that has no interest in repairing at all.

It is the will of the user that should count and certainly Wine should not block this.

(And keep in mind that the chance is likely that this problem situation arises in only 1 particular combination that only a handfull of users are experiencing)

Like I said, it's doable, plenty of apps do this, but should Wine be
fixed, it will break your app. Detecting the broken behavior is a
better solution, and fixing Wine is the best.

--
-Austin

antoniong · Post by **antoniong** » Thu Feb 05, 2009 12:54 pm

austin987 wrote: Like I said, it's doable, plenty of apps do this, but should Wine be
fixed, it will break your app. Detecting the broken behavior is a
better solution, and fixing Wine is the best.

--
-Austin

Apparently you don't want to understand the quintessens of the problem. Your solution maybe fine for wine but for an enduser is is no solution whatsoever. The user does not care a bit about Wine for him it is a fix for a singualr problem. That's all.

Do you have any experience as an enduser or do you feel like the allmighty God developer? Open up your eyes!

(Don't bother to answer)

austin987 · Post by **austin987** » Thu Feb 05, 2009 1:24 pm

On Thu, Feb 5, 2009 at 11:54 AM, antoniong <[email protected]> wrote:

austin987 wrote:
Like I said, it's doable, plenty of apps do this, but should Wine be
fixed, it will break your app. Detecting the broken behavior is a
better solution, and fixing Wine is the best.

--
-Austin
Apparently you don't want to understand the quintessens of the problem. Your solution maybe fine for wine but for an enduser is is no solution whatsoever. The user does not care a bit about Wine for him it is a fix for a singualr problem. That's all.

Actually, it's the end developer that you're worried about, not the
end user. The end user won't be adding this workaround in their code.

I do understand, but preparing you for the reality of your 'solution'.

Do you have any experience as an enduser or do you feel like the allmighty God developer? Open up your eyes!

Yes. I started as a user, and have learned a lot from working with
Wine. I've used similar workarounds for testing Wine in an automated
fashion, since our tab behavior is apparently broken.

You can check for the "SHELL" environmental variable (or really any
that *nix has that windows doesn't), or check for Wine specific
registry entries.

Again, it's a very dangerous practice. If you test for the the broken
behavior (which can occur on Windows as well), you won't risk breaking
Wine in the future, and also fix the app for broken Windows machines.

--
-Austin

Gert van den Berg · Post by **Gert van den Berg** » Thu Feb 05, 2009 11:08 pm

On Thu, Feb 5, 2009 at 8:24 PM, Austin English <[email protected]> wrote:

Again, it's a very dangerous practice. If you test for the the broken
behavior (which can occur on Windows as well), you won't risk breaking
Wine in the future, and also fix the app for broken Windows machines.

It would probably better to bundle a version of Wine with the
application (like Picasa), which would prevent this issue... (It would
make the detection code unnecessary as well, since you know that the
version will always run under Wine)

This should not be used as an alternative to reporting bugs though...
(Although doing it in parallel might be a nice trade-off)

vitamin · Post by **vitamin** » Fri Feb 06, 2009 10:26 am

antoniong wrote:Apparently you don't want to understand the quintessens of the problem. Your solution maybe fine for wine but for an enduser is is no solution whatsoever. The user does not care a bit about Wine for him it is a fix for a singualr problem. That's all.

That's not the way Open Source development works. If you want it so bad - code it yourself, or convince someone to do it. Telling them they are an idiot won't help.

You can hack all you want a commercial product. But this is not acceptable in the FOSS world. It should be done right or not at all.

There were number of cases when detecting Wine and doing something different eventually broke the application on Wine. So this solution is not viewed as acceptable one by the Wine community.

The topic is closed.

austin987 · Post by **austin987** » Fri Feb 06, 2009 6:24 pm

vitamin wrote:The topic is closed.

I see no reason to close this post. Just because it's not popular or advised, no rules were broken.

Reopening.

antoniong · Post by **antoniong** » Fri Feb 06, 2009 6:39 pm

austin987 wrote:
vitamin wrote:The topic is closed.
I see no reason to close this post. Just because it's not popular or advised, no rules were broken.
Reopening.

And closing made me really angry so I opened a new thread.

austin987 · Post by **austin987** » Fri Feb 06, 2009 6:45 pm

On Fri, Feb 6, 2009 at 5:39 PM, antoniong <[email protected]> wrote:

austin987 wrote:
vitamin wrote:
The topic is closed.
I see no reason to close this post. Just because it's not popular or advised, no rules were broken.
Reopening.
And closing made me really angry so I opened a new thread.

Understandable. That's why I reopened it.

Not trying to scare you off from wine. At the same time, you need to
realize that what you're trying to do isn't a good idea.

Do you have an app that you wrote that doesn't work? Or are you trying
to get one to work that you don't have source to?
--
-Austin

antoniong · Post by **antoniong** » Fri Feb 06, 2009 6:59 pm

austin987 wrote: Understandable. That's why I reopened it.

Not trying to scare you off from wine. At the same time, you need to
realize that what you're trying to do isn't a good idea.

Do you have an app that you wrote that doesn't work? Or are you trying
to get one to work that you don't have source to?
--
-Austin

I know what I want is not the best solution. I have enough experience to oversee the consequences.

But in this case it is about a specialized app (only interesting for a rather small group of people in 1 small counntry) that is written by someone else. There are a few people wanting to use this under Linux and the developer is willing to cooperate as lang as it means making minor changes to his windows app. Add to that the fact that his own coding all works fine but he uses again another 3rd party devloped module that does some special type of printing/preview.

So there are quite a number of people involved:

1. Developer of the app.
2. Developer of his compiler.
3. Developer os th module that is problematic.

and there is an enduser who want to use linux.

Now there are 3 solutions:

1. (the best) solve the problem within Wine. is going to take quite some time and will mean at least 2 developers agreeing to work together and diving deep into the source code of Wine.

2. Use a CLI code in the app so that the app know it runs linux/Wine or native Windows.

or

3. Some coding by which the developer knows whether or not he is using Linux/Wine and use that decision to circumvent the problem part.

That's all nothing more nothing less. (and now I'm going to bed)

austin987 · Post by **austin987** » Fri Feb 06, 2009 7:05 pm

On Fri, Feb 6, 2009 at 5:59 PM, antoniong <[email protected]> wrote:

austin987 wrote:
Understandable. That's why I reopened it.

Not trying to scare you off from wine. At the same time, you need to
realize that what you're trying to do isn't a good idea.

Do you have an app that you wrote that doesn't work? Or are you trying
to get one to work that you don't have source to?
--
-Austin
I know what I want is not the best solution. I have enough experience to oversee the consequences.

But in this case it is about a specialized app (only interesting for a rather small group of people in 1 small counntry) that is written by someone else. There are a few people wanting to use this under Linux and the developer is willing to cooperate as lang as it means making minor changes to his windows app. Add to that the fact that his own coding all works fine but he uses again another 3rd party devloped module that does some special type of printing/preview.

So there are quite a number of people involved:

1. Developer of the app.
2. Developer of his compiler.
3. Developer os th module that is problematic.

and there is an enduser who want to use linux.

Now there are 3 solutions:

1. (the best) solve the problem within Wine. is going to take quite some time and will mean at least 2 developers agreeing to work together and diving deep into the source code of Wine.

2. Use a CLI code in the app so that the app know it runs linux/Wine or native Windows.

or

3. Some coding by which the developer knows whether or not he is using Linux/Wine and use that decision to circumvent the problem part.

That's all nothing more nothing less. (and now I'm going to bed)

Now I understand better.

In that case, I'd recommend a fourth option:
4) Add an option to enable/disable each Wine hack.

Utorrent does this. You get your app working in both Windows and Wine,
and if/when in the future Wine is fixed, you only have to disable the
hack.

Quick, easy, cheap, and non-lethal for Wine and Windows.

Of course, the developer in me would ask that you file a bug for each
problem, and if possible, a small snippet of source code showing the
problem.

--
-Austin

felix · Post by **felix** » Mon Feb 09, 2009 5:58 am

On Fri, Feb 06, 2009 at 05:59:58PM -0600, antoniong wrote:
<snipage>

Now there are 3 solutions:

1. (the best) solve the problem within Wine. is going to take quite
some time and will mean at least 2 developers agreeing to work
together and diving deep into the source code of Wine.

Any you happen to know that for an absolute fact? If you log the bugs,
then one of the wine developers might be able to tell you very quickly
just how difficult it will be to fix the problem. Right now, from this
thread, it's impossible to know, it could be as simple as a DLL
override.

2. Use a CLI code in the app so that the app know it runs linux/Wine
or native Windows.

or

3. Some coding by which the developer knows whether or not he is using
Linux/Wine and use that decision to circumvent the problem part.

Wine does not support detecting of wine, therefore whatever method is
used, the wine developers may well change this in the future to suit.
Hence the detection method no longer works and the app now breaks.

When the correct functionality is implemented you app won't be able to
use it.

That's all nothing more nothing less. (and now I'm going to bed)

Seems to me, that you've already decided that you know more that the
wine developers on how to solve your problem and won't listen to any
reasons put forward that there is a better solution.

Namely look to code to detect the broken behaviour, not the platform,
but the lack of functionality. That's something that the wine developers
can easily help you with, by providing feedback on how to test that the
api being used doesn't work as expected.

--
Darragh

"Nothing is foolproof to a sufficiently talented fool."

antoniong · Post by **antoniong** » Mon Feb 09, 2009 9:57 am

[I know for a fact that I will not be able to help solving this problem within Wine.

For starters, I have no access at all to the app, I have no access to whatever 3rd party it uses. Besides that I have no time for such procedures. I know because I have been in the computing business a long time and know how problems like theseare solved.

I also don't want to spend all that time. my only job is to try to get 1 (=one) particular app to run using Wine. Developer tells me that if he can detect Wine running then he can circumvent the particular part in the app.

That's all, there is nothing more to it. The evt. future (like Winde being changed) is of no relevance since the endusers of this app will not update Wine. They will install the whole at the start and then it wll be inert.

An as a last: I have no code, i want no code.

I wish all those developing Wine a good profitable future. I came here with a simple question and I leave with the answer "runtime switch". problem solved.

PS: I know it is a bad solution but it is the cheapest, most easily and quickest solution.

David Gerard · Post by **David Gerard** » Tue Feb 10, 2009 9:05 am

2009/2/9 Darragh Bailey <[email protected]>:

Wine does not support detecting of wine, therefore whatever method is
used, the wine developers may well change this in the future to suit.
Hence the detection method no longer works and the app now breaks.

Will Wine be abandoning its own set of registry keys?

http://wiki.winehq.org/UsefulRegistryKeys

Will detecting HKEY_CURRENT_USER\Software\Wine stop working at some
point in the future?

- d.