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

example code appending files with w32api broken?
by Hin-Tak Leung 21 Jan '10

21 Jan '10

I needed a WIN32 API based file-appending solution to fix a bug (http://bugs.winehq.org/show_bug.cgi?id=21394) and using the example code http://msdn.microsoft.com/en-us/library/aa363778%28VS.85%29.aspx as reference, I have got a somewhat working solution, except if I follow the code, the WriteFile part for appending fails. Then I have cross-gcc compiling that example source code standard-alone, and the resulting executable won't append under wine cmd either. So it looks like either the example code is wrong, or wine's implementation of WriteFile() is a bit broken sometimes. I have determined the ReadFile succceeds and the SetFilePointer() also work) So I have two questions - (1) can somebody tell if there is something obviously wrong with the example, (2) can somebody say if it is because wine is not working e.g. SetPointer doesn't work? On a general question: what's the policy of patches based on MSDN example code like this? I mean, assuming the example does the job, it is quite difficult to write file-appending code which isn't quite similiar to that.

2 5

Re: [PATCH 1/5] wininet: Add Internet{Set, Query}Option tests, implement POLICY option
by Nikolay Sivov 20 Jan '10

20 Jan '10

On 1/20/2010 23:46, Andrew Eikum wrote: > --- > dlls/wininet/internet.c | 6 ++++++ > dlls/wininet/tests/internet.c | 26 ++++++++++++++++++++++++++ > 2 files changed, 32 insertions(+), 0 deletions(-) > Please mark patches with (tryX) in subject and specify a difference from previous try next time. It's really hard to follow identically named mails without a single line of details.

1 0

Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try3)
by Paul Vriens 20 Jan '10

20 Jan '10

On 01/11/2010 09:47 PM, Peter Dons Tychsen wrote: > Try 3 of this patch: > > - Moved check to server. > - Removed handling of error code translation after input from AJ. > > Thanks, > > /pedro > > Hi Peter, This patch has introduced test failures on NT4 and below (tested locally): http://test.winehq.org/data/tests/user32:win.html The callback is entered several times on NT4 (only once on XP) so it seems. The test crashes on Win98 btw. Could you have a look? You can use the winetestbot (https://winetestbot.geldorp.nl/) to check the failures on NT4. I can assist with Win9x testing if needed. I'm busy setting up a local winetestbot that includes Win95, Win98 and WinMe. -- Cheers, Paul.

2 2

Re: oleaut32: do not crash in logging if string is NULL
by Alexandre Julliard 20 Jan '10

20 Jan '10

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -68,10 +68,16 @@ typedef struct _marshal_state { > > /* used in the olerelay code to avoid having the L"" stuff added by debugstr_w */ > static char *relaystr(WCHAR *in) { > - char *tmp = (char *)debugstr_w(in); > - tmp += 2; > - tmp[strlen(tmp)-1] = '\0'; > - return tmp; > + static char szNull[] = "<NULL>"; > + if (in) > + { > + char *tmp = (char *)debugstr_w(in); > + tmp += 2; > + tmp[strlen(tmp)-1] = '\0'; > + return tmp; > + } > + else > + return szNull; > } This should never happen. Places that can get a null pointer should use the standard debugstr_w. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: kernel32/tests: do not compare handle with zero directly (Smatch)
by Dan Carpenter 20 Jan '10

20 Jan '10

Sorry, I'm not on the list. - ok( file != 0, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); + ok( !!file, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); Smatch sees those as equivelent. (The new version does at least http://repo.or.cz/w/smatch.git) There is a wine_checker.sh script in smatch_scripts so you can quickly test individual files. I just pushed a change to make wine_checker.sh find the smatch binary so you may want to pull the most recent changes. /path/to/smatch_scripts/wine_checker.sh dlls/kernel32/tests/virtual.c Michael said it could be either real bug or a false positive. I sort of decided it was a false positive and pushed a change to fix that. Now if "file" gets 1) reassigned 2) incremented/decremented 3) passed to a function like this: fuction(&file); it stops being called a filehandle. (Unless it gets reassigned another file handle obviously). Hope that is Ok. The check only prints a warning if something is _definitely_ a file handle and it gets compared to zero. I could easily change it to print a message if something is _possibly_ a file handle and gets compared against zero. Like this: if (x) file = CreateFile(); else file = some_func(); if (file) // <- complain I know smatch has been abandonware for a long time, but I hope to do better now. regards, dan carpenter

1 2

WINEDEBUG=+relay: why unicode arguments printed in form L"\0412\044b" and not L"\x412\x44b"? 044b sure not octal
by Илья Басин 20 Jan '10

20 Jan '10

/////////////////////////// #include <windows.h> int main() { MessageBoxExW(NULL, L"\x412\x44b \x434\x435\x439\x441\x442\x432\x438\x442\x435\x43b\x44c\x43d\x43e \x445\x43e\x442\x438\x442\x435 \x443\x434\x430\x43b\x438\x442\x44c \"\x43f\x440\x438\x43f\x430\x440\x43a\x43e\x432\x430\x43d\x43d\x44b\x435\" \x43f\x438\x441\x44c\x43c\x430?\r\r\x410\x442\x440\x438\x431\x443\x442 \x41f\x430\x440", L"The Bat! Voyager", 0x00012133, 0x00000019); } /////////////////////////// # WINEDEBUG=+relay wine msgbox.exe 2>&1 | grep "MessageBoxExW" 0009:Call user32.MessageBoxExW(00000000,0040a028 L"\0412\044b \0434\0435\0439\0441\0442\0432\0438\0442\0435\043b\044c\043d\043e \0445\043e\0442\0438\0442\0435 \0443\0434\0430\043b\0438\0442\044c \"\043f\0440\0438\043f\0430\0440\043a\043e\0432\0430\043d\043d\044b\0435\" \043f\0438\0441\044c\043c\0430?\r\r\0410\0442\0440\0438\0431\0443\0442 \041f\0430\0440",0040a000 L"The Bat! Voyager",00012133,00000019) ret=0040101c 0009:Ret user32.MessageBoxExW() retval=00000000 ret=0040101c

2 1

Re: [PATCH 4/5] wined3d: Don't use the depth range clipping hack when we have ARB_depth_clamp.
by Chris Robinson 20 Jan '10

20 Jan '10

On Tuesday 19 January 2010 2:52:28 pm Henri Verbeet wrote: > ARB_depth_clamp should give pretty much the desired behaviour by clamping > instead of clipping depth values outside the depth range. I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in state_clipping if you're going to bypass the depth range hack with it. Currently it's only called if WINED3DRS_CLIPPING is off.

3 8

valgrind run called on account of rain
by Dan Kegel 20 Jan '10

20 Jan '10

Today's scheduled match between Valgrind and Wine was called on account of rain. The roofers think they found where the water was coming in, and the rainstorm can't last forever; I'm hoping to turn the Valgrind build machine on again later this week. Once it dries out :-)

4 4

Re: [PATCH 3/5] wined3d: Don't use the depth range clipping hack when minZ and maxZ are equal.
by Stefan Dösinger 20 Jan '10

20 Jan '10

Am 19.01.2010 um 23:52 schrieb Henri Verbeet: > - if (!stateblock->device->untransformed) > + if (!stateblock->device->untransformed && minZ != maxZ) My tests show that this is not needed, at least in d3d8 and d3d9. My (unsent) tests show that if you pass MinZ == MaxZ SetViewport adjusts one of them to make sure they're apart by at least 0.001. If the parameters are < 0.999 maxZ is incremented by 0.001, otherwise minZ is set to 0.999. (If my memory serves me right) That said, I will be busy the next 2 weeks at university, so don't expect the test and a fix for SetViewport in in that time. Plus, I still haven't ported my tests to ddraw, which may behave differently. If it helps your work feel free to put the patch in in the meantime, although obviously it would be better to skip it to avoid forgetting about it later.

1 0

re: Usage of libxml2 for several modules
by Dan Kegel 19 Jan '10

19 Jan '10

http://xmlsoft.org/threads.html says it's only a problem if the same document is being parsed by both threads. The trouble scenario seems unlikely, offhand.

4 7