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

bug or feature: libd3dx9.cross.a
by Misha Koshelev 07 Jul '10

07 Jul '10

Dear All: I have run into another slight issue and, as this may affect others, was wondering whether or not I am (i) doing something wrong or (ii) this is something that should be corrected (in that case I am happy to submit a patch but need a bit of guidance as to where this could be fixed as I could not immediately find it). Specifically, if I do, from the main Wine source directory: cd dlls/d3dx9_36/ make clean; make I get all files _except_ libd3dx9.cross.a, resulting in a dangling symlink in the dlls directory and a mysterious failure when doing: cd dlls/d3dx9_36/tests rm *.exe; make crosstest ../../../tools/winegcc/winegcc -b i586-mingw32msvc -B../../../tools/winebuild --sysroot=../../.. --lib-suffix=.cross.a asm.cross.o core.cross.o effect.cross.o line.cross.o math.cross.o mesh.cross.o shader.cross.o surface.cross.o rsrc.res testlist.cross.o -o d3dx9_36_crosstest.exe -ld3dx9 -ld3d9 -luser32 -lgdi32 -lkernel32 -L./lib32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -ld3dx9 collect2: ld returned 1 exit status winegcc: i586-mingw32msvc-gcc failed make: *** [d3dx9_36_crosstest.exe] Error 2 However, if I simply do cd dlls/d3dx9_36/ make libd3dx9.cross.a All is well. Is this a bug or feature? It seems un-user friendly for new developers trying to add functions to DLLs. Any good way to fix? Thx Misha

1 0

Re: [PATCH 2/2] d3dx9: Test penultimate declaration element in D3DXDeclaratorFromFVFTest.
by James McKenzie 07 Jul '10

07 Jul '10

Misha Koshelev wrote: > --- > dlls/d3dx9_36/tests/mesh.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index a2fb6d8..2952e23 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -262,7 +262,7 @@ static void D3DXDeclaratorFromFVFTest(void) > > if (hr == D3D_OK) > { > - for (i=0; i<4; i++) > + for (i=0; i<5; i++) > I don't know about everyone else here, but I prefer to use less than or equal to, which I think is what was intended here. This positively states the upper bound, which is what I was taught in programming classes a long time ago (when ANSI C was still 89...) Thus this would be for (i=0; i<=4; i++) James McKenzie

2 1

one more git trick - how to add (try x) automatically?
by Misha Koshelev 07 Jul '10

07 Jul '10

Any hints. Since I'll probably be trying more than once for patches, good to know. Thank you! Misha

1 0

Should include files be bug for bug compatible?
by Dylan Smith 07 Jul '10

07 Jul '10

In richedit.h CHARFORMAT2[AW] is padded differently on the Windows PSDK depending on whether it is included for a c or c++ source file. Should the include file be fixed, or does bug for bug compatibility mean that a correct CHARFORMAT2 structure should be declared in a private include file? I tried compiling the following test program using the PSDK: /* source code */ #include <stdio.h> #include <windows.h> #include <richedit.h> int main() { printf("sizeof(CHARFORMAT2W) %d\n", sizeof(CHARFORMAT2W)); printf("FIELD_OFFSET(CHARFORMAT2W, wWeight) %d\n", FIELD_OFFSET(CHARFORMAT2W, wWeight)); printf("FIELD_OFFSET(CHARFORMAT2W, sSpacing) %d\n", FIELD_OFFSET(CHARFORMAT2W, sSpacing)); return 0; } /* end of code */ The compiled c version gives the following output: sizeof(CHARFORMAT2W) 116 FIELD_OFFSET(CHARFORMAT2W, wWeight) 90 FIELD_OFFSET(CHARFORMAT2W, sSpacing) 92 The c++ version gives the following output: sizeof(CHARFORMAT2W) 116 FIELD_OFFSET(CHARFORMAT2W, wWeight) 92 FIELD_OFFSET(CHARFORMAT2W, sSpacing) 94 Those are the only two fields that are affected, so the inconsistency has gone unnoticed until now. According to the About Rich Edit Controls page (http://msdn.microsoft.com/en-us/library/bb787873(VS.85).aspx) Windows has used a C++ code base since richedit 2.0, and so all the richedit DLLs should follow the c++ version of CHARFORMAT2 since riched32.dll is just a wrapper around riched20.dll for richedit 1.0 emulation. Wine's include file will compile like the c version, which caused some weird behaviour that I noticed when improving the EM_SETCHARFORMAT tests.

2 1

d3d9/tests: Add test for surface format conversion
by Bjørnar Hansen 07 Jul '10

07 Jul '10

On Mon, Jul 5, 2010 at 21:37, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The DirectX9 SDK "Blobs" sample needs it. It creates a R32F surface, stretches > to a R16F and then uses it for drawing. Later on I realized that DirectX9 > cards(at least my GF7400) don't support R16F, so the sample uses the original > R32F surface for rendering. DirectX10 cards support R16F however, it would be > interesting to see how this sample reacts to that. > On a Windows XP machine with a ATI HD 4870 graphics card, D3DERR_INVALIDCALL was returned so I assumed it was an invalid call... On Mon, Jul 5, 2010 at 21:23, Henri Verbeet <hverbeet(a)gmail.com> wrote: > You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to > determine which conversions are supported. > Currently, that method always returns OK. Seems pointless to use it, but I've implemented it in my revised patch. Looking at [1], should we test for all combinations of source/target formats? The frameranger demo [2] triggers conversions from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8, which is, according to the Microsoft reference, not a valid conversion. I created a test for this, and it successfully executes on Windows XP. What's with that? [1] http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/reference… [2] http://www.pouet.net/prod.php?which=53647

2 3

Re: mapi32: Add Gaelic resource (try4)
by Paul Vriens 07 Jul '10

07 Jul '10

On 07/06/2010 08:45 PM, Ken Sharp wrote: > Works fine here, but I've changed the encoding of the patch to see if > that helps. > Hi Ken, This one is even worse: ../../../wine-git/dlls/mapi32/Ga.rc:32:87: Error: Invalid character in string 'R-phost a sheoladh mar a theip n� g� duit a cliant r�omhphoist MAPI shuite�il.' for codepage 65001 make[1]: *** [Ga.res] Error 1 make[1]: Leaving directory `/wine/wine64/dlls/mapi32' make: *** [dlls/mapi32] Error 2 You've changed the encoding of the file but left in the pragma. The problem with applying was not with Ga.rc but with the changes to Makefile.in -- Cheers, Paul.

4 5

Re: [PATCH] ntdll: Fix QueryVirtual information on builtin DLLs
by Alexandre Julliard 07 Jul '10

07 Jul '10

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1404,9 +1406,20 @@ static void load_builtin_callback( void *module, const char *filename ) > builtin_load_info->status = STATUS_INVALID_IMAGE_FORMAT; > return; > } > - virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > - VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + /* This view creation is for the sake of NtQueryVirtualMemory, the data is mapped already by dlopen. */ > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + /* The section handling is incomplete for real PE binaries/dlls, but is sufficient > + * for the builtin ones generated by Wine */ > + virtual_create_system_view( (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); > + > + } You can't do that, it needs to be a single view. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] riched20: Process WM_GETMINMAXINFO which arrives before WM_NCCREATE.
by Dmitry Timoshkov 07 Jul '10

07 Jul '10

Austin Lund <austin.lund(a)gmail.com> wrote: > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -4406,7 +4406,7 @@ static LRESULT RichEditWndProc_common(HWND hWnd, UINT msg, WPARAM wParam, > texthost = ME_CreateTextHost(hWnd, pcs, FALSE); > return texthost != NULL; > } > - else if (msg != WM_NCDESTROY) > + else if ((msg != WM_NCDESTROY) && (msg != WM_GETMINMAXINFO)) > { > ERR("called with invalid hWnd %p - application bug?\n", hWnd); > return 0; This code is completely broken. An app can decide to not even pass these messages to a subclassed richedit control. -- Dmitry.

3 5

kernel32 translation
by Gustavo 07 Jul '10

07 Jul '10

Hello, I'm approaching 100% of translation of wine to Brazilian Portuguese :D As can be seen in wine statistics, the MESSAGE #1 from dlls/kernel32 in Brazilian Portuguese is actually translated in European Portuguese. As I can see, only the "default sublanguages" languages have that file translated, so it is supposed to stay that way, isn't it? Cheers, Gustavo.

2 1

Re: fusion: Implement IAssemblyNameImpl_GetDisplayName more completely
by Nikolay Sivov 07 Jul '10

07 Jul '10

On 7/7/2010 03:04, Owen Rudge wrote: > This should have been sent with my earlier fusion patch. It provides a > more complete implementation of IAssemblyNameImpl_GetDisplayName, and > is also required to fix the slow DirectX installer bug (22774). > > --- > dlls/fusion/Makefile.in | 2 +- > dlls/fusion/asmname.c | 134 > +++++++++++++++++++++++++++++++++++++++---- > dlls/fusion/tests/asmname.c | 96 +++++++++++++++++++++++++++++-- > 3 files changed, 215 insertions(+), 17 deletions(-) Hi, Owen. Won't be a sprintfW enough for that?

1 0