August 2001 - Wine-Devel - list.winehq.org

Re: winsock stuff

by Daniel Walker

This seems to work.. Daniel Walker --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/21 01:31:04 @@ -113,9 +113,14 @@ { struct sock *sock = (struct sock *)obj; unsigned int emask; + char rBuf; assert( sock->obj.ops == &sock_ops ); if (debug_level) fprintf(stderr, "socket %d select event: %x\n", sock->obj.fd, event); + + if (event == POLLIN && !recvfrom(sock->obj.fd, &rBuf, sizeof(rBuf), MSG_PEEK, NULL, NULL)) + event = POLLHUP; + if (sock->state & WS_FD_CONNECT) { /* connecting */

Aug. 21, 2001

Re: fix for Lawson's CLOCAL problem

by Mike McCormack

Hi Alexandre, Hmmm. i'm not exactly sure about this. i don't think the server ever blocked on serial port reads or opens... i think the reason Lawson had problems was that the client thread was blocking in the overlapped read code. (FILE_AsyncReadService in files/file.c) If we use non-blocking fds unconditionally, a non overlapped ReadFile may result in a busy loop in the client thread. Additionally, overlapped read (and write) requests should fail unless the handle is opened with FILE_FLAG_OVERLAPPED. There are programs that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on this list). This is another reason to propagate CreateFile's attributes parameter into the wineserver. Another question: do you think it would be possible to implement a "write memory" message from the wineserver to the client? This message would be carried over wait_fd and would be received by the client asynchronously in wait_reply(). The message would contain a length, address and data to be written. If this is possible, i could move async i/o back into the server, keep it efficient and perhaps implement CancelIo properly... Mike > 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. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Aug. 21, 2001

Re: winsock stuff

by Alexandre Julliard

Daniel Walker <diwalker(a)earthlink.net> writes: > How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to > using MSG_PEEK , just curios.. FIONREAD is unreliable because you cannot distinguish between an EOF condition and an empty receive buffer. recvmsg(MSG_PEEK) is supposed to return 0 on EOF, and EWOULDBLOCK on empty buffer, so you can determine the real status. > Another issue is why doesn't poll() give > us a POLLHUP? That would be ideal, get poll() to work the way we need it > too. As I understand it poll() returns POLLHUP only when both directions of the socket have been closed; but if you shutdown() only the read or write side, you don't get POLLHUP so that you can continue using poll() for the other direction. This has apparently been changed between kernels 2.2 and 2.4; in 2.2 POLLHUP is returned as soon as the read side of the socket has been closed. -- Alexandre Julliard julliard(a)winehq.com

Aug. 21, 2001

Re: winsock stuff

by Daniel Walker

Alexandre Julliard wrote: > > 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. How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to using MSG_PEEK , just curios.. Another issue is why doesn't poll() give us a POLLHUP? That would be ideal, get poll() to work the way we need it too. Daniel Walker

Aug. 21, 2001

Re: winsock stuff

by Alexandre Julliard

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

Aug. 21, 2001

Re: winsock stuff

by Daniel Walker

Alexandre Julliard wrote: > > 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. Ok. > > 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. The FIONREAD would happen before the application even knows there is a FD_READ event. This particular functionality is critical in my opinion .. I've never actually seen an FD_CLOSE event without this patch. If an application is looking for FD_CLOSE and never gets it then it's going to act unpredictably. 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. Daniel Walker

Aug. 20, 2001

propably simple

by Ibrahim Hamouda

I'm sorry for posting to the developers group, although I'm not one. I just have a simple question and the other news group is not helping. for three days now I'm trying to get an application connects to a MSSQL database on a windows box. I'm running the following: Mandrake 8.0 wine 20010731 windows 98 partition and sql server is installed on it My application is built in Powerbuilder 6.0. it comes up with the user name and password box which should be authenticated through the database. when I submit the user name and password I get the following error: [Microsoft][ODBC SQL SERVER DRIVER][TCP?IP SOCKET]General network error on the linux box I've already setup the MSSQL alias in the client connectivity utility of the sql server. I just want to know if I'm configuring the native and builtin wrong in my conf file or what I'm trying to do is not doable at all. I'll appreciate an answer so I can get some sleep, I'm literaly working on that for three days. Ibrahim Hamouda Internode Networks

Aug. 20, 2001

Re: winsock stuff

by Alexandre Julliard

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

Aug. 20, 2001

Re: winsock stuff

by Daniel Walker

> > -changed get_socket_event() so it only returns events that > > the application is looking for. 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. > > -Changed sock_poll_event() to interpret a POLLIN event with > > zero bytes waiting to be read as a POLLHUP. 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. The test application I wrote acts identical in both win98 and wine with the two changes above .. Daniel Walker Alexandre Julliard wrote: > > This doesn't look really right to me. Could you please explain a bit > more what it is supposed to fix?

Aug. 20, 2001

Re: Refcounting in SelectObject

by Alexandre Julliard

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

Aug. 20, 2001

Re: winsock stuff

by Alexandre Julliard

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

Aug. 20, 2001

Re: fix for Lawson's CLOCAL problem

by Alexandre Julliard

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

Aug. 20, 2001

-clocal and the wineserver

by lawson_whitney＠juno.com

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(a)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(a)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.

Aug. 19, 2001

Re: PATCH: olepictures black & white

by Alexandre Julliard

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

Aug. 19, 2001

PATCH: oleauto header problem

by Nikolas Zimmermann

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

Aug. 19, 2001

Re: WM_GETTEXTLENGTH change in winproc.c

by Gerard Patel

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

Aug. 19, 2001

Re: WM_GETTEXTLENGTH change in winproc.c

by Alexandre Julliard

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

Aug. 18, 2001

Re: WM_GETTEXTLENGTH change in winproc.c

by Gerard Patel

At 01:19 PM 18/08/2001 -0700, you wrote: > >The idea is that 6 Unicode chars can yield more than 6 ASCII chars >with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return >more than the actual size when mixing ASCII and Unicode. > >What does the app do exactly? Maybe there are cases where the >conversion can be avoided. WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the length returned by WM_GETTEXTLENGTH. If the app had used the length returned by WM_GETTEXT, it would have worked all right of course - maybe that's the reason why the problem does not appear more often ? In the following trace Cancel is the text of a button in a dialog box. Gerard 080682e8:Call window proc 0x5f404ae6 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetPropA(000026dc,5f49c94c "AfxOldWndProc423") ret=5f404b09 080682e8:Ret user32.GetPropA() retval=40ac0259 ret=5f404b09 080682e8:Call user32.CallWindowProcA(40ac0259,000026dc,0000002b,00000002,40586474) ret=5f404b4b 080682e8:Call window proc 0x406a7980 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call window proc 0x43d715 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetWindowLongA(000026dc,00000008) ret=0043d727 080682e8:Ret user32.GetWindowLongA() retval=40586914 ret=0043d727 080682e8:Call user32.GetWindowTextLengthA(00002e0c) ret=0043bb82 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH sent from self wp=00000000 lp=00000000 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000e,00000000,00000000) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] wp=00000000 lp=00000000 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=0000000c ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=0000000c trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH returned 0000000c 080682e8:Ret user32.GetWindowTextLengthA() retval=0000000c ret=0043bb82 080682e8:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 080682e8:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 080682e8:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 080682e8:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 080682e8:Call user32.GetWindowTextA(00002e0c,413904e0,0000000d) ret=0043bba9 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT sent from self wp=0000000d lp=413904e0 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000d,0000000d,413904e0) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] wp=0000000d lp=403a7328 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=00000006 ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) retval=00000006 trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT returned 00000006 080682e8:Ret user32.GetWindowTextA() retval=00000006 ret=0043bba9 <snip unrelated painting instructions> 080682e8:Call gdi32.GetTextExtentPoint32A(00000088,413b00d0,00000006,40585f68) ret=0043c022 080682e8:Call x11drv.GetTextExtentPoint(4037c808,4039d238,00000006,40585f68) ret=40747c04 trace:text:X11DRV_GetTextExtentPoint L"Cancel"... 6 080682e8:Ret x11drv.GetTextExtentPoint() retval=00000001 ret=40747c04 080682e8:Ret gdi32.GetTextExtentPoint32A() retval=00000001 ret=0043c022 <snip a few text painting preparation> 080682e8:Call user32.DrawTextA(00000088,413904e0 "Cancel",0000000c,40585f28,00000100) ret=0043c13a trace:text:DrawTextExW L"Cancel", 12 , [(9,4),(51,20)]

Aug. 18, 2001

Re: WM_GETTEXTLENGTH change in winproc.c

by Alexandre Julliard

Gerard Patel <gerard.patel(a)nerim.net> writes: > WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the > length returned by WM_GETTEXTLENGTH. > If the app had used the length returned by WM_GETTEXT, it would > have worked all right of course - maybe that's the reason why > the problem does not appear more often ? 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. -- Alexandre Julliard julliard(a)winehq.com

Aug. 18, 2001

WM_GETTEXTLENGTH change in winproc.c

by Gerard Patel

I don't understand it : case WM_GETTEXTLENGTH: 719 case CB_GETLBTEXTLEN: 720 case LB_GETTEXTLEN: 721 /* there may be one DBCS char for each Unicode char */ 722 return result * 2; This has a bad effect on one of my test apps - returns a length of 12 for a text of 6 characters, displays funny symbols after the text. The Unicode window proc returns 6, why the unicode/ascii conversion should make it 12 ? The Api returns number of chars, not bytes. Gerard

Aug. 18, 2001

Re: WM_GETTEXTLENGTH change in winproc.c

by Alexandre Julliard

Gerard Patel <gerard.patel(a)nerim.net> writes: > I don't understand it : > > case WM_GETTEXTLENGTH: > 719 case CB_GETLBTEXTLEN: > 720 case LB_GETTEXTLEN: > 721 /* there may be one DBCS char for each Unicode char */ > 722 return result * 2; > > This has a bad effect on one of my test apps - returns a length of 12 > for a text of 6 characters, displays funny symbols after the text. > > The Unicode window proc returns 6, why the unicode/ascii conversion > should make it 12 ? The Api returns number of chars, not bytes. The idea is that 6 Unicode chars can yield more than 6 ASCII chars with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return more than the actual size when mixing ASCII and Unicode. What does the app do exactly? Maybe there are cases where the conversion can be avoided. -- Alexandre Julliard julliard(a)winehq.com

Aug. 18, 2001

Re: not-yet-connected sockets?

by Ove Kaaven

On Sat, 18 Aug 2001, Daniel Walker wrote: > That seems to work .. Are there any other place where this POLLHUP > problem might show it's teeth? Doubt it. The previous patch concentrated all the issues of POLLHUP into that "if (...) return;" test, where it returns (and hence does not get polled) when the socket is still in the unconnected state where Linux may return POLLHUP... the only issue is that there may be other flags than WS_FD_NONBLOCKING that may mask the unconnected state, but I don't think so (for instance, UDP sockets does not have to be connected to be polled).

Aug. 18, 2001

Re: not-yet-connected sockets?

by Daniel Walker

That seems to work .. Are there any other place where this POLLHUP problem might show it's teeth? Daniel Walker Ove Kaaven wrote: > Aha. Then you'd probably want something like this, then? > > Index: server/sock.c > =================================================================== > RCS file: /home/wine/wine/server/sock.c,v > retrieving revision 1.18 > diff -u -r1.18 sock.c > --- server/sock.c 2001/05/14 20:09:39 1.18 > +++ server/sock.c 2001/08/18 15:00:53 > @@ -84,7 +84,7 @@ > > if (sock->obj.select == -1) { > /* previously unconnected socket, is this reselect supposed to connect it? */ > - if (!sock->state) return; > + if (!(sock->state & ~WS_FD_NONBLOCKING)) return; > /* ok, it is, attach it to the wineserver's main poll loop */ > add_select_user( &sock->obj ); > }

Aug. 18, 2001

Re: not-yet-connected sockets?

by Ove Kaaven

On Sat, 18 Aug 2001, Daniel Walker wrote: > Ove Kaaven wrote: > > > > On Fri, 17 Aug 2001, Daniel Walker wrote: > > > > > This fixes the problem that I'm seeing .. Any version of Bearshare seem > > > to be effected .. > > > > Well, this is not a correct patch of course (but you probably already knew > > that), but if this fixes something, I'd like to know what and why, as > > sock_reselect should never do a poll() unless sock->state is set, and > > sock->state should (in theory) not be set before a connect() or listen() > > is done on the socket. Do a --debugmsg +server,+winsock, please? > > From the trace it looks like sock->state is set the WD_FD_NONBLOCKING . > enable_socket_event() set's the sock->state to non-blocking then calls > sock_reselect. Aha. Then you'd probably want something like this, then? Index: server/sock.c =================================================================== RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.18 diff -u -r1.18 sock.c --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/18 15:00:53 @@ -84,7 +84,7 @@ if (sock->obj.select == -1) { /* previously unconnected socket, is this reselect supposed to connect it? */ - if (!sock->state) return; + if (!(sock->state & ~WS_FD_NONBLOCKING)) return; /* ok, it is, attach it to the wineserver's main poll loop */ add_select_user( &sock->obj ); }

Aug. 18, 2001

Re: not-yet-connected sockets?

by Daniel Walker

Ove Kaaven wrote: > > On Fri, 17 Aug 2001, Daniel Walker wrote: > > > This fixes the problem that I'm seeing .. Any version of Bearshare seem > > to be effected .. > > Well, this is not a correct patch of course (but you probably already knew > that), but if this fixes something, I'd like to know what and why, as > sock_reselect should never do a poll() unless sock->state is set, and > sock->state should (in theory) not be set before a connect() or listen() > is done on the socket. Do a --debugmsg +server,+winsock, please? From the trace it looks like sock->state is set the WD_FD_NONBLOCKING . enable_socket_event() set's the sock->state to non-blocking then calls sock_reselect. Daniel Walker

Aug. 18, 2001

Re: Toolbar background error

by Gerard Patel

At 06:54 PM 17/08/2001 -0700, you wrote: <snip> >But their solution is still not correct IMO. How about something like >this? All clear for me on this one, tested without problem for all of my test apps - at least the one surviving the Gdi lock slaughter :-) Gerard

Aug. 18, 2001

Re:CryptoAPI

by Ove Kaaven

On Fri, 17 Aug 2001, Eric Pouech wrote: > from an exportation point of view: > - some countries (US as an example) puts lots of contraints on the > type of crypto algo to be used outside of the US. So those shouldn't > be shipped with Wine's, but be provided as an external resource) Well, www.winehq.com is currently hosted in Canada, so it's not subject to US export laws (unless the coder that writes the code lives in US, of course)... and the export laws were liberated a bit a couple of years back too, you know.

Aug. 18, 2001

Re: not-yet-connected sockets?

by Ove Kaaven

On Fri, 17 Aug 2001, Daniel Walker wrote: > This fixes the problem that I'm seeing .. Any version of Bearshare seem > to be effected .. Well, this is not a correct patch of course (but you probably already knew that), but if this fixes something, I'd like to know what and why, as sock_reselect should never do a poll() unless sock->state is set, and sock->state should (in theory) not be set before a connect() or listen() is done on the socket. Do a --debugmsg +server,+winsock, please?

Aug. 18, 2001

Re: Toolbar background error

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > I suggest reading the Corel CVS for this part of the code. > > They rewrote this part like _5_ times. But their solution is still not correct IMO. How about something like this? Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.59 diff -u -r1.59 defwnd.c --- windows/defwnd.c 2001/08/10 22:51:43 1.59 +++ windows/defwnd.c 2001/08/18 00:21:43 @@ -461,10 +461,13 @@ HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); - DPtoLP( hdc, (LPPOINT)&rect, 2 ); + if (GetClassLongW( wndPtr->hwndSelf, GCL_STYLE ) & CS_PARENTDC) + { + /* can't use GetClipBox with a parent DC or we fill the whole parent */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + } + else GetClipBox( hdc, &rect ); FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

Aug. 18, 2001

dsound ??

by Bobby Bingham

Hello all, I completely rebuilt my computer a while back, and updated wine, so I'm not sure which is causing it, but not dsound doesn't seem to work where it did before. Starcraft doesn't play any music, sound, etc, but it's installer still plays it's sound (without dsound). Before this I hadn't updated WINE for a while, so I'm not sure when it broke. Bobby Bingham

Aug. 17, 2001

Re: Toolbar background error

by Gerard Patel

At 11:08 AM 17/08/2001 -0700, you wrote: >That's not what Windows does. If you pass a window DC to WM_ERASEBKGND >it only erases an area equivalent to the client area (shifted to be >relative to the whole window), so GetClientRect is correct IMO. The >non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. How do you test this under Windows ? In my test app, I have a white brush as class brush. So my window is white. If I add after the BeginPaint : GetClientRect(hwnd, &r); r.top += 200; FillRect(ps.hdc, &r, (HBRUSH) COLOR_WINDOW) the lower part of my window is painted with the beautiful window color (brown) Now if I add immediately after : hdc = GetWindowDC(hwnd); SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); ReleaseDC(hwnd, hdc); I get a window that is completely white; maybe I am missing something but I should see a small brown strip at the lower part of the window, corresponding to the caption + menu height, no ? Gerard

Aug. 17, 2001

Re: Toolbar background error

by Gerard Patel

At 02:33 PM 17/08/2001 GMT, you wrote: <snip> >So how does an application modify the location of the client rectangle >after it has been created? By changing rgrc[0] when responding to WM_NCCALCSIZE. It seems that it is only possible to erase properly the 'custom' nonclient area by using GetWindowDC... So : --- defwnd.c.orig Sat Aug 11 10:23:18 2001 +++ defwnd.c Fri Aug 17 19:47:17 2001 @@ -462,8 +462,12 @@ if (!hbr) return 0; /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); + * Windows does, and it breaks badly with CS_PARENTDC + * GetClientRect breaks too when we are called with a window + * DC (!!) - what next ? */ + rect.left = rect.top = 0; + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; DPtoLP( hdc, (LPPOINT)&rect, 2 ); FillRect( hdc, &rect, hbr ); return 1; What do you think ? Gerard

Aug. 17, 2001

Re: Toolbar background error

by Marcus Meissner

On Fri, Aug 17, 2001 at 07:53:46PM +0000, Gerard Patel wrote: > At 02:33 PM 17/08/2001 GMT, you wrote: > > <snip> > >So how does an application modify the location of the client rectangle > >after it has been created? > > By changing rgrc[0] when responding to WM_NCCALCSIZE. > It seems that it is only possible to erase properly the 'custom' nonclient > area by using GetWindowDC... So : > > --- defwnd.c.orig Sat Aug 11 10:23:18 2001 > +++ defwnd.c Fri Aug 17 19:47:17 2001 > @@ -462,8 +462,12 @@ > if (!hbr) return 0; > > /* GetClientRect used to be GetClipBox, but it is not what > - * Windows does, and it breaks badly with CS_PARENTDC */ > - GetClientRect( wndPtr->hwndSelf, &rect ); > + * Windows does, and it breaks badly with CS_PARENTDC > + * GetClientRect breaks too when we are called with a window > + * DC (!!) - what next ? */ > + rect.left = rect.top = 0; > + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; > + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; > DPtoLP( hdc, (LPPOINT)&rect, 2 ); > FillRect( hdc, &rect, hbr ); > return 1; > > What do you think ? I suggest reading the Corel CVS for this part of the code. They rewrote this part like _5_ times. Ciao, Marcus

Aug. 17, 2001

Re: Toolbar background error

by Alexandre Julliard

Gerard Patel <gerard.patel(a)nerim.net> writes: > Now if I add immediately after : > > hdc = GetWindowDC(hwnd); > SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); > ReleaseDC(hwnd, hdc); > > I get a window that is completely white; maybe I am missing something but > I should see a small brown strip at the lower part of the window, corresponding > to the caption + menu height, no ? Yes; actually I realize now that my test app uses the CS_PARENTDC style, which is why I see that. The behavior that you observe is what happens without CS_PARENTDC; so it's actually more complex that I thought, we'll need to explicitly test the CS_PARENTDC flag. Sigh... -- Alexandre Julliard julliard(a)winehq.com

Aug. 17, 2001

Re: Problems building with extern inline functions in winebase.h

by John Alvord

True... But at least in Linux source, inlines are used deliberately and with every expectation that the compiler will inline those routines. Linux is very focussed on superb performance and doesn't want any stupid compiler tricks to mess around with the code. I have no idea how this applies to the WINE philosphy. I generally use inlines only for very small functions. john On Fri, 17 Aug 2001, J. Cone wrote: > I would have thought any inlining would enlarge a program > compared with single-copy-and-call functions. > > Extern inline would imply that there had to be an un-inlined copy > somewhere to advertise to the linker, sort of like a weak symbol. > > At 07:56 17/08/01 -0700, John Alvord wrote: > >On Fri, 17 Aug 2001, Mike Bond wrote: > > > >> On Thu, Aug 16, 2001 at 10:37:39AM -0700, Alexandre Julliard wrote: > >> > This patch should fix the build failure, though it doesn't explain why > >> > gcc doesn't inline such a simple function. > > <snip: static inline causes more bloat than extern inline > > > >Linux itself just went through a transformation of extern inline into > >static inline. It was triggered by a change in gcc, presumably for the > >better. There was some on-list grumbling, but the change was necessary. > > > >john > >

Aug. 17, 2001

Re: Toolbar background error

by Alexandre Julliard

Gerard Patel <gerard.patel(a)nerim.net> writes: > By changing rgrc[0] when responding to WM_NCCALCSIZE. > It seems that it is only possible to erase properly the 'custom' nonclient > area by using GetWindowDC... So : > > --- defwnd.c.orig Sat Aug 11 10:23:18 2001 > +++ defwnd.c Fri Aug 17 19:47:17 2001 > @@ -462,8 +462,12 @@ > if (!hbr) return 0; > > /* GetClientRect used to be GetClipBox, but it is not what > - * Windows does, and it breaks badly with CS_PARENTDC */ > - GetClientRect( wndPtr->hwndSelf, &rect ); > + * Windows does, and it breaks badly with CS_PARENTDC > + * GetClientRect breaks too when we are called with a window > + * DC (!!) - what next ? */ > + rect.left = rect.top = 0; > + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; > + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; > DPtoLP( hdc, (LPPOINT)&rect, 2 ); > FillRect( hdc, &rect, hbr ); > return 1; > > What do you think ? That's not what Windows does. If you pass a window DC to WM_ERASEBKGND it only erases an area equivalent to the client area (shifted to be relative to the whole window), so GetClientRect is correct IMO. The non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. -- Alexandre Julliard julliard(a)winehq.com

Aug. 17, 2001

Re: err:module:map_image Could not map section .data, file probably truncated

by eric pouech

mdew wrote: > > On Fri, 17 Aug 2001 13:50:53 +0200 > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > > > >>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: > > > > mdew> a number of apps that wouldve worked normally ..are now failing to > > mdew> load due to this error.. err:module:map_image Could not map > > mdew> section .data, file probably truncated /usr/local/bin/wine: can't > > mdew> exec './xxx.exe': error=21 -- > > > > Did the files perhaps catch a Virus? > > no > > loaded fine under a older version of wine...just not the cvs are the older versions still working ? did you upgrade your system (kernel for example?) in between ? do all apps exhibit the same problems what is your setup... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 17, 2001

Re: err:module:map_image Could not map section .data, file probably truncated

by mdew

On Fri, 17 Aug 2001 13:50:53 +0200 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > >>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: > > mdew> a number of apps that wouldve worked normally ..are now failing to > mdew> load due to this error.. err:module:map_image Could not map > mdew> section .data, file probably truncated /usr/local/bin/wine: can't > mdew> exec './xxx.exe': error=21 -- > > Did the files perhaps catch a Virus? no loaded fine under a older version of wine...just not the cvs -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

Aug. 17, 2001

Re: CryptoAPI

by Dan Kegel

Travis Michielsen wrote: > I was going to start implementing the Cypto API (in advapi32.dll) over the > next few weeks. As of yet these functions are no more than stubs. However, > I am finding increased use of this API as more applications becomed > networkable and relying more heavily on internet connections. > > I was hoping to implement these functions by using the OpenSSL library > (if/when available). This library seems to have similar capabilities. > > One of my concerns is about legal issues. What special concerns should I > note about cryptographic software? Are there any special copyright issues I > should be aware of? OpenSSL appears to have a very liberal license -- the only restriction is that you have to credit the original author. So it's like the original BSD licenses. > Another question is about design. M$ seems to split the cryptographic > software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). > Should I do this as well so that, applications can use the native dlls if > necessary or should I simply implement it entirely though advapi32.dll which > and avoid the need to create several new (and very small) dlls under wine? > Because most of the code is already in another library (OpenSSL) creating > extra dlls seems abit unnecessary. Depends on whether any real world apps use those individual DLL's. If not, then you're free to combine them all. Another question is whether to statically link in OpenSSL, or use dynamic linking (early or late). I'm very interested in OpenSSL stuff, and have integrated OpenSSL support into a nonblocking server at work. I found the OpenSSL list very helpful. - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 17, 2001

Re: Does Wine's winhlp work?

by Gerard Patel

At 02:43 PM 17/08/2001 +0200, you wrote: >I was about to ask the same question. My impression was that: >i) 'winhelp' is completely non-functional <snip> I think so - I have never found one help file that it can read. Gerard

Aug. 17, 2001

Re: Problems building with extern inline functions in winebase.h

by Mike Bond

In general, that is correct. The problem in the case of gcc 2.96 is that it appears to actually be not inlining the function at all in a non-optimized build and further is putting the actual function in all objects generated from source that included the headers that defined the static inline function, even those that did not use it. I may be wrong on this, but given my limited digging through gcc this appears to be what is happening. As for extern inline, yes, that may well be why they got away from that syntax, as it does indeed suggest an external symbol somewhere. On Fri, Aug 17, 2001 at 04:34:02PM +0100, J. Cone wrote: > I would have thought any inlining would enlarge a program > compared with single-copy-and-call functions. > > Extern inline would imply that there had to be an un-inlined copy > somewhere to advertise to the linker, sort of like a weak symbol. -- TTFN MikeB

Aug. 17, 2001

Re:CryptoAPI

by Eric Pouech

from a pure technical point of view, the crypto API is in a pure WOSA style : - a set of high level API (in advapi) - an extendable set of low level service providers (here for example the crypto algos - RSA....) - the high level maps the fonctional request of the user onto on of the available SP. so, my advice here would be to implement this type of scheme. This would allow to: - use native DLLs if they exist (and go beyond what's supported by Linux) - still allow to use Linux lib (just build a wrapper DLL to that lib) and you should be all set from a copyright point of view: - Wine use a X11 like licence, so make sure all the external libs you use are not GPL (LGPL is fine). If they are GPL, you won't be able to ship the result with Wine. - Use of native DLL is granted as long as you have a Windows licence on the target machine (native DLLs shall not be shipped with Wine, Wine should be configured to use the local resources) from an exportation point of view: - some countries (US as an example) puts lots of contraints on the type of crypto algo to be used outside of the US. So those shouldn't be shipped with Wine's, but be provided as an external resource) > Hi, > > I was going to start implementing the Cypto API (in advapi32.dll) over the > next few weeks. As of yet these functions are no more than stubs. However, > I am finding increased use of this API as more applications becomed > networkable and relying more heavily on internet connections. > > I was hoping to implement these functions by using the OpenSSL library > (if/when available). This library seems to have similar capabilities. > > One of my concerns is about legal issues. What special concerns should I > note about cryptographic software? Are there any special copyright issues I > should be aware of? > > Another question is about design. M$ seems to split the cryptographic > software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). > Should I do this as well so that, applications can use the native dlls if > necessary or should I simply implement it entirely though advapi32.dll which > and avoid the need to create several new (and very small) dlls under wine? > Because most of the code is already in another library (OpenSSL) creating > extra dlls seems abit unnecessary. > > - Travis > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

Aug. 17, 2001

Re: Problems building with extern inline functions in winebase.h

by J. Cone

I would have thought any inlining would enlarge a program compared with single-copy-and-call functions. Extern inline would imply that there had to be an un-inlined copy somewhere to advertise to the linker, sort of like a weak symbol. At 07:56 17/08/01 -0700, John Alvord wrote: >On Fri, 17 Aug 2001, Mike Bond wrote: > >> On Thu, Aug 16, 2001 at 10:37:39AM -0700, Alexandre Julliard wrote: >> > This patch should fix the build failure, though it doesn't explain why >> > gcc doesn't inline such a simple function. <snip: static inline causes more bloat than extern inline > >Linux itself just went through a transformation of extern inline into >static inline. It was triggered by a change in gcc, presumably for the >better. There was some on-list grumbling, but the change was necessary. > >john

Aug. 17, 2001

Re: Problems building with extern inline functions in winebase.h

by John Alvord

On Fri, 17 Aug 2001, Mike Bond wrote: > On Thu, Aug 16, 2001 at 10:37:39AM -0700, Alexandre Julliard wrote: > > This patch should fix the build failure, though it doesn't explain why > > gcc doesn't inline such a simple function. > > This indeed allow me to build. My guess is that gcc-2.96 won't inline > anything in a debug build. The suggestion about 'static inline' instead > of 'extern inline' worked right up until it got to the file that actually > implemented the various functions in question, at which point the > compiler complained about the two definitions not matching, one being > static the other not. My guess as to why the 'static inline' would work > is that while it would still not actually inline it in a debug build, > it is providing a static implementation to each file that includes > winbase.h. This is horrible bloat for debug builds as many files that > do not need it will get those functions anyway. It would still be nice > if there could be a way to inline those various functions in a more > generic way so anything built against winelib outside of the scheduler > could take advantage of the inlining, but I really don't see, the way > inline is being interpreted in 2.96, that this could be done. Linux itself just went through a transformation of extern inline into static inline. It was triggered by a change in gcc, presumably for the better. There was some on-list grumbling, but the change was necessary. john

Aug. 17, 2001

Re: Toolbar background error

by Bill Medland

Gerard Patel <gerard.patel(a)nerim.net> wrote in article <1.5.4.32.20010817004913.4187264c(a)pop.nerim.net>... > At 05:10 PM 16/08/2001 GMT, you wrote: > > >It's the client rectangle in the toolbar (I believe). I've handed the > >issue back to Guy. > > I think that's a general issue, not specific to toolbars. > We are seeing it for toolbars because it's a trick that is used mainly > for toolbars. > > What happens I think is that some apps are not satisfied with the standard > toolbar look. They want to have a bigger border around the buttons. > That is not provided by the standard control, at least when these apps > were written (maybe it is now, I am not following these matters closely). > > What these apps are doing is playing with WM_NCCALCSIZE to restrict > the client rectangle to something smaller than what remains when > the system clips the true nonclient area. In the case of one of my test > apps, this is done by subclassing (the Wine code is never called). > > Since GetWindowRect returns only the width and the height of the > client area, and is setting the origin to 0 - 0, the custom client area > appears higher that it is to WM_ERASEBKGND and the lower part of > the window is not painted (toolbar in the case of the app I see) > > Now, I don't know yet how should be done the erasing of this custom > nonclient area :-/ > > Gerard > > > > > Now that makes sense to me. The example I am working with is the MSDN ROWLIST sample which is unfortunately MFC (I prefer using Petzold examples because that is purer code). According to Spy++ I saw the NC_CALCSIZE calls happening on windows. (The messages during the Toolbar creation during the main window creation are: WM_CREATE for the main application windows ... WM_NCCREATE (Sends WM_NOTIFYPARENT) WM_NCCALCSIZE WM_CREATE WM_SIZE WM_MOVE WM_SHOWWINDOW {*2 TB_SETBITMAPSIZE (16,15) WM_STYLECHANGING/CHANGED * 2 TB_SETBUTTONSIZE (23,22) WM_STYLECHANGING/CHANGED * 2 } Now spy++ tells me that the Client Rectangle is (8,5) to (208, 27) (which as far as I understand is measured relative to the innermost pixel of the application window border inclusive of it). So how does an application modify the location of the client rectangle after it has been created? Bill

Aug. 17, 2001

Re: Problems building with extern inline functions in winebase.h

by Mike Bond

On Thu, Aug 16, 2001 at 10:37:39AM -0700, Alexandre Julliard wrote: > This patch should fix the build failure, though it doesn't explain why > gcc doesn't inline such a simple function. This indeed allow me to build. My guess is that gcc-2.96 won't inline anything in a debug build. The suggestion about 'static inline' instead of 'extern inline' worked right up until it got to the file that actually implemented the various functions in question, at which point the compiler complained about the two definitions not matching, one being static the other not. My guess as to why the 'static inline' would work is that while it would still not actually inline it in a debug build, it is providing a static implementation to each file that includes winbase.h. This is horrible bloat for debug builds as many files that do not need it will get those functions anyway. It would still be nice if there could be a way to inline those various functions in a more generic way so anything built against winelib outside of the scheduler could take advantage of the inlining, but I really don't see, the way inline is being interpreted in 2.96, that this could be done. -- TTFN MikeB

Aug. 17, 2001

CryptoAPI

by Travis Michielsen

Hi, I was going to start implementing the Cypto API (in advapi32.dll) over the next few weeks. As of yet these functions are no more than stubs. However, I am finding increased use of this API as more applications becomed networkable and relying more heavily on internet connections. I was hoping to implement these functions by using the OpenSSL library (if/when available). This library seems to have similar capabilities. One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of? Another question is about design. M$ seems to split the cryptographic software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). Should I do this as well so that, applications can use the native dlls if necessary or should I simply implement it entirely though advapi32.dll which and avoid the need to create several new (and very small) dlls under wine? Because most of the code is already in another library (OpenSSL) creating extra dlls seems abit unnecessary. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Aug. 17, 2001

Re: not-yet-connected sockets?

by Daniel Walker

Ove Kaaven wrote: > > On Fri, 17 Aug 2001, Daniel Walker wrote: > > > Ove Kaaven wrote: > > > > > > On Thu, 16 Aug 2001, Daniel Walker wrote: > > > > > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > > > then wine ignores the socket and it's events .. I realize this has been > > > > known for a some time(since linux 2.4), but why hasn't it been fix? > > > > Doesn't this effect a lot of non-blocking socket applications? > > > > > > No, since this problem was fixed half a year ago, it shouldn't affect > > > anything. > > > > It must not be completely fixed.. Where is the patch that fixed it? > > http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12 This fixes the problem that I'm seeing .. Any version of Bearshare seem to be effected .. Daniel Walker Index: sock.c =================================================================== RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.18 diff -u -r1.18 sock.c --- sock.c 2001/05/14 20:09:39 1.18 +++ sock.c 2001/08/17 12:58:03 @@ -548,7 +548,7 @@ sock->hmask &= ~req->mask; sock->state |= req->sstate; sock->state &= ~req->cstate; - sock_reselect( sock ); +/* sock_reselect( sock ); */ /* service trigger */ if (req->mask & WS_FD_SERVEVENT)

Aug. 17, 2001

Re: not-yet-connected sockets?

by Ove Kaaven

On Fri, 17 Aug 2001, Daniel Walker wrote: > Ove Kaaven wrote: > > > > On Thu, 16 Aug 2001, Daniel Walker wrote: > > > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > > then wine ignores the socket and it's events .. I realize this has been > > > known for a some time(since linux 2.4), but why hasn't it been fix? > > > Doesn't this effect a lot of non-blocking socket applications? > > > > No, since this problem was fixed half a year ago, it shouldn't affect > > anything. > > It must not be completely fixed.. Where is the patch that fixed it? http://www.winehq.com/cvsweb/wine/server/sock.c.diff?r1=1.11&r2=1.12

Aug. 17, 2001

Re: not-yet-connected sockets?

by Daniel Walker

Ove Kaaven wrote: > > On Thu, 16 Aug 2001, Daniel Walker wrote: > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > then wine ignores the socket and it's events .. I realize this has been > > known for a some time(since linux 2.4), but why hasn't it been fix? > > Doesn't this effect a lot of non-blocking socket applications? > > No, since this problem was fixed half a year ago, it shouldn't affect > anything. It must not be completely fixed.. Where is the patch that fixed it? Daniel Walker

Aug. 17, 2001