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.
On Wed, Feb 4, 2009 at 11:35 AM, antoniong <wineforum-user at winehq.org> 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
austin987 wrote:> > Tweaking an app to work both on Wine and Windows is *much* easier. > -- > -AustinIndeed, but then one needs a way to find out whether or not the app is running using Wine.
On 2/4/09, antoniong <wineforum-user at winehq.org> 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
austin987 wrote:> On 2/4/09, antoniong <wineforum-user at winehq.org> 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. > -AustinI 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 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. > -- > -AustinNo 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 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. > > -- > -AustinApparently 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)
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 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? > -- > -AustinI 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)
[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.
2009/2/9 Darragh Bailey <felix at compsoc.nuigalway.ie>:> 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.
David Gerard wrote:> Will Wine be abandoning its own set of registry keys?Doubt. But what will prevent user from creating those keys on windows? If you need a sure way to detect wine - look for any of internal Wine exports from ntdll with GetProcAddress().
Hi,
I have also been searching for a way to detect if my application is running
under wine. As I haven?t found an appropriate solution I came to the following
solution. It may not be perfect and there is no guarantee that it will be always
working but I think it is a good approach.
Code:
BOOL CMyClass::IsWine()
{
CString csRet;
BOOL fRet = FALSE;
CString csEntry = _T("ProductName");
HMODULE hLib = LoadLibrary(_T("ntdll"));
if (hLib != NULL)
{
HRSRC hVersion = FindResource( hLib,
MAKEINTRESOURCE(VS_VERSION_INFO), RT_VERSION );
if (hVersion != NULL)
{
HGLOBAL hGlobal = LoadResource( hLib, hVersion );
if ( hGlobal != NULL)
{
LPVOID versionInfo = LockResource(hGlobal);
if (versionInfo != NULL)
{
DWORD vLen,langD;
BOOL retVal;
LPVOID retbuf=NULL;
TCHAR fileEntry[256];
_stprintf(fileEntry,_T("\\VarFileInfo\\Translation"));
retVal = VerQueryValue(versionInfo,fileEntry,&retbuf,(UINT
*)&vLen);
if (retVal && vLen==4)
{
memcpy(&langD,retbuf,4);
_stprintf(fileEntry,
_T("\\StringFileInfo\\%02X%02X%02X%02X\\%s"),
(langD & 0xff00)>>8,langD & 0xff,(langD &
0xff000000)>>24,
(langD & 0xff0000)>>16, csEntry);
}
else
_stprintf(fileEntry, _T("\\StringFileInfo\\%04X04B0\\%s"),
GetUserDefaultLangID(), csEntry);
if (VerQueryValue(versionInfo,fileEntry,&retbuf,(UINT *)&vLen))
{
csRet = (TCHAR*)retbuf;
csRet.MakeLower();
if(0 <= csRet.Find(_T("wine")))
fRet = TRUE;
}
}
}
UnlockResource( hGlobal );
FreeResource( hGlobal );
FreeLibrary(hLib);
}
}
return fRet;
}
This code is mainly based on a publication on www.codeproject.com by luetz:
http://www.codeproject.com/KB/cpp/GetLocalVersionInfos.aspx?display=Print.
I simply read the product name of the ntdll.dll which is "Wine" when
running under wine.
Hope this helps, JonDoe