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

Re: include: rename LIST_ENTRY to WINE_LIST_ENTRY to prevent a conflict on *BSD/OS X
by Nikolay Sivov 15 Jan '10

15 Jan '10

On 1/16/2010 02:12, Austin English wrote: > See bug 21320. > LIST_FOR_EACH_SAFE is inconsistent after your patch. Also I think a shorter variant something like WLIST_... is preferable, but it's a subject of discussion.

2 1

Usage of libxml2 for several modules
by Nikolay Sivov 15 Jan '10

15 Jan '10

I'm thinking about implementing xmllite library - its interface is almost the same as xmlTextReader/Writer from libxml2 so it's potentially a thin wrapper, and it's good. The problem is that libxml2 is not reentrant. This isn't a problem for xmllite itself, cause it's not thread safe too, but: we already have a msxml3 module that loads libxml2. If let's say a process with 2 threads use msxml3 for first and xmllite for second then it's not safe anymore, cause both modules use the same libxml2 instance. If I'm right then only solution is to link to libxml2 statically from each module. Is it an acceptable way? P.S. having a separate copy of libxml2 allows to tweak its namespace support (I believe there's some discussions of that problem in bugzilla).

1 0

GSoC D3DX9 work
by Tony Wasserka 15 Jan '10

15 Jan '10

Hi everyone, I probably should've written this mail a few months earlier, but I had hoped that I'd get some spare time to work on Wine stuff. But to face reality, I'm having A-levels-like graduation (abitur in Germany) in the comming months. I have to prepare a skilled work until the end of january, put a great bunch of learning for the basic course exams and another one for the abitur exams themselves. The past months weren't any relaxing either. It's not that I was overstrained with school and about to get a burn-out or something, but I just lack the time and/or often motivation to work on the d3dx9 dll. This mail is basically for searching for someone to integrate the texture, mesh and font. The font code may be the easiest to integrate (or at least to understand), the texture stuff is the most profitable (as most games which use d3dx require its texture loading functions) and.. the mesh code is at least useful for the DX SDK samples (although these have yet other problems in Wine ranging from incomplete dx10 support over certain unicode functions to the incompatible msvc++ runtime). I know this may sound like "here, I hacked together some code, now anyone do the dirty work and integrate it, write tests, etc...", but especially concerning the visual tests, I think I'd spend my time better on other stuff than writing visual tests for stuff of which I'm pretty certain about that it works fine (ofc I see a point in tests though, but visual tests are a double-edged sword in that regard). I do have numerous tests for the non-visual part, and some functions don't even need visual tests. Especially the texture code consists basically of a) the file loading routines b) pixel format conversion c) filtering, where a, b and c are needed by only one function and d) functions which call that one function with some fancy magic behing (e.g. compability checks, auto-mipmap generation, combining file loading and conversion, etc). So if the one function (D3DXLoadSurfaceFromMemory) is implemented, things will get a lot easier (it actually is already partially implemented by me). So - if anyone is interested in working with my code (CC'd this to David - maybe you are? If not, never mind), I'd be willing to help that one with understanding the code and to explain what still needs to be done, and how I think things should be done (I still have a meanwhile quite compact list of TODOs). The code can be accessed at http://repo.or.cz/w/wine/d3dx9TW.git (in the "Merge" branch, sorry for ****ing up branching there, was my first public repo) and at http://code.google.com/p/google-summer-of-code-2009-wine/downloads/list (a more compact and organized one). Note that I'm not sure whether the code there is up-to-date, I might still have some patches on my hard disk which improve things. But the code there gives a pretty good insight in what's all this about, in case really anyone steps up I'll provide him with the most up-to-date work of mine. If there's anything anyone might want to ask, just answer this mail or contact me directly on irc at #winehackers, my nick is BigBrain and I'm around quite often. Best regards, Tony Wasserka

1 0

Legal issues with wine development
by Benjamin Zink 15 Jan '10

15 Jan '10

Hello, I understand you aren't allowed to look at the source code. The question I have is are you allowed to look at the headers and is an API that's auto generated from the source ok to look at? http://www.cppdoc.com/ has a javadoc style mfc api auto generated from the mfc source. Is this an ok thing to look at? Thank you, Benjamin Zink

3 2

Re: [2/3] user32/tests: Add test for EM_GETIMESTATUS and EM_SETIMESTATUS.
by Paul Vriens 15 Jan '10

15 Jan '10

On 01/15/2010 02:22 PM, Kusanagi Kouichi wrote: > Signed-off-by: Kusanagi Kouichi<slash(a)ac.auone-net.jp> > --- > dlls/user32/tests/Makefile.in | 2 +- > dlls/user32/tests/edit.c | 59 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+), 1 deletions(-) > Hi Kusanagi, These tests fail on Vista+ so it seems: https://winetestbot.geldorp.nl/JobDetails.pl?Key=309 -- Cheers, Paul.

1 0

Re: msvcrt/tests: add some demangle tests
by Christian Costa 15 Jan '10

15 Jan '10

Maybe you can do it for ?swprintf@@YAHPA_WIPB_WZZ as well... André Hentschel a écrit : > somehow regarding http://source.winehq.org/patches/data/57476 > --- > dlls/msvcrt/tests/cpp.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/msvcrt/tests/cpp.c b/dlls/msvcrt/tests/cpp.c > index 106ef73..a75883d 100644 > --- a/dlls/msvcrt/tests/cpp.c > +++ b/dlls/msvcrt/tests/cpp.c > @@ -1034,6 +1034,9 @@ static void test_demangle(void) > /* 113 */ {"?f(a)T@@QAEHQAY1BE(a)BO@$$CBD(a)Z", "public: int __thiscall T::f(char const (* const)[20][30])"}, > /* 114 */ {"??0?$Foo(a)U?$vector_c(a)H$00$01$0?1$0A@$0A@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@@mpl(a)boost@@@@QAE(a)XZ", > "public: __thiscall Foo<struct boost::mpl::vector_c<int,1,2,-2,0,0,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647> >::Foo<struct boost::mpl::vector_c<int,1,2,-2,0,0,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647> >(void)"}, > +/* 115 */ {"?swprintf@@YAHPAGIPBGZZ", "int __cdecl swprintf(unsigned short *,unsigned int,unsigned short const *,...)"}, > +/* 116 */ {"?vswprintf@@YAHPAGIPBGPAD(a)Z", "int __cdecl vswprintf(unsigned short *,unsigned int,unsigned short const *,char *)"}, > +/* 117 */ {"?vswprintf@@YAHPA_WIPB_WPAD(a)Z", "int __cdecl vswprintf(wchar_t *,unsigned int,wchar_t const *,char *)"}, > > }; > int i, num_test = (sizeof(test)/sizeof(test[0])); >

1 0

Re: [2/3] user32/tests: Add test for EM_GETIMESTATUS and EM_SETIMESTATUS.
by Nikolay Sivov 15 Jan '10

15 Jan '10

On 1/15/2010 16:22, Kusanagi Kouichi wrote: > + > + imc = ImmGetContext(hwEdit); > + if (!imc) > + { > + trace("ImmGetContext failed.\n"); > + DestroyWindow(hwEdit); > + return; > + } > + > Hi. A minor correction needed here - should be win_skip(), not just trace() with something like "not implemented", not just failed.

1 0

MFC42.dll implementation
by Benjamin Zink 15 Jan '10

15 Jan '10

Hello, I was thinking about starting a wine implementation of mfc42.dll and was wondering if anyone had already started or had some tips on where to start. Thank you, Benjamin Zink

2 1

Re: [PATCH 1/4] jscript: Added implementation of Array.reverse
by Jacek Caban 15 Jan '10

15 Jan '10

Hi Piotr, On 1/15/10 1:17 AM, Piotr Caban wrote: > --- > dlls/jscript/array.c | 37 +++++++++++++++++++++++++++++++++++-- > dlls/jscript/tests/api.js | 26 ++++++++++++++++++++++++++ > 2 files changed, 61 insertions(+), 2 deletions(-) > > > + if(hres1 == DISP_E_UNKNOWNNAME) + jsdisp_delete_idx(jsthis, l); + else + jsdisp_propput_idx(jsthis, l,&v1, ei, sp); + + if(hres2 == DISP_E_UNKNOWNNAME) + jsdisp_delete_idx(jsthis, k); + else + jsdisp_propput_idx(jsthis, k,&v2, ei, sp); You should check error codes of these calls. Jacek

1 0

Re: kernel32/tests: do not compare handle with zero directly (Smatch)
by Michael Stefaniuc 14 Jan '10

14 Jan '10

Andre, this is actually a false positive in the file_handles Smatch script. Or a valid bug requiring an other solution; depending on the point of view. On 01/14/2010 11:09 PM, André Hentschel wrote: > --- > dlls/kernel32/tests/virtual.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/tests/virtual.c b/dlls/kernel32/tests/virtual.c > index 5187a97..2931374 100644 > --- a/dlls/kernel32/tests/virtual.c > +++ b/dlls/kernel32/tests/virtual.c > @@ -583,7 +583,7 @@ static void test_MapViewOfFile(void) > name = "Foo"; file is used as a HFILE before this line and should be checked against INVALID_HANDLE_VALUE and not NULL. > file = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, 4096, name ); file is now a normal HANDLE and should be checked against NULL. > } > - ok( file != 0, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); This is ok. > + ok( !!file, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); The real fix is either for me to mark it as a false positives. Or to make file a HFILE and use an other HANDLE variable for the mmap. > SetLastError(0xdeadbeef); > mapping = OpenFileMapping( FILE_MAP_READ, FALSE, name ); bye michael

1 0