wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

Re: winsock stuff
by Alexandre Julliard 21 Aug '01

21 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > To improve on this patch we could only do the FIONREAD if the sock is > in a non-blocking state. That's the only time that doing the FIONREAD > would be an advantage. Also we wouldn't need to worry about screwing up > blocking sockets. Even further, we could only do the FIONREAD if socket > is non-blocking and looking for an FD_CLOSE event. Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > I noticed that WSAEnumNetworkEvents() was returning all events that had > occurred and not just the events that had been selected with > WSAEventsSelect(). Win98 will trigger the event object for all events > but WSAEnumNetworkEvents() (in win98) would return zero if the event > hadn't been selected. I was trying to gain compatibility with win98. I'd suggest doing the masking in WSAEnumNetworkEvents then. > An FD_READ event with a zero buffer would mean that the other side > closed the connection so it would be equivalent to a POLLHUP from poll() > .. I didn't find an occasion when poll() actually returned POLLHUP when > the socket closed, on Linux anyway. The application that I was testing > got confused when recv() returned zero. Even though recv() can legally > return zero, I think non-blocking applications are going to be looking > for FD_CLOSE events as opposed to recv() returning zero. But FIONREAD can return 0 bytes even when the socket isn't closed (for instance if another thread got the data first). You can only determine that it was really closed when you do the actual read. So I don't really see how we can avoid having recv() return zero; well maybe we can make it return EWOULDBLOCK and tell the server the connection is closed, but I'm not sure it's any better. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > -changed get_socket_event() so it only returns events that > the application is looking for. > -Changed sock_poll_event() to interpret a POLLIN event with > zero bytes waiting to be read as a POLLHUP. This doesn't look really right to me. Could you please explain a bit more what it is supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Refcounting in SelectObject
by Alexandre Julliard 20 Aug '01

20 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Appended code tries to clean up better by: > - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount > - Call DeleteObject in SelectObject when the RefCount of the released handle > is 0x8000 > - Decrementing the RefCount when a hBitmap is still selected into a DC when > DeleteDC is called for that DC > - Call DeleteObject in DeleteDC when RefCount is 0x8000 > > For some applications I tested, I always saw the delayed DeleteObject done > after the refused DeleteObject in the first place. Is this approach better? Yes, looks good. Though we can probably safely use the dwCount field in GDIOBJHDR since it is not used for anything useful right now, instead of adding new fields. I've changed that and applied the patch. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard 20 Aug '01

20 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Open serial ports with O_NONBLOCK if FILE_FLAG_OVERLAPPED is > specified. The open on the server side must always be non-blocking, we cannot have the server block on anything. If there are cases where we need to block on open, it will have to be done on the client side. -- Alexandre Julliard julliard(a)winehq.com

1 0

-clocal and the wineserver
by lawson_whitney＠juno.com 19 Aug '01

19 Aug '01

Good day! Any time clocal falls out of the modem's termios (say I use cu -l on it) the wineserver hangs trying to open it, or at least the app hangs, and I haven't found a way to kill it without killing the wineserver. Both 16 and 32 bit versions of juno are affected. I haven't really investigated it very thouroughly, but I wasted a lot of time restoring backup versions of the app and wine. Should I look into mickey-mousing the open to avoid the problem, or - is it really a wineserver problem which I am probably not even marginally competent to muck with? I'd be glad to make traces or winedbg output, but it seems the problem should be easy to duplicate. Hmmm, setting clocal back on from another terminal unhangs the app. That is neater than killing the wineserver, I guess. terminal.exe from wfw 3.11 behaves similarly, with an extra twist: it hangs on the Win16Mutex until somebody sets clocal (well, I guess carrier detect would work, too). [whit@giftie user0001]$ wine terminal.exe err:ntdll:RtlpWaitForCriticalSection section 0x400fad6c "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=008f fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default xterm: unable to open font "vga", trying "fixed".... Failed to open input method passed master doesn't match slave name passed master doesn't match slave name [whit@giftie user0001]$ Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: PATCH: olepictures black & white
by Alexandre Julliard 19 Aug '01

19 Aug '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Somehow the loaded JPEGs are now black & white in the IPicture implementation. > > Exchanging CreateCompatibleDC(0) by CreateDCA("DISPLAY",0,0,0); makes > them colored again. > > But I am not sure whether the problem itself was a bug on my side, or > on the WINE side... Maybe a bit of both... I think the patch below should fix the GDI part; but is there any reason you don't use GetDC(0) instead of CreateCompatibleDC? It would avoid creating a new DC every time. Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.60 diff -u -r1.60 dib.c --- objects/dib.c 2001/08/17 00:07:42 1.60 +++ objects/dib.c 2001/08/19 19:27:42 @@ -875,7 +875,9 @@ /* Now create the bitmap */ - if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); + if (fColor) + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + GetDeviceCaps( hdc, BITSPIXEL ), NULL ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

1 0

PATCH: oleauto header problem
by Nikolas Zimmermann 19 Aug '01

19 Aug '01

Hi there, Reaktivate doesn't compile anymore. We need this patch. Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel 19 Aug '01

19 Aug '01

At 02:35 PM 18/08/2001 -0700, you wrote: >For standard controls like buttons it should never be a problem since >there is both an ASCII and Unicode win proc, so in a pure ASCII app we >should never do the conversion. I think the problem is that the >dialog code does a CreateWindowW, so the button is Unicode even though >the app does everything in ASCII. I guess we'll have to maintain both >A and W win procs inside each window, not only inside the class. How about creating Ascii windows when the app calls DialogBox..A variants ? Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > How about creating Ascii windows when the app calls DialogBox..A variants ? That could be a workaround, but since dialog resources are Unicode it's better to avoid converting back and forth. Besides, Windows maintains two different win procs for windows of standard classes so we should do it this way too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

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