unit to detect if your Windows program is running in Wine

[Chebmaster]

One of the pitfalls a Windows program may encounter while running in Linux are the circular directory references: i.e. when directory contains some of the higher level directories containing it, so any recursive search algorithm is doomed to be caught in an infinite loop.

The second danger is "minimize to tray" which seems to be working, but since there is no tray (at least no one supported by wine) there is no way to restore your app from the minimized state.

Wine itself does everything to avoid detection, reporting itself as genuine Windows 95/98/200/XP according to its internal settings and even emulating the known bugs of these specific versions.

So far, this one works :D

Updated one time

unit cl_winedetect;

{$mode delphi}
{$longstrings on}

interface

uses
Windows, Classes, SysUtils;

function RunningInWine: longbool;

implementation
Const WineSig: string = 'Wine placeholder DLL';

var
Performed: boolean = false;
Detected: boolean = false;

function RunningInWine: longbool;
var
buf: string;
S: TFileStream;
i: integer;
sd: string;
begin
if Performed then begin
Result:=Detected;
Exit;
end;
Result:=False;
Try
SetLength(sd, 1000);
FillChar(sd[1], 1000, 0);
GetSystemDirectory(@sd[1], 1000);
sd:=Trim(sd);
S:=TFileStream.Create(sd + '\kernel32.dll', fmOpenRead);
SetLength(buf, 1000);
S.ReadBuffer(buf[1], Length(buf));
S.Free;
For i:=1 to length(buf) - length(WineSig) do
if copy (buf, i, length(WineSig)) = WineSig then begin
Result:=True;
Break;
end;
Except
End;
Detected:=Result;
Performed:=true;
end;
end.

[dmantione]

Wine supports the KDE system tray applet, Windows apps perfectly appear in the system tray. So be carefull not write workarounds that make it harder to get applications working well :)

[JernejL]

wine has specific wine registry keys and settings, look for those rather than using a hardcoded path to wine dll which will break every time the wine kernel32.dll changes.

[Chebmaster]

Wine supports the KDE system tray applet,
I didn't see any whan I was using Gnome.


wine has specific wine registry keys and settings,
Which are to be removed or made unavailable to the applications, according the official docs.


rather than using a hardcoded path to wine dll
Why shouldn't I? the c:\windows\system32\ is where all the DLLs are stored, because the applications expect them to be there. There is no reason for Wine team to change that.


which will break every time the wine kernel32.dll changes.
So far, all the wine dlls contain that signature string, this does not change from version to version.

[JernejL]

rather than using a hardcoded path to wine dll
Why shouldn't I? the c:\windows\system32\ is where all the DLLs are stored, because the applications expect them to be there. There is no reason for Wine team to change that.


That is totally false, the system32 directory can be ANYTHING and ANYWHERE, depending on registry settings in windows, for example, look at windows 2000 or earlier, it used WINNT folder by default, win98 had no system32 folder, and on all windows os-es you can change the system folder.




which will break every time the wine kernel32.dll changes.
So far, all the wine dlls contain that signature string, this does not change from version to version.

it will, and when it will, it will break.

[Chebmaster]

, the system32 directory can be ANYTHING and ANYWHERE,
In original Microsoft OSes, definitely.
In Wine...? So far I didn't see a setting that would allow that.


it will, and when it will, it will break.
Well, the creators of Wine strive constantly to improve the stealth part. So there is no solution that would last forever. The detection methods should be constantly invented and old ones improved.

Today, with versions 0.9.19 to 0.9.36, this method works.

[JernejL]

i'm sure there's a better way, such as checking weither some file part of windows not present in wine is in proper directory.

[Chebmaster]

The problem with that is that Wine allows you to copy dlls and other files from the real Windows and use them.

I assume, you cannot replace this way only a selected few dlls, and kernel32 must be among them.

[Setharian]

the "stealth" part from Wine devs is a little bit weird :) they could add an additional export from kernel32 or ntdll which would return Wine version, simple GetProcAddress would tell you if you are running Wine or not :)

[Chebmaster]

They claim that otherwise the developers of commercial soft would make sure their soft won't run in Wine. Take me, for example. With this unit available, I use it do disable some features in my program (like auto-setting the maximum supported monitor refresh rate) which can do only harm in Linux.

Ok, I updated the code, now it asks the system path from the system.

[dmantione]

Well, it makes a lot of sense. For example, as a Konqueror user I often encounter web sites saying "Your webbrowser is not supported". Luckily the Konqueror developers built in an option to make Konq lie about its identity. More often than not, after making Konq identify itself as IE6.0, the website works perfectly.

I think the Wine developers want to avoid this trap: They don't want people to add messages "Sorry, you cannot run this program, use a real Windows instead".

[Almindor]

Well, it makes a lot of sense. For example, as a Konqueror user I often encounter web sites saying "Your webbrowser is not supported". Luckily the Konqueror developers built in an option to make Konq lie about its identity. More often than not, after making Konq identify itself as IE6.0, the website works perfectly.

I think the Wine developers want to avoid this trap: They don't want people to add messages "Sorry, you cannot run this program, use a real Windows instead".

Perhaps ask them to make it a command-line choice? This way you can make a nice little document explaining to users that your app needs to know it.

Simplest tho, is to make it in your app. Make some argument or some such and tell the users to run it thusly in wine.