wine-devel July 2010

wine-devel@winehq.org

114 participants
459 discussions

wine explorer /desktop=Title,0x0 app.exe for fullscreen?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Jul '10

13 Jul '10

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 13 Jul '10

13 Jul '10

1 0

Having some trouble implementing D3DXComputeNormals... any hints/advice?
by Misha Koshelev 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

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 12 Jul '10

12 Jul '10

2 1

← Newer
1
...
32
33
34
35
36
37
38
...
46
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2010