July 2010 - Wine-Devel - list.winehq.org

The annoying FAQ of detecting Wine

by David Gerard

Unfortunately, this is a FAQ, so I've added it. I based the answer on the last time this came around on wine-users; I'm not a developer, so please sanity-check what I wrote! Hopefully this will be useful in dealing with the actual problems people think they can solve by doing this. http://wiki.winehq.org/FAQ#head-9c045f5ff1df8a1afef91e1152ca7f6a9684f116 8.6. I write a Windows app. How can it detect if it's running under Wine? This is a bad idea. The goal of Wine is that an application will be unable to tell it's running under Wine rather than Windows. So any method to detect running under Wine is unsupported and may break without warning in the future. Wine should not be treated as a "version" of Windows - functionality or performance-tuning is likely to be different between any two development versions. Rather than detecting Wine: * Detect if functionality exists and use it when available. * File a bug if something works in Windows that does not work in Wine. * Ask for help on the developers' list. That said: if you really want to detect Wine, try, e.g., running a native binary or syscall (AppArmor or SELinux may block this), reading the environment, accessing a function (e.g ntdll.get_wine_version() ) or registry key only found in Wine. Any of these may break at any time. Asking the user directly if they are running the app under Wine will be more reliable than trying to automatically detect it. - d.

July 3, 2010

FAQ just updated and copyedited

by David Gerard

Just went through the FAQ, copyediting, tweaking and bringing things into the present: http://wiki.winehq.org/FAQ?action=diff&rev2=347&rev1=346 Please sanity-check :-) - d.

July 3, 2010

Re: Why some gdi32 calls aren't caught in relay while some are caught?

by Vitaliy Margolen

On 07/01/2010 12:55 PM, Hayan Lee wrote: > Wine doc says relay supports user32, ntdll, etc, but not gdi32. > However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap() > But some aren't caught, e.g, CreateBitmapIndirect() See RelayFromExclude in http://wiki.winehq.org/UsefulRegistryKeys that will exclude all internal calls to listed dlls from relay output. Default Wine setup has that key set to "winex11.drv;user32;gdi32;advapi32;kernel32". Also note that some exports are marked as -norelay in .spec file. You won't get any relay output for such functions. Vitaliy.

July 3, 2010

Re: shell32/tests: CommandLineToArgvW("") shouldn't truncate returned exe path

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3073 Your paranoid android. === W2K3R2SESP2 (32 bit shlexec) === shlexec.c:195: Test failed: WaitForSingleObject returned 258 shlexec.c:1417: Test failed: argvA3 expected 'Open', got '(null)' shlexec.c:1420: Test failed: argvA4 expected 'C:\WINDOWS\Temp\wt11.tmp\test file.shlexec', got '(null)' shlexec.c:1426: Test failed: argcA expected 4, but got 5 shlexec.c:1427: Test failed: argvA3 expected 'Lnk', got 'Open' shlexec.c:1516: Test failed: argcA expected 4, but got 5 shlexec.c:1517: Test failed: argvA3 expected 'Exec', got 'Lnk' === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2

July 3, 2010

Re: patch for fixing the tab change bug

by Nikolay Sivov

On 7/3/2010 02:56, Austin English wrote: > On Thu, Jul 1, 2010 at 5:20 PM, Matthias Kupfer > <matthias.kupfer(a)informatik.tu-chemnitz.de> wrote: >> Hi, >> >> after changing the selected tab, it's impossible to change to another tab with >> mouse. This patch fixes this issue, because the SetCurFocus changes selection >> (if conditions apply). > This patch has caused a regression, please see > http://bugs.winehq.org/show_bug.cgi?id=23479. > Yeah, patch is wrong. With it now we have duplicated notification messages sent.

July 2, 2010

Re: patch for fixing the tab change bug

by Austin English

On Thu, Jul 1, 2010 at 5:20 PM, Matthias Kupfer <matthias.kupfer(a)informatik.tu-chemnitz.de> wrote: > Hi, > > after changing the selected tab, it's impossible to change to another tab with > mouse. This patch fixes this issue, because the SetCurFocus changes selection > (if conditions apply). This patch has caused a regression, please see http://bugs.winehq.org/show_bug.cgi?id=23479. -- -Austin

July 2, 2010

Re: RFC: Wine API Documentation Proposal

by Peter Davies

> I don't know about the 'respectability' of SF, but I'm more concerned with the content and who gets to change it. There are folks that may decide to enter incorrect or even bogus information. I would like it if all added information that is not already present in the Wine API be vetted. That means one person enters it and another disassociated person verifies before it goes live. Code already in the API should be considered automatically vetted. I think the speed and freedom provided by wiki is more important than vetting. Most problems would be due to vandalism (easily reverted), people will keep an eye on Recent Changes. If the problem is overwhelming, we will make editing privileges require a grant by an admin on a shall issue basis. Bogus information is a non-issue, people with sufficient knowledge to enter convincing information are not going to be the sort to enter bogus information. Wikipedia has a high level of accuracy despite its openness. Peter

July 2, 2010

Re: Changing sizes of templates in comdlg32

by Alexander Nicolaysen Sørnes

In the Norwegian version of Windows, Microsoft moved the Up and Down radiobuttons around to make room for the bigger words. I did the same for Wine's version, and it worked great. :) Alexander Fredag 2. juli 2010 19.35.10 skrev Gustavo : > Ok, Paul, I understand. Out of curiosity, is that for compatibility > with older versions of Windows? I've never seen this problem with > Windows, it seems to have plenty space for the long texts that comes > with the Portuguese version, even 3.11. > > Well, that doesn't matter, I think I can fix it without messing too > much. The only big problem is with the group "Direction" in the "Find" > and "Replace" dialogs. The words "up" and "down" are too small. I > might have to leave that in English. > > Gustavo. > > 2010/7/2 Paul Chitescu <paulc(a)voip.null.ro>: > > On Friday 02 July 2010 12:41:25 am Gustavo wrote: > >> I've found the following warning the the file comdlg32: > >> > >> /* > >> * WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES. > >> */ > >> > >> Does that mean that I can't correct the size of the buttons or strings > >> that are wrong in the Portuguese template file? Or is that only a > >> warning for the English file? The "Find" and "Replace" dialogs are > >> specially ugly in Portuguese, I would appreciate to be able to change > >> that. > > > > Gustavo, > > > > Knowing the reason the warning is there will help you judge what you can > > and what you shouldn't move or resize. > > > > There are many apps that grow the dialog and insert their own controls at > > fixed positions. There are also some applications that disable a group of > > controls and then shrink the dialog to make them invisible. > > > > It is generally OK to change the dimensions of the controls a little but > > you must preserve the general layout and the size of the groups of > > controls. You must however not resize the dialog itself. > > > > Regards, > > > > Paul >

July 2, 2010

Re: Addition of En resources to non-En resources

by Octavian Voicu

2010/7/2 Francois Gouget <fgouget(a)free.fr>: > As expected Wallon and Finnish are truncated: > http://fgouget.free.fr/tmp/reshack/comdlg32_Wa.jpg > http://fgouget.free.fr/tmp/reshack/comdlg32_Fi.jpg I wonder how we will handle these cases once we switch to using PO files. A more generic approach will surely be needed, so that dialogs are resized to fit long data. Octavian

July 2, 2010

Re: Changing sizes of templates in comdlg32

by Gustavo

Ok, Paul, I understand. Out of curiosity, is that for compatibility with older versions of Windows? I've never seen this problem with Windows, it seems to have plenty space for the long texts that comes with the Portuguese version, even 3.11. Well, that doesn't matter, I think I can fix it without messing too much. The only big problem is with the group "Direction" in the "Find" and "Replace" dialogs. The words "up" and "down" are too small. I might have to leave that in English. Gustavo. 2010/7/2 Paul Chitescu <paulc(a)voip.null.ro>: > On Friday 02 July 2010 12:41:25 am Gustavo wrote: >> I've found the following warning the the file comdlg32: >> >> /* >> * WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES. >> */ >> >> Does that mean that I can't correct the size of the buttons or strings >> that are wrong in the Portuguese template file? Or is that only a >> warning for the English file? The "Find" and "Replace" dialogs are >> specially ugly in Portuguese, I would appreciate to be able to change >> that. > > Gustavo, > > Knowing the reason the warning is there will help you judge what you can and > what you shouldn't move or resize. > > There are many apps that grow the dialog and insert their own controls at > fixed positions. There are also some applications that disable a group of > controls and then shrink the dialog to make them invisible. > > It is generally OK to change the dimensions of the controls a little but you > must preserve the general layout and the size of the groups of controls. You > must however not resize the dialog itself. > > Regards, > > Paul > >

July 2, 2010