February 2009 - Wine-Devel - list.winehq.org

Re: [PATCH] advapi32: fixed second buffer argument to MBtoWC and WCtoMB

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > diff --git a/dlls/advapi32/cred.c b/dlls/advapi32/cred.c > index 9ad4fb1..ab86ed6 100644 > --- a/dlls/advapi32/cred.c > +++ b/dlls/advapi32/cred.c > @@ -940,7 +940,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const CREDENTIALW *CredentialW, > if (CredentialW->TargetName) > { > CredentialA->TargetName = buffer; > - string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, -1, NULL, NULL); > + string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, NULL, 0, NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, string_len, NULL, NULL); It doesn't make sense to use the output size as buffer size. You need to pass the real size of the buffer. -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2009

Re: [RESEND] comctl32: Save and restore colours when adding masked images

by Alexandre Julliard

Peter Urbanec <winehq.org(a)urbanec.net> writes: > This patch will save and restore the colours when adding a masked image > to ImageList. What's the point of restoring the colors in a DC that gets deleted right away? -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2009

Re: avifil32: ukranian translation by Artem Reznikov

by Alexandre Julliard

Christoph von Wittich <Christoph(a)ApiViewer.de> writes: > dlls/avifil32/avifile_Uk.rc | 51 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/avifil32/rsrc.rc | 1 + > 2 files changed, 52 insertions(+), 0 deletions(-) Please add a From: line with the full name and email of the original author (or better ask him to submit the patch himself). And please fix your mail setup, all your patches are wrapped. -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2009

[patch] rpcrt4_conn_np_read needs to expect and accept ERROR_MORE_DATA

by Luke Kenneth Casson Leighton

http://bugs.winehq.org/show_bug.cgi?id=17263 hooray! very simple fix, here - allow ERROR_MORE_DATA status code as an acceptable error. ... and _check it_, afterwards. ideally, the loop to read a complete PDU should be vaguely like this: do { RpcConnection conn->ops->read(data, &len) total_read += len; if GetLastError() == ERROR_MORE_DATA if total_read == total_packet_size return FALSE; /* not ok to return ERROR_MORE_DATA at end of PDU! } while (total_read != total_packet_size); i.e. you should _expect_ there to be an ERROR_MORE_DATA status code on all but the _very_ last bit of the PDU. but, you can't do that in rpcrt4_conn_np_read() because that function is just a "data getter", it doesn't know when it's being used to grab the last bit of the PDU. this will prove to be important for catching problems, both internally and also when SMBs are used. _yes_ the SMB system also returns ERROR_MORE_DATA. actually, if NT STATUS codes are enabled, it's STATUS_MORE_PROCESSING_REQUIRED which _do_ go over-the-wire if the smb server negotiates their use, but that's another story. l.

Feb. 5, 2009

Re: kernel32: DeviceIoControl: lpBytesReturned must not be NULL if lpOverlapped is NULL

by Nikolay Sivov

Christoph von Wittich wrote: > dlls/kernel32/comm.c | 55 > +++++++++++++++++++++++++++++++------------------ > 1 files changed, 35 insertions(+), 20 deletions(-) > > diff --git a/dlls/kernel32/comm.c b/dlls/kernel32/comm.c > index d83eacb..11cfda0 100644 > --- a/dlls/kernel32/comm.c > +++ b/dlls/kernel32/comm.c > @@ -551,7 +551,8 @@ BOOL WINAPI BuildCommDCBW( > */ > BOOL WINAPI SetCommBreak(HANDLE handle) > { > - return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, > NULL, 0, NULL, NULL); > + DWORD dwBytesReturned; > + return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, > NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -573,7 +574,8 @@ BOOL WINAPI SetCommBreak(HANDLE handle) > */ > BOOL WINAPI ClearCommBreak(HANDLE handle) > { > - return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, > NULL, 0, NULL, NULL); > + DWORD dwBytesReturned; > + return DeviceIoControl(handle, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, > NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -595,6 +597,7 @@ BOOL WINAPI ClearCommBreak(HANDLE handle) > BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > { > DWORD ioc; > + DWORD dwBytesReturned; > > switch (func) > { > @@ -612,7 +615,7 @@ BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > SetLastError(ERROR_INVALID_PARAMETER); > return FALSE; > } > - return DeviceIoControl(handle, ioc, NULL, 0, NULL, 0, NULL, NULL); > + return DeviceIoControl(handle, ioc, NULL, 0, NULL, 0, > &dwBytesReturned, NULL); > } > > /******************************************************************** > @@ -632,8 +635,9 @@ BOOL WINAPI EscapeCommFunction(HANDLE handle, UINT func) > */ > BOOL WINAPI PurgeComm(HANDLE handle, DWORD flags) > { > + DWORD dwBytesReturned; > return DeviceIoControl(handle, IOCTL_SERIAL_PURGE, &flags, > sizeof(flags), > - NULL, 0, NULL, NULL); > + NULL, 0, &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -654,9 +658,10 @@ BOOL WINAPI PurgeComm(HANDLE handle, DWORD flags) > BOOL WINAPI ClearCommError(HANDLE handle, LPDWORD errors, LPCOMSTAT lpStat) > { > SERIAL_STATUS ss; > + DWORD dwBytesReturned; > > if (!DeviceIoControl(handle, IOCTL_SERIAL_GET_COMMSTATUS, NULL, 0, > - &ss, sizeof(ss), NULL, NULL)) > + &ss, sizeof(ss), &dwBytesReturned, NULL)) > return FALSE; > > if (errors) > @@ -708,11 +713,12 @@ BOOL WINAPI ClearCommError(HANDLE handle, LPDWORD > errors, LPCOMSTAT lpStat) > BOOL WINAPI SetupComm(HANDLE handle, DWORD insize, DWORD outsize) > { > SERIAL_QUEUE_SIZE sqs; > + DWORD dwBytesReturned; > > sqs.InSize = insize; > sqs.OutSize = outsize; > return DeviceIoControl(handle, IOCTL_SERIAL_SET_QUEUE_SIZE, > - &sqs, sizeof(sqs), NULL, 0, NULL, NULL); > + &sqs, sizeof(sqs), NULL, 0, > &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -732,9 +738,10 @@ BOOL WINAPI SetupComm(HANDLE handle, DWORD insize, > DWORD outsize) > */ > BOOL WINAPI GetCommMask(HANDLE handle, LPDWORD evtmask) > { > + DWORD dwBytesReturned; > TRACE("handle %p, mask %p\n", handle, evtmask); > return DeviceIoControl(handle, IOCTL_SERIAL_GET_WAIT_MASK, > - NULL, 0, evtmask, sizeof(*evtmask), NULL, NULL); > + NULL, 0, evtmask, sizeof(*evtmask), > &dwBytesReturned, NULL); > } > > /***************************************************************************** > @@ -755,9 +762,11 @@ BOOL WINAPI GetCommMask(HANDLE handle, LPDWORD evtmask) > */ > BOOL WINAPI SetCommMask(HANDLE handle, DWORD evtmask) > { > + DWORD dwBytesReturned; > + > TRACE("handle %p, mask %x\n", handle, evtmask); > return DeviceIoControl(handle, IOCTL_SERIAL_SET_WAIT_MASK, > - &evtmask, sizeof(evtmask), NULL, 0, NULL, NULL); > + &evtmask, sizeof(evtmask), NULL, 0, > &dwBytesReturned, NULL); > } > > static void dump_dcb(const DCB* lpdcb) > @@ -797,6 +806,7 @@ BOOL WINAPI SetCommState( HANDLE handle, LPDCB lpdcb) > SERIAL_LINE_CONTROL slc; > SERIAL_HANDFLOW shf; > SERIAL_CHARS sc; > + DWORD dwBytesReturned; > > if (lpdcb == NULL) > { > @@ -858,13 +868,13 @@ BOOL WINAPI SetCommState( HANDLE handle, LPDCB lpdcb) > * so flow control does not interfere. > */ > return (DeviceIoControl(handle, IOCTL_SERIAL_SET_BAUD_RATE, > - &sbr, sizeof(sbr), NULL, 0, NULL, NULL) && > + &sbr, sizeof(sbr), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_LINE_CONTROL, > - &slc, sizeof(slc), NULL, 0, NULL, NULL) && > + &slc, sizeof(slc), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_HANDFLOW, > - &shf, sizeof(shf), NULL, 0, NULL, NULL) && > + &shf, sizeof(shf), NULL, 0, > &dwBytesReturned, NULL) && > DeviceIoControl(handle, IOCTL_SERIAL_SET_CHARS, > - &sc, sizeof(sc), NULL, 0, NULL, NULL)); > + &sc, sizeof(sc), NULL, 0, &dwBytesReturned, > NULL)); > } > > > @@ -891,6 +901,7 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > SERIAL_LINE_CONTROL slc; > SERIAL_HANDFLOW shf; > SERIAL_CHARS sc; > + DWORD dwBytesReturned; > > TRACE("handle %p, ptr %p\n", handle, lpdcb); > > @@ -901,13 +912,13 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > } > > if (!DeviceIoControl(handle, IOCTL_SERIAL_GET_BAUD_RATE, > - NULL, 0, &sbr, sizeof(sbr), NULL, NULL) || > + NULL, 0, &sbr, sizeof(sbr), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_LINE_CONTROL, > - NULL, 0, &slc, sizeof(slc), NULL, NULL) || > + NULL, 0, &slc, sizeof(slc), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_HANDFLOW, > - NULL, 0, &shf, sizeof(shf), NULL, NULL) || > + NULL, 0, &shf, sizeof(shf), &dwBytesReturned, > NULL) || > !DeviceIoControl(handle, IOCTL_SERIAL_GET_CHARS, > - NULL, 0, &sc, sizeof(sc), NULL, NULL)) > + NULL, 0, &sc, sizeof(sc), &dwBytesReturned, NULL)) > return FALSE; > > memset(lpdcb, 0, sizeof(*lpdcb)); > @@ -980,8 +991,9 @@ BOOL WINAPI GetCommState(HANDLE handle, LPDCB lpdcb) > */ > BOOL WINAPI TransmitCommChar(HANDLE hComm, CHAR chTransmit) > { > + DWORD dwBytesReturned; > return DeviceIoControl(hComm, IOCTL_SERIAL_IMMEDIATE_CHAR, > - &chTransmit, sizeof(chTransmit), NULL, 0, > NULL, NULL); > + &chTransmit, sizeof(chTransmit), NULL, 0, > &dwBytesReturned, NULL); > } > > > @@ -1002,6 +1014,7 @@ BOOL WINAPI TransmitCommChar(HANDLE hComm, CHAR > chTransmit) > BOOL WINAPI GetCommTimeouts(HANDLE hComm, LPCOMMTIMEOUTS lptimeouts) > { > SERIAL_TIMEOUTS st; > + DWORD dwBytesReturned; > > TRACE("(%p, %p)\n", hComm, lptimeouts); > if (!lptimeouts) > @@ -1010,7 +1023,7 @@ BOOL WINAPI GetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > return FALSE; > } > if (!DeviceIoControl(hComm, IOCTL_SERIAL_GET_TIMEOUTS, > - NULL, 0, &st, sizeof(st), NULL, NULL)) > + NULL, 0, &st, sizeof(st), &dwBytesReturned, NULL)) > return FALSE; > lptimeouts->ReadIntervalTimeout = st.ReadIntervalTimeout; > lptimeouts->ReadTotalTimeoutMultiplier = > st.ReadTotalTimeoutMultiplier; > @@ -1043,6 +1056,7 @@ BOOL WINAPI GetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > BOOL WINAPI SetCommTimeouts(HANDLE hComm, LPCOMMTIMEOUTS lptimeouts) > { > SERIAL_TIMEOUTS st; > + DWORD dwBytesReturned; > > TRACE("(%p, %p)\n", hComm, lptimeouts); > > @@ -1058,7 +1072,7 @@ BOOL WINAPI SetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > st.WriteTotalTimeoutConstant = lptimeouts->WriteTotalTimeoutConstant; > > return DeviceIoControl(hComm, IOCTL_SERIAL_SET_TIMEOUTS, > - &st, sizeof(st), NULL, 0, NULL, NULL); > + &st, sizeof(st), NULL, 0, &dwBytesReturned, > NULL); > } > > /*********************************************************************** > @@ -1078,8 +1092,9 @@ BOOL WINAPI SetCommTimeouts(HANDLE hComm, > LPCOMMTIMEOUTS lptimeouts) > */ > BOOL WINAPI GetCommModemStatus(HANDLE hFile, LPDWORD lpModemStat) > { > + DWORD dwBytesReturned; > return DeviceIoControl(hFile, IOCTL_SERIAL_GET_MODEMSTATUS, > - NULL, 0, lpModemStat, sizeof(DWORD), NULL, > NULL); > + NULL, 0, lpModemStat, sizeof(DWORD), > &dwBytesReturned, NULL); > } > > /*********************************************************************** > > > Hi, your patches are corrupted by line wrapping.

Feb. 5, 2009

Re: ideas and questions for implementation of MessageMode in Named Pipes

by Luke Kenneth Casson Leighton

On Thu, Feb 5, 2009 at 1:34 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Luke, hi juan, thanks for responding. >> how about: ripping out the use of unix-pipes altogether, and replacing >> them with tdb (trivial database) in a mmap'd file? the nice thing > The usual response around here is, show us some patches, and we'll let > you know ;-) yehh, ha ha :) i was kinda hoping to not have to go through five different implementations! i think i've finally come up with an idea that i believe will work: double-socketing. very simple: you write down one filedescriptor, and read from a different one. wineserver proxies the data from one to the other, whenever it's requested. here's the important bit: wineserver ONLY allows ONE lot of data into the "read" socket at any one time. it'll be ok (and desirable) to allow multiple "readers" of the "read" socket. what you _don't_ want is more than one reader trying to indicate "please start sending a new message" whilst there are other reader(s) still grabbing the previous message. so i believe that a critical section (copying the style of the code around server_get_unix_fd) each around "please start a new message" and "please send some more read-data" would be sufficient. what do you think? also the advantage of double-socketing is that when it comes to doing SMB named pipes there will be a clean "way in and out" for SMBreadX, SMBwriteX and SMBtransactNamedPipe data over the IPC$ share. the double-sockets will still be needed (one for reading, one for writing) - a _third_ socket will be needed, to communicate with the smb server (via the break-out mechanism). > Some test cases showing us where we're deficient would be a great start, btw. all there, in #17195. five so far. * test1 (the first i wrote) just does send recv send recv. this one works (in existing wine) * send2recv2 does send send recv recv and it's this one that shows _immediately_ that there's a problem with wine's messagemode code. * shortread demonstrates the "standard" way to be able to read blocks of data when the message is _way_ beyond acceptable incoming buffer sizes (e.g. in smbs it was often the case that spoolss would result in SMBwriteX SMBwriteX SMBwriteX SMBtransactnamedpipe SMBreadX SMBreadX SMBreadX transferring _whopping_ great sized messages). again, wine keels over on this one as it doesn't know what to do at the message boundaries. * threadread demonstrates several messages being queued followed by a number of threads performing simultaneous reads (deliberately using shortreads where the individual reads are fixed sizes). i only have this doing 1 thread at the moment because the data needs to be "reconstructed" properly otherwise (even on nt). * threadwrite demonstrates several messages being written simultaneously, with a single process grabbing them all. this one _doesn't_ have to be limited in the number of threads that perform writes, which indicates in the internal design of NT that the writes are atomic.

Feb. 5, 2009

Re: include: Change some DWORD to DWORD_PTR in msacm.h.

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > Uwe Bonnes wrote: >>>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.de> writes: >> >> Michael> The change is for Win64 compatibility and it matches the DDK. >> -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance, >> DWORD fdwEnum) >> +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, >> DWORD_PTR dwInstance, DWORD fdwEnum) >> >> Is the spec aentry then still right? >> >> ./dlls/msacm32/msacm32.spec:@ stdcall acmDriverDetailsW(long ptr long) > For 32bit yes but if it will work for 64bit I have no clue. I don't > remember to have seen any Win64 fix patch that touched the spec file too > so I would have to defer the answer to this question to Alexandre. It's fine for 64-bit too. -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2009

Re: include: Change some DWORD to DWORD_PTR in msacm.h.

by Michael Stefaniuc

Uwe Bonnes wrote: >>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.de> writes: > > Michael> The change is for Win64 compatibility and it matches the DDK. > -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance, > DWORD fdwEnum) > +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, > DWORD_PTR dwInstance, DWORD fdwEnum) > > Is the spec aentry then still right? > > ./dlls/msacm32/msacm32.spec:@ stdcall acmDriverDetailsW(long ptr long) For 32bit yes but if it will work for 64bit I have no clue. I don't remember to have seen any Win64 fix patch that touched the spec file too so I would have to defer the answer to this question to Alexandre. bye michael

Feb. 5, 2009

Re: include: Change some DWORD to DWORD_PTR in msacm.h.

by Uwe Bonnes

>>>>> "Michael" == Michael Stefaniuc <mstefani(a)redhat.de> writes: Michael> The change is for Win64 compatibility and it matches the DDK. -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance, DWORD fdwEnum) +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD_PTR dwInstance, DWORD fdwEnum) Is the spec aentry then still right? ./dlls/msacm32/msacm32.spec:@ stdcall acmDriverDetailsW(long ptr long) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 5, 2009

Re: New Wine Gecko package

by Alistair Leslie-Hughes

Hi Jacek, "Jacek Caban" <jacek(a)codeweavers.com> wrote in message news:498A2A37.6070102(a)codeweavers.com... > Hi all, > > Also the last debug version was accidentally stripped. It will be fixed > in this release. I'm planning to do the release tomorrow, so it will be > in Git on Friday. I've test a few apps (TopStyle, Web Page maker), they appear to not crash any more than before ;). The patch attached didn't cleanly apply to todays git. (but did to a 1.1.14 tree) Best Regards Alistair Leslie-Hughes

Feb. 5, 2009