wine-devel February 2009

wine-devel@winehq.org

143 participants
298 discussions

Re: New Wine Gecko package
by James Mckenzie 05 Feb '09

05 Feb '09

Jacek Caban <jacek(a)codeweavers.com> wrote: >Sent: Feb 5, 2009 12:28 PM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Scott Ritchie <scott(a)open-vote.org>, wine-devel <wine-devel(a)winehq.org> >Subject: Re: New Wine Gecko package > >James Mckenzie wrote: >> Jacek Caban <jacek(a)codeweavers.com> wrote: >> >>> Scott Ritchie wrote: >>> >>>> Is this version compatible with Wine 1.0.1 by chance? >>>> >>>> >>> No, it's technically impossible. >>> >>> >> Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko or will we have to wait until 1.2 (that is the next stable release)? >> > >No, it would require too much risky changes. The fact that we need a >bugfix release proves that it's a bad idea. This is your opinion and I respect it as you have more experience with Gecko than I. > >Also I don't see any point in upgrading Gecko in 1.0 branch. > It depends on the timeline for the 1.2 release. If this is a long way off, it may be worth the effort. If it is a matter of months, then the effort would not be worth it, since this would be a major project. James McKenzie

1 0

Re: [PATCH] mshtml: Fixed last argument to MBtoWC
by Rob Shearman 05 Feb '09

05 Feb '09

2009/2/4 Marcus Meissner <marcus(a)jet.franken.de>: > @@ -442,7 +442,7 @@ static LPWSTR get_url(void) > > if(size > sizeof(httpW) && !memcmp(url, httpW, sizeof(httpW))) { > strcatW(url, v_formatW); > - MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, url+strlenW(url), -1); > + MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, url+strlenW(url), (size-strlenW(url))/sizeof(WCHAR)); Dividing a string length (which returns character count) by sizeof(WCHAR) doesn't look right. -- Rob Shearman

2 1

ideas and questions for implementation of MessageMode in Named Pipes
by Luke Kenneth Casson Leighton 05 Feb '09

05 Feb '09

ok, alexandre: i tried moving named_pipe_read into wineserver - it's not possible to do completely, as you cannot do blocking-reads in wineserver but you still need blocking-read characteristics in the client (kernel32, ntdll). if you start messing with the fd, setting or clearing ioctl O_NONBLOCK in one, it interferes with the other. there's a race-condition risk. so, i have some ideas and questions. 1) is it possible for wineserver to tell a thread to wait indefinitely? is there a communication channel where wineserver can tell "anyone who's interested" to go away, go to sleep, i'll tell you when to wake up"? what i want is to replace the fd blocking-read with something that still blocks, but doesn't interfere with the file descriptor. 2) would a _second_ filedescriptor fit the required criteria, as described in 1), above? in other words, if the message-lengths (4 bytes) were sent on a secondary control fd - and nothing _but_ message-lengths were sent on that fd - my intuition tells me that that could work, even without having any infrastructure in wineserver. in fact, i get the feeling that it would be _better_ - and a lot simpler - than having any infrastructure in wineserver. the reasoning goes roughly something like this: * 5 threads are waiting - blocking - on a message-mode read named pipe. all of them are blocking to read from the "control" channel, in userspace (kernel32/ntdll). * client 1 does a message-mode write, and in userspace (kernel32/ntdll) 4 bytes indicating the length of the message are sent, followed by N bytes on the unix_fd (exactly as is done at the moment). * one and ONLY one of the 5 threads, thanks to STANDARD linux kernel scheduling, happens to be awake and gets to read the 4-byte length. all the other 4 stay asleep. damnit, that's not right, is it. you want the other 4 to wake up once ONE of them has read the 4-byte length, and for ALL of them to move on to blocking on the "message" pipe - the actual content. so, i suppose what you could do is have a per-read-thread filedescriptor (!!!) which _would_ have to involve arbitration by wineserver, so that when a write is performed, ALL of the clients get notified "wake up now, start trying to read". is there _anything_ in wine which already exists that does what is required, as illustrated, above? answers and information greatly appreciated so as to be able to improve this free software project's effectiveness. l.

2 7

Re: New Wine Gecko package
by James Mckenzie 05 Feb '09

05 Feb '09

Jacek Caban <jacek(a)codeweavers.com> wrote: > >Scott Ritchie wrote: >> Jacek Caban wrote: >> >>> Hi all, >>> >>> The last release of Wine Gecko caused a few regressions. Thanks to >>> Alexandre, we've found the reason. The bad news is that the fix requires >>> a new package. I've uploaded RC build to: >>> >>> http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko-0.9.1.cab >>> >>> I'd appreciate if people that observe the regression (mostly strange >>> crashed) could retest bugs with this build. To do so, you will need the >>> new package and the attached patch. Also quick tests with random apps >>> would be nice. This is a bugfix release based on the same codebase as >>> 0.9.0 version so I don't expect any new regressions with it. >>> >>> >> >> Is this version compatible with Wine 1.0.1 by chance? >> > >No, it's technically impossible. > Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko or will we have to wait until 1.2 (that is the next stable release)? James McKenzie

2 1

bugzilla stuck?
by Dan Kegel 05 Feb '09

05 Feb '09

It seems hung to me at the moment...

3 3

Re: [PATCH] advapi32: fixed second buffer argument to MBtoWC and WCtoMB
by Alexandre Julliard 05 Feb '09

05 Feb '09

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

1 0

Re: [RESEND] comctl32: Save and restore colours when adding masked images
by Alexandre Julliard 05 Feb '09

05 Feb '09

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

1 0

Re: avifil32: ukranian translation by Artem Reznikov
by Alexandre Julliard 05 Feb '09

05 Feb '09

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

1 0

Re: kernel32: DeviceIoControl: lpBytesReturned must not be NULL if lpOverlapped is NULL
by Nikolay Sivov 05 Feb '09

05 Feb '09

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.

1 0

Re: include: Change some DWORD to DWORD_PTR in msacm.h.
by Uwe Bonnes 05 Feb '09

05 Feb '09

>>>>> "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 ----------

3 2

← Newer
1
...
22
23
24
25
26
27
28
29
30
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 February 2009