wine-devel May 2009

wine-devel@winehq.org

128 participants
234 discussions

Re: Question on writing a testcase..
by chris ahrendt 12 May '09

12 May '09

Paul Vriens wrote: > chris ahrendt wrote: >> I have two test cases for the file.c test in kernel32 to show two >> problems I have found and reported as bugs that wine should be able >> to handle. >> >> first problem : >> >> I/O warning : failed to load external entity >> "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" >> >> Wine does not seem to be parsing this correctly while the various >> windows platforms do correctly. >> So I would like to put a test for this in the test case. >> >> Second file issue I found that needs a test case : >> >> I/O warning : failed to load external entity "EQ/updatestatus.xml" >> >> It seems wine is expecting a fully qualified path in this case where >> as windows uses the application running directory and then looks >> there... >> I am not even sure where this is looking in wine. I would guess at >> the root level from the z: mapping if I had to venture a guess >> instead of the current running directory. >> >> Would I just write the two subroutines and then submit them to >> wine-patch? >> >> Chris >> >> > What function(s) are the tests for? Did you already write some > testcases and run them on Windows? > > -- Cheers, > > Paul. > > They are for the open file api let me find the exact API.. filehandle = _lopen( filename, OF_READ ); in the dlls/kernel32/tests/file.c I also would write the test for _lcreate and the other couple of API's that return a file handle. And I am using an application on windows already that does the open in this manner... but could hack something out really quick. Chris

1 0

Question on writing a testcase..
by chris ahrendt 12 May '09

12 May '09

I have two test cases for the file.c test in kernel32 to show two problems I have found and reported as bugs that wine should be able to handle. first problem : I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" Wine does not seem to be parsing this correctly while the various windows platforms do correctly. So I would like to put a test for this in the test case. Second file issue I found that needs a test case : I/O warning : failed to load external entity "EQ/updatestatus.xml" It seems wine is expecting a fully qualified path in this case where as windows uses the application running directory and then looks there... I am not even sure where this is looking in wine. I would guess at the root level from the z: mapping if I had to venture a guess instead of the current running directory. Would I just write the two subroutines and then submit them to wine-patch? Chris

2 1

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr
by Vitaliy Margolen 12 May '09

12 May '09

Few nitpicks about your patch. Guy Albertelli wrote: > + if (!(input = HeapAlloc( GetProcessHeap(), 0, i_size ))) > + { > + SetLastError( ERROR_NOT_ENOUGH_MEMORY ); > + goto err_ret; > + } > + memset( input, 0, i_size ); To zero out allocated memory you should use HEAP_ZERO_MEMORY allocation flag: input = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, i_size ); However there is no need to do any of that - do not just clear memory without a good reason. It takes time to do it, especially that you doing it several times. What you do need to do in your code is explicitly zero-terminate all strings you receive from mount manager after you copy them. > + p = (WCHAR *) input; This is wrong - types of "p" and "input" has nothing to do with each other. > + p = (WCHAR*)((char *)input + sizeof(MOUNTMGR_MOUNT_POINT)); > + input->DeviceNameOffset = (char *)p - (char *)input; > + memcpy( p, nonpersist_name, lstrlenW( nonpersist_name )*sizeof(WCHAR) ); > + input->DeviceNameLength = lstrlenW( nonpersist_name )*sizeof(WCHAR); This is ugly. You can write it like this: input->DeviceNameOffset = sizeof(*input); input->DeviceNameLength = lstrlenW( nonpersist_name ) * sizeof(WCHAR) memcpy( input + 1, nonpersist_name, input->DeviceNameLength ); > + /* is there space in the return variable ?? */ > + if ((o1->SymbolicLinkNameLength/sizeof(WCHAR))+2 > size) > + { > + SetLastError( ERROR_INVALID_PARAMETER ); > + goto err_ret; > + } This doesn't look right. There are several other error codes that more appropriate. You should expand your tests to check what native returns here. Also are you sure that "size" is in chars not bytes? > + /* make string null terminated */ > + p = (WCHAR*)((char*)volume + o1->SymbolicLinkNameLength); > + memset( p, 0, sizeof(WCHAR) ); Again ugly. You can write it like: volume[o1->SymbolicLinkNameLength / sizeof(WCHAR)] = 0; > + if (input) HeapFree( GetProcessHeap(), 0, input ); > + if (output) HeapFree( GetProcessHeap(), 0, output ); You do not need to check for pointer != NULL before freeing it. All free() functions already doing it. Vitaliy.

2 1

DIB Engine : Almost 100% working
by Massimo Del Fedele 11 May '09

11 May '09

Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max

12 29

Re: comctl32/listview: WinSCP dogfood fix
by Nikolay Sivov 11 May '09

11 May '09

Stefan Stranz wrote: > Fixes bug #13867 > Original fix by GameZelda A test needed for such changes. Especially for that part: @@ -519,7 +519,7 @@ static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW) if (!aw) return bt ? -1 : 0; if (!bt) return aw ? 1 : 0; if (aw == LPSTR_TEXTCALLBACKW) - return bt == LPSTR_TEXTCALLBACKW ? 0 : -1; + return bt == LPSTR_TEXTCALLBACKW ? 1 : -1; if (bt != LPSTR_TEXTCALLBACKW) { LPWSTR bw = textdupTtoW(bt, isW);

1 0

Impossible to register to Bugzilla
by Alain Aupeix 11 May '09

11 May '09

2 2

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try5)
by Nikolay Sivov 11 May '09

11 May '09

André Hentschel wrote: > now PSDK compatible > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) Still wrong: +#define ListView_SetCheckState(hwndLV, i, bCheck) \ + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = LVIS_STATEIMAGEMASK;\ + SNDMSG(hwndLV, LVM_SETITEMSTATE, (WPARAM)(UINT)(i), (LPARAM)(LPLVITEMA)&_LVi);} 'A' structure for both SNDMSG[A,W]. Try with neutral LVITEM. +#define ListView_GetCheckState(hwndLV, i) \ + ((((BOOL)(SNDMSGW((hwndLV), LVM_GETITEMSTATE, (i), \ + LVIS_STATEIMAGEMASK))) >> 12) -1) Always W version used. Why?

2 1

Re: DIB Engine : Almost 100% working
by Reece Dunn 11 May '09

11 May '09

Jeremy White wrote: > Reece Dunn wrote: >> Also, doesn't CodeWeavers have the ability to pledge for features >> (such as DirectX) as well as specific applications? > > Well, kinda sorta, but not really. It's on our todo list and has > been for a long time. > > I think Roderick summarized the issue from our perspective correctly. > Everyone wishes it will be a magic bullet, so we all get excited about it. >From Massimo's report, his DIB engine looks like it fixes a few issues on some games - like Age of Empires 2 - and has some speedups there. Not sure how much of a benefit this is going to be overall. > But in practice, it helps very few applications. Improving gdiplus > (an easier task), we have found to have far more dramatic benefits. I understand this approach. The DIB engine is not a trivial, or isolated piece of functionality, to develop. There are some things I'd be interested in seeing: 1. how this affects double-buffering performance (which a lot of applications make use of, as well as the common controls), which uses DIBs to draw the data off-screen; 2. how this affects theme performance (the repainting of winecfg with the Gem theme is glacially slow); 3. whether this will support alpha blending (useful for themes that support it - such as is likely to be used to provide better integration look and feel - as well as the Wine icon refresh that was being looked at). I wonder if there are any media players or video editing applications that would benefit? Anyway, I'll hopefully get around to do some testing on the DIB engine at some point to test these out. - Reece

1 0

Re: Severity levels
by Nicklas Börjesson 11 May '09

11 May '09

>How many times does this have to be repeated? Severity levels are NOT >determined by how much a user wants the app to work. They're just not, >deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). You seem to be convinced that all users are morons hyping their own stuff. >>>If a set of devs decide to work on getting a particular app working >>>that's up to them, and we've already been over this too. >> Obviously. I can't remember opposing that? >Who said you had? Why writing that we've had already been over it, then?!?? .....etc.... "you can't see the picture" .....etc.... "Not to you, no. Only what you think is right." .....etc.... Huh? This doesn't lead anywhere, you constantly misread me and I don't seem to understand what you are getting at. For some reason, I seem to annoy the hell out if you. I really don't get it, it is not my intention. Do I have some kind of attitude I need to be aware of? I am not a native English speaker. Anyway, it has been obvious from the start that you and I can't communicate. Therefore, I am backing out(hands in air) of this discussion before...uh.. after it has gotten out of hand. //Nicklas

9 24

Winelib - Getting Started guide
by Josef Šimánek 11 May '09

11 May '09

Hi ! I was reading Winelib GSG and I tried to compile notepad from Wine sources. So I downloaded Wine sources (version 1.1.21) and I installed wine from Wine Ubuntu repository (version 1.1.21). I edit Makefile and type make into console. My problem above. In the guide is written to report bad compiling behaviour. So I did it. Any hints ? mirindoslav@mirindoslav-laptop:~/Plocha/notepad$ make winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -m32 -o notepad.exe.so dialog.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid dialog.o: In function `DIALOG_StringMsgBox': dialog.c:(.text+0x235): undefined reference to `wnsprintfW' main.o: In function `HandleCommandLine': main.c:(.text+0x25a5): undefined reference to `PathFindFileNameW' collect2: ld returned 1 exit status winegcc: i486-linux-gnu-gcc failed make: *** [notepad.exe.so] Error 2

2 2

← Newer
1
...
12
13
14
15
16
17
18
...
24
Older →

Jump to page:

2025

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 May 2009