Test If Running Under Wine

[Craig macLeod]

I am a developer of Win32 applications. We have recently found the command ShellExecute when trying to browse folders functions differently between Wine and Windows. This is mainly because there is no implementation of Windows Explorer unider Wine so the command does nothing.

How in our code do we differentiate between Wine runs and Windows runs?

The documentation discourages such tests saying we should fix Wine.

My boss wants to do minimal changes to our code so how do we do a simple test if we are using Wine or not? I have some code to test for the existance of explore.exe and if not present then assume we are under Linux. Is this sufficiently generic? (foreign languages etc)

[Mike McCormack]

Craig macLeod wrote:
> I am a developer of Win32 applications. We have recently found the 
> command ShellExecute when trying to browse folders functions differently 
> between Wine and Windows. This is mainly because there is no 
> implementation of Windows Explorer unider Wine so the command does nothing.
>
> How in our code do we differentiate between Wine runs and Windows runs?

You could test for the presence of HKCU\Software\Wine\Wine, but that 
might change later.
> The documentation discourages such tests saying we should fix Wine.
>
> My boss wants to do minimal changes to our code so how do we do a simple 
> test if we are using Wine or not? I have some code to test for the 
> existance of explore.exe and if not present then assume we are under 
> Linux. Is this sufficiently generic? (foreign languages etc)

It's discouraged because we might change the way things are done later, 
implement and explorer, etc and because we don't want applications to 
expect brokenness by default.  If somebody implements an explorer.exe 
that works in a few months, then your app will have permanently crippled 
itself, even though it might otherwise work.

Why not just run the ShellExecute and let it fail?

Mike

On Mon, 10 Oct 2005 09:37:42 +0200, Mike McCormack   
wrote:
> Why not just run the ShellExecute and let it fail?
>  Mike

I think the best approach here is that used in browser sniffing when  
designing web pages: test functionality rather than software presence  
followed by assumptions that may become false later on.

That's basically what Mike is suggesting I think, try the ShellExecute  
within a suitable error-trap. (Give a thought to possible stubs in wine  
that may return without error having done nothing for the user).

HTH

[Boaz Harrosh]

Craig macLeod wrote:
> I have some code to test for the existance of explore.exe and if not 
> present then assume we are under Linux. Is this sufficiently generic?

I think that is best. Since you are looking for the specific missing 
fixture, that could be fixed in future versions/Installations. Also you 
might consider suppling with your application installation a most simple 
"explorer.exe" that does exactly what you need. If it is to display a 
folder, look in codeproject.com they have a sample. Contact me off list 
I have a couple of hours work on top of that sample.

Free Life
Boaz
> (foreign languages etc)

I've looked and did not find other names for it. 
%SystemRoot%\explorer.exe is probably it.
You also have the shell= in registry but that is not Necessary it.
also you have the public Window class: ExploreWClass => EXPLORER.EXE 
(look in MSDN)

Free life
Boaz

[cdr]

Craig macLeod wrote:
> I am a developer of Win32 applications.

Same here...
> How in our code do we differentiate between Wine runs and Windows runs?

Here is one possibility:
/* Get a non-0 to indicate we are running under Wine. */
    iWine = (int)GetProcAddress(LoadLibrary("kernel32"), "wine_get_unix_file_name");
> The documentation discourages such tests saying we should fix Wine.

This is naive and far from practical. To me, it's self-evident that an
application will want know which run-time OS it's running under for many
reasons; it's completely inappropriate for the run-time OS supplier to
discourage it from doing so.

It is further my observation that Wine developers are (unfortunately)
not particularly interested in supporting application builders who
would like to make their applications run well under Wine;  they
believe their system is primarily for the users who will want to run
an application that the application vendor would like to prevent from
running under anything but MS Windows.

cdr

[Troy Rollo]

On Wed, 12 Oct 2005 10:41, cdr wrote:
> This is naive and far from practical. To me, it's self-evident that an
> application will want know which run-time OS it's running under for many
> reasons; it's completely inappropriate for the run-time OS supplier to
> discourage it from doing so.

I wouldn't describe it as completely inappropriate. Aside from the reasons 
usually given, where possible it is preferable to provide the fix for Wine. 
Also, if the application is testing for Wine, why not do a Winelib port?
> It is further my observation that Wine developers are (unfortunately)
> not particularly interested in supporting application builders who
> would like to make their applications run well under Wine;

There are certainly some who are interested in the Winelib side of things.

[cdr]

Troy Rollo wrote:
> Also, if the application is testing for Wine, why not do a Winelib port?

Single sorce to maintain, single binary to distribute.
cdr