How can I detect WINE from my program?

megapup · Post by **megapup** » Sun May 24, 2009 1:35 pm

How can I detect WINE from my program, or detect Linux, in other wors how can I detect that OS is not Windows.
BOOL WINAPI GetVersionEx(LPOSVERSIONINFO lpVersionInfo) returns that OS is Vista

austin987 · Post by **austin987** » Sun May 24, 2009 1:54 pm

On Sun, May 24, 2009 at 1:35 PM, megapup <[email protected]> wrote:

How can I detect WINE from my program, or detect Linux, in other wors how can I detect Â that OS is not Windows.
BOOL WINAPI GetVersionEx(LPOSVERSIONINFO lpVersionInfo) returns that OS is Vista Â

Why do you want to do this?

--
-Austin

megapup · Post by **megapup** » Sun May 24, 2009 2:38 pm

Because WINE is not emulator

When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.

austin987 · Post by **austin987** » Sun May 24, 2009 2:41 pm

On Sun, May 24, 2009 at 2:38 PM, megapup <[email protected]> wrote:

Because WINE is not emulator Â :D Â When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.

Instead of tweaking your application, file bugs for wine so we can fix
them instead. Or better yet, fix them yourself

.

Since you've got the code, provide small testcases, which help greatly.

--
-Austin

jay · Post by **jay** » Sun May 24, 2009 2:41 pm

megapup wrote:Because WINE is not emulator When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.

Well, I guess you could check if HKCU\Software\Wine exists ^^

EDIT1: I'm talking about the registry key of course
EDIT2: ..or is Wine hiding that key from every program except regedit? I don't know.

austin987 · Post by **austin987** » Sun May 24, 2009 2:44 pm

On Sun, May 24, 2009 at 2:41 PM, jay <[email protected]> wrote:

megapup wrote:
Because WINE is not emulator Â :D Â When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.
Well, I guess you could check if HKCU\Software\Wine exists ^^

It could be created on windows as well.

--
-Austin

jay · Post by **jay** » Sun May 24, 2009 2:52 pm

Of course, if some company is called Wine or someone wants to pretend Wine is being used then it could be created.

But all registry keys could be fake-created and deleted, so why use the registry at all hehe

oh wait.. the same is true for the HDD.. oh oh ^^

EDIT²: gah, I should re-read what I've written before submitting

megapup · Post by **megapup** » Sun May 24, 2009 3:20 pm

I finded solution, just load kernel32.dll and try to find there function wine_get_unix_file_name()
I ckecked just now on wine 1.1.22 ubuntu 9.04, it works perfectly

austin987, fix the wine-bugs yourself it's good idea, simply I forget about the possibility

ps my english so bad

vitamin · Post by **vitamin** » Sun May 24, 2009 4:35 pm

megapup wrote:I finded solution, just load kernel32.dll and try to find there function wine_get_unix_file_name()
I ckecked just now on wine 1.1.22 ubuntu 9.04, it works perfectly

Yes, that is a sure way to detect if you running on Wine.

However keep in mind that fixing Wine is always a most preferred solution. Or at least making Wine return proper errors and have your application handle those errors. So whenever Wine gets fixed your application will continue working properly in the same way it does on windows.

oiaohm · Post by **oiaohm** » Sun May 24, 2009 11:20 pm

The wine registry key is created when wined3d is installed in windows as well for virtualization support ie windows running in many emulators has wined3d installed.

wine_get_unix_file_name() would be classed as a internal wine function that can be renamed or removed without notice.

For long term compatibility it is preferable if detection is not used and the flaws in wine fixed. Basically megapup don't complain to us if one day that function gets removed or renamed it is an internal function.

Now look about my note about wined3d you might detect wine but if the problem is in wined3d you are in trouble since it exists on windows and wine and a virtualization system might rename its registry keys making it not detectable straight up.

Providing test cases of where the error is or patching the error in wine is kinda important.

megapup · Post by **megapup** » Mon May 25, 2009 2:10 am

It would be better for all if WINE would have something like official way to detect itself.
Because the problems fixes not at once but a program wants to work right now.

oiaohm · Post by **oiaohm** » Mon May 25, 2009 8:39 am

Not better. megapup .

Its a double sided sword if wine is detectable why bother fixing wine bugs. If wine is reliability detectable applications developers have a simple path to exclude wine. Reason why we have to reserve the right to move any internal part as we see fit so in case of someone excluding wine we can counter.

If wine is reliability detectable this can be used by virus writers to attack host OS. Problem is for support wine would have to expose wine version and host OS reason some bugs are particular to like Mac OS or Linux or BSD... Once you know the host OS you can code to syscall the hosting OS and attack it. Downside of giving it up is cross platform viruses become simpler.

Downside out weights the good. You would have to give a really good reason why we have to. Giving developers a free pass does not help wine develop.

Applications builder are free to ship custom versions of wine if required. LGPL license was chosen to allow this.

If you are looking at wine as a free path out of having to develop natively for other platforms it is not megapup.

There are two major solutions to your problems megapup.

1) Wine is designed to assist in cross porting of applications to build native programs as well. So if your program is compatible with winegcc and other tools when in build due to header flags wine is detectable. Secondary advantage is that you can take advantage of native paths for load heavy parts.

Source level wine is simply detected. Making like program.exe.so binaries allows you the detection you are talking about since program.exe.so does not work with windows but works with wine also these files are platform Dependant ie Linux Mac OS BSD... So providing the required split. A path was already provided basically just required binary for windows and binaries for different platforms.

2) What would be wrong asking user if they are running in wine in the installer or providing a option in application to enable defective work rounds megapup. Thinking defect work around might have usage on future version of windows, cedega or clones like reactos. Using a controllable defect correction system would be the preferred method since wine developers still could use your program in bug testing by not enabling the work around and gets the most usage out the defect correction code.

There is more than 1 path. To us we have provided enough paths detection reduces the usefulness of your program to us for bug testing.

With wine where defects can disappear or be dependent on a particular video card driver or bit of software. Hard coding the defect handling should be last option because who to say in every case the correction you do in your code will not be cased by something you overlooked your end?

megapup you could end up harming your uses with the solid detection. If there are good advantages it would be done.

majkl · Post by **majkl** » Mon Jun 01, 2009 2:35 am

Hello,
at first i want to thank you, that at least someone answered, ive been looking for such detection - i also needed to tweak my application, because of wine does not support some functionality.

Secondly if someone would bother to update, fix or do something with it, it would be great. Now for the problem:

Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel.

Actually im not yet sure if wine supports transparency at all.. I found the problem accidentaly few minutes ago, when i decided to try my windows application on my friends computer, who use wine. In fact it worked pretty well(i bow before wine developers

), but my good bye screen, who uses this transparency functionality was totally screwed up. I saw only white blank window. And unfortunatelly i cannot develope the project on wine, so i really need to detect wine and just not use this functionality.

rein · Post by **rein** » Mon Jun 01, 2009 2:55 am

majkl wrote:And unfortunatelly i cannot develope the project on wine, so i really need to detect wine and just not use this functionality.

The official answer is that you should not detect wine to use or not use functionality. Instead you should detect if functionality exists and use it when available. This should work on all versions of wine and windows

Now it may be difficult to detect transparency, at least I would not know how. But since it is an approved way to handle missing wine functionality that makes it a very good question on the wine developers list.

David Gerard · Post by **David Gerard** » Mon Jun 01, 2009 2:59 am

2009/5/25 oiaohm <[email protected]>:

Its a double sided sword if wine is detectable why bother fixing wine bugs. Â If wine is reliability detectable applications developers have a simple path to exclude wine. Â Reason why we have to reserve the right to move any internal part as we see fit so in case of someone excluding wine we can counter.

[snip long answer]

If this isn't a FAQ and on the wiki, it should be.

Q. I'm writing an application. How do I detect when it's running on Wine?

A. You can detect it using --- or ---. However, this is a VERY BAD
IDEA. [long list of reasons]

- d.

James McKenzie · Post by **James McKenzie** » Mon Jun 01, 2009 7:55 pm

majkl wrote:

Hello,
at first i want to thank you, that at least someone answered, ive been looking for such detection - i also needed to tweak my application, because of wine does not support some functionality.

Secondly if someone would bother to update, fix or do something with it, it would be great. Now for the problem:

Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel.

You could help solve this problem since you appear to be a programmer.
Look in BugZilla for transparency issues and there should be some code
or pseudo-code to work with.

James McKenzie

oiaohm · Post by **oiaohm** » Tue Jun 02, 2009 8:37 am

majkl

Number one if wine does not have a test case for a particular bit of missing function it needs to be coded. Of course there are the odd function or two were you cannot use a detect.

Seams strange to windows coders at first is that the best way to detect wine and other emulators is the person sitting behind the keyboard.

Problem with those render errors some of them are not wine but the video driver being used too. World of Warcraft of all things has a game config file you edit to enable overrides. This is perfectly fine to wine users. Basically include in instructions enable this to make X problem go away.

Advantage of this method is simple the day wine does support doing that you don't need to release another binary with you hack removed to restore full function.

If you can detect using normal windows calls if a function is working on not use that. If you cannot simply use a configuration in file or registry for the application.

Detecting wine itself is the wrong path.

andreaplanet · Post by **andreaplanet** » Tue Jun 02, 2009 9:36 am

Ok, recognizing that Wine is running in order to execute a different code is not welcome. But still there are features that Wine does not implement or does not want to implement. In that case the only workaround is to execute a different code based on the OS.

If there is a vulnerability then it is not avoided through obscurity (i.e. by not providing an official API or method to recognize Wine).
A virus writer that want's to target Wine/Linux will find several methods and try them all inside his code.

Actually a default Wine installation creates the Z: symlink, so a part of the methods above described I just have to run "Z:/bin/uname -a" to get the exact linux version. Or I may try to read the contents of the file "Z:/etc/system-release". And through Z: I can run *any* linux program too.

Andrea

Gert van den Berg · Post by **Gert van den Berg** » Tue Jun 02, 2009 11:31 am

An official way to detect Wine might really be handy, not just to work
around bugs, but to enable additional / different functionality when
the app is running under Wine, such as native file dialogs (not sure
if it is possible with a native Windows program?).

It must be optional and disabled by default though... (An extra
Windows version is probably the most elegant way).It must also be
possible to enable it on a per-application basis. (Like Windows
versions)

It would be really nice if it is possible to compile a single
application that run on both Windows and Wine and has native dialogs
on both. (Almost like Java, but without the overhead)

Gert

oiaohm · Post by **oiaohm** » Tue Jun 02, 2009 8:26 pm

Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail.

I was not talking about secuirty through obscurity as such. We provide a detect path we are able to limited so cannot remove it. If we find an attacker using a detect path we have to have the right to remove it we can limit the damage that can do. This is where the problem comes in with all the forms of detect so far. You are going to hook to something that we one day may remove. So then we get yelled at if we say do that.

There is a really dirty way to detect wine and it is the most dependable by the way. Try to run .exe.so if it runs it wine or another emulator base off wine. If it don't run it not wine or the wrong platform type. You can catch this failure by the way. Again can be secuirty filtered against to stop it from functional operation. You could also allow the file to be removed if missing going on as if you are on windows. So meeting our requirements. This kind of support is not going to be removed because someone decides to abuse detecting wine. We already have a built in counter measure. dll overrides settings. Flip the default if dll is not listed as builtin don't allow it to be loaded as builtin. So detect would be dead as door nail if we ever had to kill it. Yet restore able by altering winecfg libs for the application.

Basically at some point you many have to tell user how to enable the extras anyhow. So why not just be up front and ask them. Simpler by the way don't have to include .exe.so for linux bsd mac os solarias... Detecting wine is the hard path.

This way is using nothing about the internals of wine. The complete idea that you have to add something to detect wine is wrong.

If you are after a way wine users/developers cannot block if they choose to forget it. That is impossible.

Basically you guys are thinking the incorrect ways. Test function is the way. Not like windows is going to add elf support any time soon.

Gert

If you want to call system native in the first place .dll.so and .exe.so are the recommend to do it. As we say function tests. If it functions you have wine if it don't you have windows.

Gert wine always has overhead. Interfacing with native dialogs sound like a way to save a lot of coding hell. Until you wakeup. Native dialogs on Linux are basically incompatible with windows. http://wiki.winehq.org/WinePluginApi Yep inserting a windows gui addon into gtk or qt currently is impossible.

So you will have to rebuild your full front end native anyhow to have it work. That is basically most of the way to building the full program. Then there are threading control issues and other evils. You are talking a major undertaking. It gets to the point bugger it port program to QT will be simpler. Also thinking upcoming is arm and mips based processors so a port to QT or Java will be worth it. Low end of market will own to arm/mips process running Ubuntu and other full distrubtions, android and Windows CE. Sorry wine don't run on arm without being wrapped in qemu and being as slow as hell.

Really have to look carefully for why to go the path you want Gert. Long term for most programs using wine as cross platform interface is wrong answer.

It would be nice to have pass through libs in wine for qt and gtk we don't because it will hurt like hell. Even simple things like a file handle don't match up. If someone wanted to provide wrappers for that they could.

James McKenzie · Post by **James McKenzie** » Tue Jun 02, 2009 8:42 pm

oiaohm wrote:

Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail.

You are correct in the statement that Z:\ does NOT exist with each and
every Wine installation. Some users have disabled it or even moved it
to prevent bad things from happening.

I was not talking about secuirty through obscurity as such. We provide a detect path we are able to limited so cannot remove it. If we find an attacker using a detect path we have to have the right to remove it we can limit the damage that can do. This is where the problem comes in with all the forms of detect so far. You are going to hook to something that we one day may remove. So then we get yelled at if we say do that.

There is a really dirty way to detect wine and it is the most dependable by the way. Try to run .exe.so if it runs it wine or another emulator base off wine. If it don't run it not wine or the wrong platform type. You can catch this failure by the way. Again can be secuirty filtered against to stop it from functional operation. You could also allow the file to be removed if missing going on as if you are on windows. So meeting our requirements. This kind of support is not going to be removed because someone decides to abuse detecting wine. We already have a built in counter measure. dll overrides settings. Flip the default if dll is not listed as builtin don't allow it to be loaded as builtin. So detect would be dead as door nail if we ever had to kill it. Yet restore able by altering winecfg libs for the application.

Basically at some point you many have to tell user how to enable the extras anyhow. So why not just be up front and ask them. Simpler by the way don't have to include .exe.so for linux bsd mac os solarias... Detecting wine is the hard path.

Here is what we are trying to tell you and andreaplanet: Help us make
Wine better. If there is a function you absolutely have to have, let us
know. We are here to help you the developer. In turn, this makes Wine
better.

This is what Wine is all about in the first place. It started as a
project, a long time ago to get one or two programs to run on Linux (and
before that OS/2). Windows is definitely a 'moving target' and we all
have to work towards that target. Windows95/98 as old as they are, are
still targets. More recently, WindowsXP. The project needs to fill in
many blanks. Some exist on MSDN, some in more obscure places and some
have no documentation at all. That is why we need your help as program
developers to advise what is and is not working right for your program.
Then we can fill in the blanks and also test what functions we do know
about properly. The goal is to reproduce the Windows API as best we can
without violating Microsoft code (and maybe in the process, fix a few
Windows bugs.)

James McKenzie

andreaplanet · Post by **andreaplanet** » Wed Jun 03, 2009 12:49 am

oiaohm wrote:Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail.

Also with a fully active Firewall & Antivirus (where every executable must be authorized manually by the end-user) a Windows system is mostly secure against attacks. But this is not the common case, that's why viruses and trojans are still doing damages on Windows.

The default installation of Wine has Z:\ active, so the majorty of Wine installations has vulnerabilities from someone who targets a Wine-Linux system. And simple relocation doesn't help since I can use winepath to get the current path. I even don't need the access to the full / path, since I'm a "bad guy" my code contains also a copy of the native /bin/ln executable located in C:, so I only have to run

C:\ln -s / /home/currentuser/.wine/dosdevices/v:

After I did some damage (on v: which point to /) I can safely remove that symlink again. But maybe this is even not necessary since a symlink created in such a way is not visible in the WineConfiguration program. And you get the current user path through the environment or through winepath.

But.. why all this hassle? Since I am attacking a linux system I only need to have my malicious code compiled as a native Linux binary. No need to have any symlink at all.
So another good way to know if I'm running on Wine/Linux is to run my own compiled linux executable, if it runs then I'm on linux. I just discovered yesterday that it is possible to run native linux executables within wine.

oiaohm wrote:The complete idea that you have to add something to detect wine is wrong.

Many small issues in Wine will never be fixed because
- it's not worth (or)
- there are too few developers to fix everything (or)
- the wine community does not want to fix something by design (or)
- some issues are just impossible to fix due to technical reasons

In such cases a workaround is the only solution (also just a messagebox saying that a specific feature is not available), and such workaround require to know if I'm running under Wine or not.
And since there exists already many ways to know if I'm running on Wine. Why not offer a official standard way that will work reliable for the good guys? Bad guys will find out in any case.

majkl · Post by **majkl** » Wed Jun 03, 2009 1:07 am

Ok, i understand that you dont want to have reliable way for everyone to detect wine from application - i understand, there may be good reasons for this, it depends in point of view, but what about this switch/option/configuration stuff, that someone above already mentioned? What about saying wine to allow the application to findout if it is wine, or not allowing it? Would it be hard to implement such switch?

oiaohm · Post by **oiaohm** » Wed Jun 03, 2009 4:28 am

andreaplanet what you describe as an attack don't work on all distributions out there. Some have wine sandboxed. So even if Z: exists. Running ln -s will not work. Access to other native binarys are forbin by the mandatory access control system.

This is the were you are so wrong. bad guys go that path we already have an answer. Just we choose to not use it at this time.

Mandatory access controls also can forbin applications running created by use and not installed in system. At this stage linux systems all bar hardered Linux's don't have this enabled.

The paths you have are already have walls to be put up in case of need andreaplanet. Wine is currently left soft to be as friendly as we can. That can be changed over night if the need ever turns up.

Basically Linux is not windows. Linux systems do have solid mandatory access control systems they can turn on if there was a secuirty need to. You want your applications to keep working stop trying to be a smart ass. It don't matter because I have a hole does not wash with me. Simple point here you don't. The hole only exists because the OS secuirty is turned down if its ever turned up those holes disappear.

majkl we already have switchs. We already have a way to detect. Ie exe.so binaries. They only work on wine and its relations. Why duplicate.

Still no one has answered why you cannot just put a check box in the installer asking user are they on wine? It is the simplest solution. It why I am classing you arguments for so pointless.

Many small issues in Wine will never be fixed because
- it's not worth (or)
- there are too few developers to fix everything (or)
- the wine community does not want to fix something by design (or)
- some issues are just impossible to fix due to technical reasons

This is one of the reason why we don't want to. If you can detect wine what is you motivation to fix it. That simple. If you can detect wine most windows developers will do the same as you do on windows. Ok its wine run different block of code lets not bother fixing it no matter how simple.

There is currently no issue that cannot be fixed due to technical reason. Some have been delayed due to the fact with the upcoming alterations in the X11 stack they will become simpler to fix.

Problem here I am reading you like a openbook. Windows programmer solution to a OS bug detect OS alter program to avoid it so because they cannot fix OS. Linux program to a OS bug patch the OS. We expect Linux style method not windows for the simple reason if you don't remove the bug someone else can in future so leaving users with a crippled program due to your workaround.

andreaplanet · Post by **andreaplanet** » Wed Jun 03, 2009 6:21 am

oiaohm wrote:andreaplanet what you describe as an attack don't work on all distributions out there.

But this attack will work on most Linux systems since by default I can run native programs. Like with Windows, viruses and trojans have a easy job on most Windows systems, but not on all.
You can't say Wine has no vulnerabilities because if you configure it as a Sandbox then you can feel secure, when nearly nobody does that.
(I tried to find out how to activate the Sandbox environment for Wine but didnt found anything).

oiaohm wrote:Wine is currently left soft to be as friendly as we can. That can be changed over night if the need ever turns up. The hole only exists because the OS secuirty is turned down if its ever turned up those holes disappear.

Good to know. I could say the same for Windows. Just install the appropriate software for defending it.
So right now I can easily target a Wine-Linux system. Fortunately it's still easier to try to attack a native Windows machine, also because there exists more Windows systems, so you have a higher chance of success.

oiaohm wrote:We already have a way to detect. Ie exe.so binaries. They only work on wine and its relations. Why duplicate.

So everyone who want to detect Wine must create his own exe.so? Ok, but if it is hardened through a sandbox then still can I run it? With a sandbox can I run a native linux binary distributed together with my application?

oiaohm wrote:Still no one has answered why you cannot just put a check box in the installer asking user are they on wine? It is the simplest solution. It why I am classing you arguments for so pointless.

First you say it is wrong to detect Wine, now you say let the user detect Wine (choose on which OS you are running).
Every developer have to write that question, save that info somewhere in the registry or a INI file. What a duplication.
Honestly a simple API call for everyone would be much easier without bothering the end-user.
As a end-user I would ask myself "isn't the program intelligent enough to detect on what system it is running?"

Many small issues in Wine will never be fixed because
- it's not worth (or)
- there are too few developers to fix everything (or)
- the wine community does not want to fix something by design (or)
- some issues are just impossible to fix due to technical reasons

oiaohm wrote:This is one of the reason why we don't want to. If you can detect wine what is you motivation to fix it. That simple. If you can detect wine most windows developers will do the same as you do on windows. Ok its wine run different block of code lets not bother fixing it no matter how simple.

This is a good point. But you can't force developers to do that, also because there exists easy workarounds. Running a native binary, reading the environment. It's not that hard, maybe unreliable.
Why not cooperate? Make an API call like "bool IsWineBugFixed(int bugnr);". That function will read from a .conf/inf file that is updated at each wine release. Until the bug is fixed the Windows code will execute in custom way else it will run in a native way.

And you didn't answered about "bugs/behaviours" that the Wine community just don't want to change. Let's call them hacks or patchs to make a particular application run (better). People at Codeweavers said that CrossOver is full of hacks that the wine community refuse to use. What if I want to use such a hack even on Wine? In such case I need a customized attitude of my program, so I need to detect if Wine is running.

For example personally I want that my application use the native Open File Dialog and not the ugly default windows open file dialog. By reading the currently running OS I can run a specified native executable/library that offer this feature and interact with the EXE application through a pipe for example. The Wine community will refuse to use such a hack because it changes the natural behaviour of the Windows environment. And I want this change only for my own application, so that other applications will run without problems. Here a reason why a simple API to let me know the name of currently OS is welcome, and it should work both at least on Windows, Linux and Mac OS X.

Of course on the long run the goal is to rewrite the application natively for Linux and Mac OS X. But right now it's an acceptable workaround.