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

wine explorer /desktop=Title,0x0 app.exe for fullscreen?
by Joerg-Cyril.Hoehle＠t-systems.com July 12, 2010

July 12, 2010

Hi, on MacOS, I've setup winecfg with a default virtual desktop because full screen apps generally don't work. However, all windowing apps (e.g. notepad, regedit) would benefit from not using this desktop window. They nicely open resizable windows when run in full screen. The FAQ recommends wine explorer /desktop=Title,800x600 for running apps inside windows when fullscreen is the default setting. What I need is the exact opposite. Looking at the source, I found out that the converse works using wine explorer /desktop=Title,0x0 regedit.exe opens a regedit window without a virtual desktop one. Can that behaviour be blessed officially and documented? Or is it accidental? Regards, Jörg Höhle

4 4

Re: shlwapi/tests: Fix GLE for SHFormatDateTimeA
by testbot＠testbot.winehq.org July 12, 2010

July 12, 2010

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=3297 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:593: Test failed: GetShellSecurityDescriptor should fail ordinal.c:616: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1766: Test failed: got 26 ordinal.c:1816: Test failed: got 26 ordinal.c:1824: Test failed: got 26 ordinal.c:1832: Test failed: got 37, length 38 ordinal.c:1843: Test failed: got 40 === W7PROX64 (32 bit ordinal) === ordinal.c:1760: Test failed: got 9 ordinal.c:1781: Test failed: got 6 ordinal.c:1794: Test failed: got 9 ordinal.c:1802: Test failed: got 9 ordinal.c:1832: Test failed: got 32, length 33 ordinal.c:1843: Test failed: got 35 ordinal.c:1854: Test failed: got 19 ordinal.c:1865: Test failed: got 22

1 0

Having some trouble implementing D3DXComputeNormals... any hints/advice?
by Misha Koshelev July 12, 2010

July 12, 2010

Dear All: Hope you are having a nice Sunday. I have decided that, as all the D3DXCreate... functions return vertex normals in addition to vertices themselves, it is more efficient to implement D3DXComputeNormals and use this function rather than calculate normals individually for each shape (or create an internal function that does the same thing). As you can see from this patch: http://github.com/misha680/wine/commit/0e975e7360f403eb123055b6ff996137e0b2… the normals computed by D3DXComputeNormals are almost equal to those originally returned by D3DXCreateCylinder for complex enough values of the radii, length, slices, and stacks (these values are within 10^-6 of each other). I have taken the following description from MSDN: "A normal for a vertex is generated by averaging the normals of all faces that share that vertex. If adjacency is provided, replicated vertices are ignored and 'smoothed' over. If adjacency is not provided, replicated vertices will have normals averaged in from only the faces explicitly referencing them." and implemented it in a test case (attached - code, compilation script, and compiled executable via MingW). For a very simplified cylinder (radii 1.0f, length 0.0f, 3 slices, 2 stacks) all seems well, and my normals match perfectly to those created by D3DXComputeNormals. However, for a more complicated case: static const FLOAT radius = 1.0f; static const FLOAT length = 1.0f; static const UINT slices = 10; static const UINT stacks = 20; You can see something quite perplexing. Specifically, below you can see all 3 triangles that contain vertex #11 (11, 21, and 12 are vertex indices, below you will see the actual vertex X,Y,Z values, and finally the computed normal for the specific triangle). Below, you can see under "Averaged Normals", first the normal computed by averaging and normalizing the normals for each of the triangles, and then the original normal computed by D3DXComputeNormals. Notice that they are quite (significantly) different. This does not happen for a lot of vertices, but for quite a few (say 5-10%). Index Buffer: 11,21,12, {0,1,-0.5}, {0,1,-0.45}, {0.587785,0.809017,-0.5}, {0.00954915,0.0293893,0}, 20,30,11, {-0.587785,0.809017,-0.5}, {-0.587785,0.809017,-0.45}, {0,1,-0.5}, {-0.00954915,0.0293893,0}, 11,30,21, {0,1,-0.5}, {-0.587785,0.809017,-0.45}, {0,1,-0.45}, {-0.00954915,0.0293893,0}, Averaged Normals: 11 {-0.107677,0.994186,0} {-1.99491e-008,1,0}, I have used the equivalent statement for D3DXComputeNormals: if (!SUCCEEDED(D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS, NULL, -1.01f, -0.01f, -1.01f, NULL, NULL))) and tried to vary the parameters listed below, but honestly am a bit stumped... I will investigate further, but if perhaps I am missing something simple, would be great to know! Thanks Misha p.s. Fyi these are the relevant parameters for D3DXComputeTangentFrameEx from http://msdn.microsoft.com/en-us/library/bb172745%28v=VS.85%29.aspx Thank you! Misha fPartialEdgeThreshold [in] FLOAT Specifies the maximum cosine of the angle at which two partial derivatives are deemed to be incompatible with each other. If the dot product of the direction of the two partial derivatives in adjacent triangles is less than or equal to this threshold, then the vertices shared between these triangles will be split. fSingularPointThreshold [in] FLOAT Specifies the maximum magnitude of a partial derivative at which a vertex will be deemed singular. As multiple triangles are incident on a point that have nearby tangent frames, but altogether cancel each other out (such as at the top of a sphere), the magnitude of the partial derivative will decrease. If the magnitude is less than or equal to this threshold, then the vertex will be split for every triangle that contains it. fNormalEdgeThreshold [in] FLOAT Similar to fPartialEdgeThreshold, specifies the maximum cosine of the angle between two normals that is a threshold beyond which vertices shared between triangles will be split. If the dot product of the two normals is less than the threshold, the shared vertices will be split, forming a hard edge between neighboring triangles. If the dot product is more than the threshold, neighboring triangles will have their normals interpolated.

2 5

xrender.c is does not find fontconfig.h on OS X Tiger
by Mike Kronenberg July 12, 2010

July 12, 2010

Dear List OS X Tiger does has not have fontconfig, so I'm building it in ~/buildwine/usr to keep it out of /usr. I include the headers and libs from ~/buildwine/usr with CPPFLAGS and CFLAGS. This worked fine until 1.2-rc1 and 1.2-rc2. Compiling xrender.c now exits with an error that FC_WEIGHT_THIN etc is not defined. configure leaves me with SONAME_LIBFONTCONFIG='libfontconfig.1.dylib' FONTCONFIGINCL='' in the config.log. No luck even if I export FONTCONFIGINCL="-I//$HOME/buildwine/usr/include/fontconfig -I//$HOME/buildwine/usr/include' which resulted in a correct FONTCONFIGINCL, but the compiling still failed. All the other custom compiled deps are working as usual. Any hint what I might missing? txs Mike

2 2

Re: wined3d/directx.c: Corrected Nvidia 8400 and 8500 reporting
by Roderick Colenbrander July 12, 2010

July 12, 2010

Hi Seth, It is not a good idea to advertise a 8400 and a 8500 as a 8600GT. All Geforce8 GPUs have the same features (except, some have different purevideo capabilities). As mentioned before even CUDA is allowed on all GPUs but only if they have 256MB or more. Likely the app you are using either disallows this GPU based on the wrong number of video memory Wine reports or it just disallows poor GPUs because it is not worth the effort to use them for CUDA computations because they don't have enough computation power. The Geforce 8600GT is (depending on the configuration) upto 4x faster (if you just look at shaders + clock speeds), so it is really not a good idea to mark the 8400/8500 as a 8600GT. This could really cause issues for games which use the PCI id to select a performance profile at startup. It would be better to add a separate 8500GT entry with 256MB. I'm not sure if we want to merge it with the 8400 though since the 8500 has 256-1024 (depending on the model) and the 8400 has 128-512MB. A lot of modern games like to have around 256MB. I guess it is best to keep the 8400 tied to the 8300. Roderick On Sun, Jul 11, 2010 at 7:04 PM, Seth Shelnutt <shelnutt2(a)gmail.com> wrote: > Moves the Nvidia Geforce 8400 and 8500 to be reported as 8600GT as they have > feature parity. This is needed for CUDA applications to support these two > cards. They are currently reported as an 8300 which is not CUDA capable. > > Thanks, > > Seth Shelnutt > > > >

2 2

Old documentation changelogs to be kept?
by Frédéric Delanoy July 12, 2010

July 12, 2010

In the documentation directory, there are ChangeLog.ALPHA, ChangeLog.BETA and ChangeLog.OLD. Are these files still useful (most recent entry is dated 2008-06-16)? Or are they simply kept as a log of the good old pre-git days? Frédéric

1 0

Manifests, Microsoft.VC90.CRT and vc_redist
by Peter Urbanec July 12, 2010

July 12, 2010

I'm trying to get my head around the mess generated by SxS, isolated apps, embedded manifests, local deployment and all the other "solutions" to DLL hell. It's hard enough to make it work on Windows, but making it work well under wine is another challenge. In a nutshell, I'd like to ship a custom wine64 RPM package that can co-exist with distribution provided wine32 RPMs. I also want to make a couple of companion RPMs, which provide x64 apps that depend on my wine64 RPM. I don't want to require an installation of the x64 packages under Wine. i.e. I want to avoid the requirement to run vcredist_x64.exe for each user. The most obvious solution to this seems to be to include the DLLs from "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" in the same dir as the x64 application executable, known as "application local deployment". Now, this is where I get confused. The VC redist files provide DLLs with version 9.0.30729.1, whereas the manifest embedded in the application has version 9.0.21022.8. When the 9.0.30729.1 VC redist files are installed in the windows dir, the associated policies will redirect requests for 9.0.21022.8 to use 9.0.30729.1, but this does not seem to work when the DLLs are deployed in the app directory. Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number. Should I be using msvcr90.dll from VC redist? Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir? Thanks for any insights you could provide.

3 3

Re: [PATCH 2/2] uninstaller: Update the Czech translation.
by Michael Stefaniuc July 12, 2010

July 12, 2010

Forgot to remove the "[PATCH 2/2]". There is no dependency for this patch. bye michael Michael Stefaniuc wrote: > Translation by Radek Vokal. > --- > programs/uninstaller/Cs.rc | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/programs/uninstaller/Cs.rc b/programs/uninstaller/Cs.rc > index ed73cd3..f6ee8cc 100644 > --- a/programs/uninstaller/Cs.rc > +++ b/programs/uninstaller/Cs.rc > @@ -1,5 +1,4 @@ > -/* Hey, Emacs, open this file with -*- coding: cp1250 -*- > - * > +/* > * Uninstaller (Czech Resources) > * > * > @@ -22,9 +21,9 @@ > > LANGUAGE LANG_CZECH, SUBLANG_NEUTRAL > > -/* Czech strings in CP1250 */ > - > +#pragma code_page(65001) > > STRINGTABLE DISCARDABLE { > - IDS_APPNAME, "Deinstalátor" > + IDS_APPNAME, "DeinstalÃ¡tor" > + IDS_UNINSTALLFAILED, "SpuÅ¡tÄ›nÃ pÅ™Ãkazu %s selhalo, moÅ¾nÃ¡ pÅ™ÃÄÃna je chybÄ›jÃcÃ aplikace.\nPÅ™ejete si odstranit instalaÄnÃ zÃ¡znam z registru?" > }

1 0

Re: user32: Add a test showing that SetForegroundWindow() on a visible child of invisible parent does activate the parent an
by testbot＠testbot.winehq.org July 12, 2010

July 12, 2010

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=3291 Your paranoid android. === W98SE (32 bit win) === win.c:2950: Test failed: hwnd 000004C4 message 0112 win.c:2952: Test failed: message 0112 available win.c:2959: Test failed: hwnd 000004C4 message 0100 win.c:2961: Test failed: message 0100 available win.c:2973: Test failed: message 000f available win.c:2985: Test failed: message 000f available win.c:2994: Test failed: message 000f available win.c:3003: Test failed: message 000f available === W2KPROSP4 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000900A6 fg 000600AE in hook HCBT_SETFOCUS === WXPPROSP3 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000700F0 fg 000A0148 in hook HCBT_SETFOCUS === W2K3R2SESP2 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500D8 fg 000B00BE in hook HCBT_SETFOCUS === WVISTAADM (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000D0108 fg 000E0106 in hook HCBT_SETFOCUS === W2K8SE (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500FE fg 00040152 in hook HCBT_SETFOCUS === W7PRO (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0005015A fg 00090132 in hook HCBT_SETFOCUS === W7PROX64 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0005016E fg 000401B0 in hook HCBT_SETFOCUS === W7PROX64 (64 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000050170 fg 00000000000301B0 in hook HCBT_SETFOCUS

1 0

Re: user32: Make sure that main window state is consistent during the tests.
by testbot＠testbot.winehq.org July 12, 2010

July 12, 2010

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=3290 Your paranoid android. === W98SE (32 bit win) === Timeout === WVISTAADM (32 bit win) === win.c:2271: Test failed: 000F0200: expected prev 000D01D8, got 003301D2 win.c:2272: Test failed: 000D01D8: expected next 000F0200, got 003301D2 win.c:2198: Test failed: 00BF01D0: expected next 00040208, got 000E01E0 win.c:2271: Test failed: 003401D2: expected prev 00110200, got 000F01E0 win.c:2272: Test failed: 00110200: expected next 003401D2, got 000F01E0 === W2K8SE (32 bit win) === win.c:2271: Test failed: 000E0110: expected prev 000B0116, got 009000FC win.c:2272: Test failed: 000B0116: expected next 000E0110, got 009000FC win.c:2198: Test failed: 0052010E: expected next 000500F4, got 000C0114 win.c:2271: Test failed: 009100FC: expected prev 00100110, got 000D0114 win.c:2272: Test failed: 00100110: expected next 009100FC, got 000D0114

2 1