April 2002 - Wine-Devel - list.winehq.org

Re: freetype.c:1852: conflicting types for `WineEngGetTextExtentPointI'

by Huw Davies

On Thu, Apr 04, 2002 at 06:12:43AM -0800, Andriy Palamarchuk wrote: > After refreshing today morning from CVS I got the > compilation error. > The complete error text: > > freetype.c:1852: conflicting types for > `WineEngGetTextExtentPointI' > ../../include/font.h:102: previous declaration of > `WineEngGetTextExtentPointI' > make[2]: *** [freetype.o] Error 1 > make[2]: Leaving directory > `/mnt/buf/prj/wine/dlls/gdi' > make[1]: *** [gdi/gdi32.dll.so] Error 2 > make[1]: Leaving directory `/mnt/buf/prj/wine/dlls' > make: *** [dlls] Error 2 > > Huw, can it be because of your yesterday's patch? > Other relevant patch is Alexandre's change to > configure. > > Let me know if you need additional information. Alexandre changed the LPWORD to const WORD* in my patch but I guess forgot to change the type in dlls/gdi/font.c . There's already a patch in wine-patches that should fix this. Huw. -- Huw Davies huw(a)codeweavers.com

April 4, 2002

freetype.c:1852: conflicting types for `WineEngGetTextExtentPointI'

by Andriy Palamarchuk

After refreshing today morning from CVS I got the compilation error. The complete error text: freetype.c:1852: conflicting types for `WineEngGetTextExtentPointI' ../../include/font.h:102: previous declaration of `WineEngGetTextExtentPointI' make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/mnt/buf/prj/wine/dlls/gdi' make[1]: *** [gdi/gdi32.dll.so] Error 2 make[1]: Leaving directory `/mnt/buf/prj/wine/dlls' make: *** [dlls] Error 2 Huw, can it be because of your yesterday's patch? Other relevant patch is Alexandre's change to configure. Let me know if you need additional information. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 4, 2002

[PATCH] Move send() functionality to WS2_32 code

by Martin Wilck

PATCH: Move send() functionality to WS2_32 code In short, does the same to send() that the previous patch did to recv(). For the send() family of functions, WSASendTo() becomes the work horse. All other functions (WSASend(), send(), sendto(), ...) are only wrappers around WSASendTo(). To provide the scatter/gather functionality of WSASendTo(), the Unix system call used as backend is sendmsg() rather than sendto(). Patch against: Wine CVS 2002-04-03, with my previous patch (recv) applied. Test status: Compiles, no warnings. Tested with 16 bit apps: FreeAgent (newsreader), Solstice mail, nslookup, teraterm (telnet) (16 bit apps now call WS2_32 code!) Modified files: dlls/winsock : socket.c, ws2_32.spec diff -ruNX diffignore TMP/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- TMP/wine/dlls/winsock/socket.c Thu Apr 4 10:58:53 2002 +++ MW/wine/dlls/winsock/socket.c Thu Apr 4 11:01:03 2002 @@ -1944,34 +1944,13 @@ */ int WINAPI WS_send(SOCKET s, const char *buf, int len, int flags) { - int fd = _get_sock_fd(s); + DWORD n; + WSABUF wsabuf = { len, (char*) buf }; - TRACE("socket %04x, ptr %p, length %d, flags %d\n", s, buf, len, flags); - if (fd != -1) - { - int length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: exceptfds */ - do_block(fd, 2); - } - if ((length = send(fd, buf, len, flags)) < 0 ) - { - SetLastError(wsaErrno()); - if( GetLastError() == WSAEWOULDBLOCK ) - _enable_event(s, FD_WRITE, 0, 0); - } - else - { - close(fd); - return length; - } - close(fd); - } - else SetLastError(WSAENOTSOCK); - return SOCKET_ERROR; + if ( WSASendTo ( s, &wsabuf, 1, &n, flags, NULL, 0, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; + else + return n; } /*********************************************************************** @@ -1982,43 +1961,106 @@ LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) { - INT iFlags = 0; - INT rc = 0; - DWORD dwCount; - - /* Overlapped is not supported or checked for */ - FIXME( "(%u,%p,0x%lx,%p,0x%lx,%p,%p): semi stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesSent, - dwFlags, lpOverlapped, lpCompletionRoutine ); - - /* Convert setup flags */ - if( dwFlags & MSG_DONTROUTE ) - { - iFlags |= MSG_DONTROUTE; - } - - if( dwFlags & MSG_OOB ) - { - iFlags |= MSG_OOB; - } - - /* Indicate nothing yet sent */ - *lpNumberOfBytesSent = 0; - - /* Send all buffers with the same flags */ - for(dwCount = 0; dwCount < dwBufferCount; dwCount++ ) - { - if( ( rc = WS_send( s, lpBuffers[ dwCount ].buf, - lpBuffers[ dwCount ].len, iFlags ) ) != 0 ) + return WSASendTo ( s, lpBuffers, dwBufferCount, lpNumberOfBytesSent, dwFlags, + NULL, 0, lpOverlapped, lpCompletionRoutine ); +} + +/*********************************************************************** + * WSASendTo (WS2_32.74) + */ +INT WINAPI WSASendTo( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, + LPDWORD lpNumberOfBytesSent, DWORD dwFlags, + const struct WS_sockaddr *to, int tolen, + LPWSAOVERLAPPED lpOverlapped, + LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) +{ + int i, n, fd, err = WSAENOTSOCK; + struct iovec* iovec; + struct msghdr msghdr; + + TRACE ("socket %04x, wsabuf %p, nbufs %ld, flags %ld, to %p, tolen %d, ovl %p, func %p\n", + s, lpBuffers, dwBufferCount, dwFlags, + to, tolen, lpOverlapped, lpCompletionRoutine); + + fd = _get_sock_fd(s); + + if ( fd == -1 ) + goto error; + + iovec = WS_ALLOC ( dwBufferCount * sizeof (struct iovec) ); + + if ( !iovec ) + { + err = WSAENOBUFS; + goto err_close; + } + + for ( i = 0; i < dwBufferCount; i++ ) + { + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; + } + + msghdr.msg_name = NULL; + + if (to) + { +#if DEBUG_SOCKADDR + dump_sockaddr (to); +#endif + msghdr.msg_name = (void*) ws_sockaddr_ws2u (to, tolen, &msghdr.msg_namelen); + if ( !msghdr.msg_name ) + { + err = WSAEFAULT; + goto err_free; + } + } + else + msghdr.msg_namelen = 0; + + msghdr.msg_iov = iovec; + msghdr.msg_iovlen = dwBufferCount; + msghdr.msg_control = NULL; + msghdr.msg_controllen = 0; + msghdr.msg_flags = 0; + + /* FIXME: Treat overlapped IO here */ + + if (_is_blocking(s)) + { + /* FIXME: exceptfds? */ + do_block(fd, 2); + } + + /* FIXME: can we support MSG_PARTIAL ? How does it relate to sendmsg()'s msg_flags ? */ + + if ((n = sendmsg (fd, &msghdr, dwFlags)) == -1) { - break; + err = wsaErrno(); + if ( err == WSAEWOULDBLOCK ) + _enable_event (s, FD_WRITE, 0, 0); + goto err_free; } - /* Indicate that we've sent something */ - *lpNumberOfBytesSent += lpBuffers[ dwCount ].len; - } + *lpNumberOfBytesSent = n; - return rc; + ws_sockaddr_free ( msghdr.msg_name, to ); + WS_FREE ( iovec ); + close ( fd ); + + return 0; + +err_free: + ws_sockaddr_free ( msghdr.msg_name, to ); + WS_FREE ( iovec ); + +err_close: + close ( fd ); + +error: + WARN (" -> ERROR %d\n", err); + SetLastError (err); + return SOCKET_ERROR; } /*********************************************************************** @@ -2035,46 +2077,13 @@ int WINAPI WS_sendto(SOCKET s, const char *buf, int len, int flags, const struct WS_sockaddr *to, int tolen) { - int fd = _get_sock_fd(s); - int res; - - TRACE("socket %04x, ptr %p, length %d, flags %d\n", s, buf, len, flags); - - res=SOCKET_ERROR; - if (fd != -1) - { - const struct sockaddr* uaddr; - int uaddrlen; + DWORD n; + WSABUF wsabuf = { len, (char*) buf }; - uaddr=ws_sockaddr_ws2u(to,tolen,&uaddrlen); - if (uaddr == NULL) - { - SetLastError(WSAEFAULT); - } - else - { - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: exceptfds */ - do_block(fd, 2); - } - res=sendto(fd, buf, len, flags, uaddr, uaddrlen); - if (res < 0 ) - { - SetLastError(wsaErrno()); - if( GetLastError() == WSAEWOULDBLOCK ) - _enable_event(s, FD_WRITE, 0, 0); - } - ws_sockaddr_free(uaddr,to); - } - close(fd); - } + if ( WSASendTo (s, &wsabuf, 1, &n, flags, to, tolen, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; else - { - SetLastError(WSAENOTSOCK); - } - return res; + return n; } /*********************************************************************** diff -ruNX diffignore TMP/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- TMP/wine/dlls/winsock/ws2_32.spec Thu Apr 4 10:58:53 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Thu Apr 4 11:01:03 2002 @@ -86,7 +86,7 @@ 71 forward WSAResetEvent KERNEL32.ResetEvent 72 stdcall WSASend(long ptr long ptr long ptr ptr) WSASend 73 stub WSASendDisconnect -74 stub WSASendTo +74 stdcall WSASendTo(long ptr long ptr long ptr long ptr ptr) WSASendTo 75 stub WSASetEvent 76 stub WSASetServiceA 77 stub WSASetServiceW

April 4, 2002

[PATCH] Move recv() functionality to WS2_32 code

by Martin Wilck

PATCH: Move recv() functionality to WS2_32 code For the recv() family of functions, WSARecvFrom() becomes the work horse. All other functions (WSARecv(), recv(), recvfrom(), ...) are only wrappers around WSARecvFrom(). To provide the scatter/gather functionality of WSARecvFrom(), the Unix system call used as backend is recvmsg() rather than recvfrom(). Patch against: Wine CVS 2002-04-04. Test status: Compiles, no warnings. Tested with 16 bit apps: FreeAgent (newsreader), Solstice mail, nslookup, teraterm (telnet) (16 bit apps now call WS2_32 code!) Modified files: dlls/winsock : socket.c, ws2_32.spec diff -ruNX diffignore MW/wine/dlls/winsock/socket.c TMP/wine/dlls/winsock/socket.c --- MW/wine/dlls/winsock/socket.c Thu Apr 4 09:37:38 2002 +++ TMP/wine/dlls/winsock/socket.c Thu Apr 4 10:58:53 2002 @@ -1797,34 +1797,13 @@ */ int WINAPI WS_recv(SOCKET s, char *buf, int len, int flags) { - int fd = _get_sock_fd(s); - - TRACE("socket %04x, buf %8x, len %d, flags %d\n", s, (unsigned)buf, len, flags); - - if (fd != -1) - { - INT length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds? */ - do_block(fd, 1); - } - if ((length = recv(fd, buf, len, flags)) >= 0) - { - TRACE(" -> %i bytes\n", length); + DWORD n, dwFlags = flags; + WSABUF wsabuf = { len, buf }; - close(fd); - _enable_event(s, FD_READ, 0, 0); - return length; - } - SetLastError(wsaErrno()); - close(fd); - } - else SetLastError(WSAENOTSOCK); - WARN(" -> ERROR\n"); - return SOCKET_ERROR; + if ( WSARecvFrom (s, &wsabuf, 1, &n, &dwFlags, NULL, NULL, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; + else + return n; } /*********************************************************************** @@ -1842,60 +1821,13 @@ int WINAPI WS_recvfrom(SOCKET s, char *buf, INT len, int flags, struct WS_sockaddr *from, int *fromlen) { - int fd = _get_sock_fd(s); - int res; + DWORD n, dwFlags = flags; + WSABUF wsabuf = { len, buf }; - TRACE("socket %04x, ptr %08x, len %d, flags %d\n", s, (unsigned)buf, len, flags); -#if DEBUG_SOCKADDR - if (from) - dump_sockaddr(from); + if ( WSARecvFrom (s, &wsabuf, 1, &n, &dwFlags, from, fromlen, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; else - DPRINTF("from = NULL\n"); -#endif - - res=SOCKET_ERROR; - if (fd != -1) - { - struct sockaddr* uaddr; - int uaddrlen; - int length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds */ - do_block(fd, 1); - } - - uaddr=ws_sockaddr_alloc(from,fromlen,&uaddrlen); - length=recvfrom(fd, buf, len, flags, uaddr, &uaddrlen); - if (length < 0) - { - SetLastError(wsaErrno()); - WARN(" -> ERROR\n"); - } - else if (ws_sockaddr_u2ws(uaddr,uaddrlen,from,fromlen) != 0) - { - /* The from buffer was too small, but we read the data - * anyway. Is that really bad? - */ - SetLastError(WSAEFAULT); - WARN(" -> WSAEFAULT\n"); - } - else - { - TRACE(" -> %i bytes\n", length); - _enable_event(s, FD_READ, 0, 0); - res=length; - } - close(fd); - } - else - { - SetLastError(WSAENOTSOCK); - WARN(" -> WSAENOTSOCK\n"); - } - return res; + return n; } /*********************************************************************** @@ -3302,34 +3234,129 @@ /*********************************************************************** + * WSARecv (WS2_32.67) + */ +int WINAPI WSARecv (SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, + LPDWORD NumberOfBytesReceived, LPDWORD lpFlags, + LPWSAOVERLAPPED lpOverlapped, + LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + return WSARecvFrom (s, lpBuffers, dwBufferCount, NumberOfBytesReceived, lpFlags, + NULL, NULL, lpOverlapped, lpCompletionRoutine); +} + +/*********************************************************************** * WSARecvFrom (WS2_32.69) */ INT WINAPI WSARecvFrom( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, struct WS_sockaddr *lpFrom, LPINT lpFromlen, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) + { - DWORD dwCount; - INT rc; + /* Uses recvmsg() in order to provide scatter-gather I/O */ + + struct iovec* iovec; + struct msghdr msghdr; + int fd, i, length, err = WSAENOTSOCK; + + TRACE("socket %04x, wsabuf %p, nbufs %ld, flags %ld, from %p, fromlen %ld, ovl %p, func %p\n", + s, lpBuffers, dwBufferCount, *lpFlags, lpFrom, + (lpFromlen ? *lpFromlen : -1L), + lpOverlapped, lpCompletionRoutine); + + fd = _get_sock_fd(s); - FIXME( "(%i,%p,%lu,%p,%p,%p,%p,%p,%p: stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, - lpFrom, lpFromlen, lpOverlapped, lpCompletionRoutine ); + if (fd == -1) + { + err = WSAENOTSOCK; + goto error; + } - for( dwCount = 0, rc = 0; dwCount < dwBufferCount; dwCount++ ) - { + /* FIXME: should this be HeapAlloc() or WS_ALLOC ? */ + iovec = WS_ALLOC ( dwBufferCount * sizeof (struct iovec) ); + if ( !iovec ) + { + err = WSAENOBUFS; + goto err_close; + } - if( ( rc = WS_recvfrom(s, lpBuffers[ dwCount ].buf, (INT)lpBuffers[ dwCount ].len, - (INT)*lpFlags, lpFrom, lpFromlen ) ) != 0 ) + for (i = 0; i < dwBufferCount; i++) { - break; + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; } - } + msghdr.msg_name = NULL; - return rc; -} + if ( lpFrom ) + { +#if DEBUG_SOCKADDR + dump_sockaddr (lpFrom); +#endif + + msghdr.msg_namelen = *lpFromlen; + msghdr.msg_name = ws_sockaddr_alloc (lpFrom, lpFromlen, &msghdr.msg_namelen); + } + else + msghdr.msg_namelen = 0; + + msghdr.msg_iov = iovec; + msghdr.msg_iovlen = dwBufferCount; + msghdr.msg_control = NULL; + msghdr.msg_controllen = 0; + msghdr.msg_flags = 0; + + /* FIXME: Treat overlapped IO here */ + + if (_is_blocking(s)) + { + /* block here */ + /* FIXME: OOB and exceptfds? */ + do_block(fd, 1); + } + + /* FIXME: can we support MSG_PARTIAL ? + How does it relate to recvmsg()'s msg_flags ? */ + + if ((length = recvmsg (fd, &msghdr, *lpFlags)) == -1) + { + err = wsaErrno(); + goto err_free; + } + + TRACE(" -> %i bytes\n", length); + + if ( lpFrom && ws_sockaddr_u2ws (msghdr.msg_name, msghdr.msg_namelen, lpFrom, lpFromlen) != 0 ) + { + /* The from buffer was too small, but we read the data + * anyway. Is that really bad? + */ + SetLastError ( WSAEFAULT ); + WARN ( " -> Address buffer too small\n" ); + } + + *lpNumberOfBytesRecvd = length; + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + close(fd); + _enable_event(s, FD_READ, 0, 0); + + return 0; + +err_free: + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + +err_close: + close (fd); + +error: + WARN(" -> ERROR %d\n", err); + SetLastError ( err ); + return SOCKET_ERROR; +} /*********************************************************************** * WSCInstallProvider (WS2_32.88) diff -ruNX diffignore MW/wine/dlls/winsock/ws2_32.spec TMP/wine/dlls/winsock/ws2_32.spec --- MW/wine/dlls/winsock/ws2_32.spec Thu Apr 4 09:37:38 2002 +++ TMP/wine/dlls/winsock/ws2_32.spec Thu Apr 4 10:58:53 2002 @@ -79,7 +79,7 @@ 64 stub WSANtohl 65 stub WSANtohs 66 stub WSAProviderConfigChange -67 stub WSARecv +67 stdcall WSARecv(long ptr long ptr ptr ptr ptr) WSARecv 68 stub WSARecvDisconnect 69 stdcall WSARecvFrom(long ptr long ptr ptr ptr ptr ptr ptr ) WSARecvFrom 70 stub WSARemoveServiceClass

April 4, 2002

Review - Winnt.h warning patch for mingw32

by Steven Edwards

This shuts up some compiler warnings on mingw but I don't know if my syntax is right. I know the rules about ifdef and ifndef but you guys said there was exceptions for the compilers so I figured I would check. Like I said I am still learning here so if this isnt right please flame away. Mingw32 currently lacks a good ./configure system as Msys wont see dlltool/wrap so I don't really have another option other then using my own makefiles for now. There is only about 4 or 5 other places I have found where mingw differs from normal GCC. Changelog: Fixes mingw32 warning about stdcall and fastcall being redefined. cvs diff winnt.h Index: winnt.h =================================================================== RCS file: /home/wine/wine/include/winnt.h,v retrieving revision 1.104 diff -u -r1.104 winnt.h --- winnt.h 2 Apr 2002 19:37:15 -0000 1.104 +++ winnt.h 4 Apr 2002 08:15:55 -0000 @@ -80,9 +80,11 @@ #ifndef __WINE__ #define pascal __stdcall #define _pascal __stdcall +#if ! defined(__WINE__) && !defined(__MINGW__) #define _stdcall __stdcall #define _fastcall __stdcall #define __fastcall __stdcall +#endif #define __export __stdcall #define cdecl __cdecl #define _cdecl __cdecl _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

April 4, 2002

Re: DeviceIoControl

by Laurent Pinchart

> > >in fact DeviceIOControl is used in two completly separate ways: >1/ control VxD >2/ control "device" handles on specific types > >the control on VxD is needed for Win 9x support. In that case the HIWORD >of the iocontrol code is always 0. So, in that case, a lookup is made in >the list of known VxD:s if wae can handle the request. > Ok. I read the "Calling DeviceIoControl on Windows 95/98/Me" MSDN page, and I now understand what it's about. >the control on "device" handles is done when the high word of the >control code is non 0. > >as of today (but it's a bit hacky) handles to "device" and VxD:s are >viewed (in the server) as very simple objects. They only provide a > >clientID (a DWORD). all the calls to DeviceIOControl start by getting > >this client ID. > >If the value has the bit 0x10000 set, it means it's a VxD. The low word >of the client id then identifies the standard ID of the VxD. > You're refering to both VxDs and WDM (.sys) drivers, right ? How does the server find the correct low word of the client ID ? The driver I want to implement has a device type of 0xef00 (value passed to IoCreateDevice). I added a field to the VxD table with id set to 0xef00. Does wine, when I call CreateFile( "\\\\.\\MyDevice", ... ), check that table and set the client ID low word to the proper value ? >If the 0x20000 bit is set, it's in fact a handle a device. Driver A: >through Z: are mapped to 0 to 25 values (in the low word) > >Otherwise, it's a handle to the old DOS named devices (with their old >IDs too) > I think we should handler those cases in a new device handler (which would just test if the device is a CDROM for now). >So, back to DeviceIoControl when the high word of the io control code is >0. We expect device handle in that case (but don't test the 0x20000 bit for >error reporting), and then try to check if the device (from it's driver >letter) is a CDROM, and if so apply the io control on it. Support of io > >control on other types of device (hard disks, storage...) isn't done at the moment. > You mean when the high word is not 0, right ? I'll add a check for the 0x10000 and 0x20000 bits, and will dispatch the call to either a VxD or a device handler. Is that ok ?Can I use the same VxD list as for (HIWORD(dwIoControlCode) == 0 ) ? Laurent Pinchart

April 4, 2002

freetype : wine doesn't compile(Implement GetTextExtentPointI)

by Sylvain Petreolle

The following patch breaks compilation because there is a previous definition : Log message: Huw D M Davies <hdavies(a)codeweavers.com> Implement GetTextExtentPointI and add support for ETO_GLYPH_INDEX. Patch: http://cvs.winehq.com/patch.py?id=1017871707710937189943255 Compile errors : gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_GDI32_ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:1852: conflicting types for `WineEngGetTextExtentPointI' ../../include/font.h:102: previous declaration of `WineEngGetTextExtentPointI' ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 4, 2002

Re: DeviceIoControl

by Eric Pouech

Laurent Pinchart a écrit : > > Hi everybody, > > I need to add support for a currently unsupported VxD, and I'm quite puzzled > by the way that DeviceIoControl currently processes the device control > requests. > > DeviceIoControl starts by checking the high word of dwIoControlCode, which is > the device type. If the device type is 0, it gets a client ID by sending a > get_file_info request to the server, and uses the client ID as the device > type. It then looks in the VxD table for a handler for the device type, and > calls it if it exists. No problem with that. > > If the high word of dwIoControlCode is not 0, it checks if the device is a > CDROM (by calling GetDriveTypeA). If so, it calls CDROM_DeviceIoControl, and > if not is just fails. in fact DeviceIOControl is used in two completly separate ways: 1/ control VxD 2/ control "device" handles on specific types the control on VxD is needed for Win 9x support. In that case the HIWORD of the iocontrol code is always 0. So, in that case, a lookup is made in the list of known VxD:s if wae can handle the request. the control on "device" handles is done when the high word of the control code is non 0. as of today (but it's a bit hacky) handles to "device" and VxD:s are viewed (in the server) as very simple objects. They only provide a clientID (a DWORD). all the calls to DeviceIOControl start by getting this client ID. If the value has the bit 0x10000 set, it means it's a VxD. The low word of the client id then identifies the standard ID of the VxD. If the 0x20000 bit is set, it's in fact a handle a device. Driver A: through Z: are mapped to 0 to 25 values (in the low word) Otherwise, it's a handle to the old DOS named devices (with their old IDs too) So, back to DeviceIoControl when the high word of the io control code is 0. We expect device handle in that case (but don't test the 0x20000 bit for error reporting), and then try to check if the device (from it's driver letter) is a CDROM, and if so apply the io control on it. Support of io control on other types of device (hard disks, storage...) isn't done at the moment. A+

April 4, 2002

Re: VirtualAlloc bug ?

by Eric Pouech

> I tried to use VirtualAlloc with MEM_COMMIT to map a page at address > 0x7ffe0000. The call to VirtualAlloc failed with ERROR_INVALID_ADDRESS. I > then tried to reserve the pages first, using VirtualAlloc with MEM_RESERVE, > and the call to VirtualAlloc/MEM_COMMIT worked fined after that. > > The MSDN state that "(MEM_COMMIT) If a memory page is not yet reserved, > setting this value causes the function to both reserve and commit the memory > page.". this has changed recently. my local information (2K, 95 and NT 3/4 help, and not XP as on line) doesn't state this most (old) MSDN code about VirtualAlloc use the form ptr = VirtualAlloc(<addr>, <size>, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE); and not the only MEM_COMMIT we should investigate a bit more this point for the VirtualAlloc implementation as of today, use the MEM_RESERVE|MEM_COMMIT form, it'll be just fine A+

April 4, 2002

Re: FreeBSD/Solaris and -lc

by Francois Gouget

Marcus Meissner wrote: [...] > It should not be linked on Linux. I found an application that will crash if I link it in on FreeBSD. So it does seem that it should not be linked in even on FreeBSD (or maybe the crash has to do with the order in which it is linked in). Confirmed... it is a link order problem for that one. > Hmm, what about something like: > > AC_CHECK_FUNC(getpid,,AC_CHECK_LIB(c,getpid)) > > or similar? Unfortunately this does not work. I get: checking for getpid... yes checking for sqrt in -lm... yes The problem is that it appears you don't need to specify it if you don't use -Bsymbolic but you need to link it in if you use it: This works: $ gcc -shared advapi32.spec.o advapi.o crypt.o eventlog.o registry.o security.o service.o -o advapi32.dll.so -L../../dlls -L../../library -lwine -lm $ echo $? 0 but this doesn't: $ gcc -shared -Wl,-Bsymbolic advapi32.spec.o advapi.o crypt.o eventlog.o registry.o security.o service.o -o advapi32.dll.so -L../../dlls -L../../library -lwine -lm advapi.o: In function `GetUserNameA': /mnt/home/fgouget/wine/wine.ref/freebsd/dlls/advapi32/../../../src/dlls/advapi32/advapi.c(.text+0x16): undefined reference to `getuid' /mnt/home/fgouget/wine/wine.ref/freebsd/dlls/advapi32/../../../src/dlls/advapi32/advapi.c(.text+0x1c): undefined reference to `getpwuid' /mnt/home/fgouget/wine/wine.ref/freebsd/dlls/advapi32/../../../src/dlls/advapi32/advapi.c(.text+0x3a): undefined reference to `strerror' ... $ echo $? 0 Hmm, $?==0 but it still really bothers me to have all these undefined reference messages. And if I add -lc everything is fine again: $ gcc -shared -Wl,-Bsymbolic advapi32.spec.o advapi.o crypt.o eventlog.o registry.o security.o service.o -o advapi32.dll.so -L../../dlls -L../../library -lwine -lm -lc $ echo $? 0 Also, I could not get ldd to work on advapi32.dll.so for any of the above files. $ ldd advapi32.dll.so advapi32.dll.so: ldd: advapi32.dll.so: Exec format error advapi32.dll.so: exit status 1 What's wrong??? -- François Gouget fgouget(a)codeweavers.com

April 4, 2002

Re: DirectX API information - where?

by Vincent Béron

Roland a écrit : > > At 10:47 PM 4/3/02 +0200, Andreas Mohr wrote: > >search.microsoft.com. > > > >That's where I get quite some information from. > > > >Apart from that, mostly web searches and my pretty good collection of > >books (it's starting to extend to 1 meter of expert windows books now :-) > > Ok, let me ask this question: > > where do you get the information about the *nix API, the X-Windows API, > OpenGL etc? > > Roland *nix: man 3 should have a lot of info. X-Window (without the "s"): www.xfree86.org. If you want something more portable, try starting at www.x.org. OpenGL: www.opengl.org There are also a ton of books on each of those subjects, although picking the good ones is difficult. Vincent

April 3, 2002

Re: DirectX API information - where?

by Roland

At 10:47 PM 4/3/02 +0200, Andreas Mohr wrote: >search.microsoft.com. > >That's where I get quite some information from. > >Apart from that, mostly web searches and my pretty good collection of >books (it's starting to extend to 1 meter of expert windows books now :-) Ok, let me ask this question: where do you get the information about the *nix API, the X-Windows API, OpenGL etc? Roland

April 3, 2002

DeviceIoControl

by Laurent Pinchart

Hi everybody, I need to add support for a currently unsupported VxD, and I'm quite puzzled by the way that DeviceIoControl currently processes the device control requests. DeviceIoControl starts by checking the high word of dwIoControlCode, which is the device type. If the device type is 0, it gets a client ID by sending a get_file_info request to the server, and uses the client ID as the device type. It then looks in the VxD table for a handler for the device type, and calls it if it exists. No problem with that. If the high word of dwIoControlCode is not 0, it checks if the device is a CDROM (by calling GetDriveTypeA). If so, it calls CDROM_DeviceIoControl, and if not is just fails. I was wondering why the same VxD table as for (HIWORD(dwIoControlCode) == 0) wasn't used when the device type in dwIoControlCode is not 0. It seems to be a mistake to me. I was thinking about implementing the following algorithm: - check HIWORD(dwIoControlCode) - if 0, deviceType = GetCliendID( Device ) - if ! 0, deviceType = HIWORD(dwIoControlCode) - look for a VxD handler in the VxD table using the deviceType. - call the handler if it exists, fails otherwise This leaves out the special case for CDROM_DeviceIoControl. Could anyone explain to me why that special check is needed, if it is ? Thanks in advance. Laurent Pinchart

April 3, 2002

Re: Startup fix for scanbin 6.0

by Dimitrie O. Paun

On April 3, 2002 03:58 pm, Stefan Leichter wrote: > + if (!str) { > + ERR("called without text\n"); ^^^ This is not an ERR (which signals an internal Wine error), maybe a WARN, but I would suggest instead just: + if (!str) return 0; -- Dimi.

April 3, 2002

VirtualAlloc bug ?

by Laurent Pinchart

Hi, I tried to use VirtualAlloc with MEM_COMMIT to map a page at address 0x7ffe0000. The call to VirtualAlloc failed with ERROR_INVALID_ADDRESS. I then tried to reserve the pages first, using VirtualAlloc with MEM_RESERVE, and the call to VirtualAlloc/MEM_COMMIT worked fined after that. The MSDN state that "(MEM_COMMIT) If a memory page is not yet reserved, setting this value causes the function to both reserve and commit the memory page.". Is that a wine bug ? I can try to fix it, but I'm scared to break something in VirtualAlloc, as I'm new to wine internals. Laurent Pinchart

April 3, 2002

Re: Read of memory location 0x7ffe0000 in windows NT

by Laurent Pinchart

> > After some investigation, it seems that reading the memory location > > 0x7ffe0000 should return KeTickCount.LowPart to the user process. Has > > anyone ever heard about that ? I was wondering if it was a native windows > > NT behaviour, or if it was done by a special kernel-space exception > > handler installed by the program. > > It's a native NT thing; a page of memory at that address is shared > between user and kernel space. The definition in the w2k ddk. I downloaded the w2k ddk, and SharedUserData seems to be located at 0xffdf0000 (line 5099 of ntddk.h). Did Microsoft move the page around between NT4 and NT5, or is there something I don't understand ? Laurent Pinchart

April 3, 2002

Re: Removed sorting of registry key values

by Paul Millar

On Wed, 3 Apr 2002, Andriy Palamarchuk wrote: [snip - Eric's info on why the registry has to be sorted] > The tests show that values are exported in the same > order in which they are created. This means the values > are stored not in any particular order. That doesn't necessarily follow ... The export function(s) could map the sorted registry back into its original order. At the cost of sizeof( void *) bytes per registry entry (perhaps less, I haven't looked too closely at the registry code), you could have the registry keys sorted (for fast access) and export back into the original order in O(n) Is it worth the memory for that level of compatibility? ---- Paul Millar

April 3, 2002

Uninstaller issues on windows

by Steven Edwards

Hola Andi, I've built the uninstaller under mingw32 but have been having problems getting it to work. It will crash shortly after startup. Is it being developed on win32 or is it wine only? If you don't mind supporting it on windows I will send you a full bug report. Thanks Steven _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

April 3, 2002

Re: DirectX API information - where?

by Andreas Mohr

On Wed, Apr 03, 2002 at 07:09:52PM +0200, Tels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Moin, > > I want to learn more about the directx and general windows APIs. Now > I looked at some books, but was very unsure as to buy what and where, if > ever. > > First, it seems that good books about these topics come from Microsoft > Press. Naturally I don't want to support them ;) > Second, it seems that you need for the examples and SDK Visual C++ - again > from MS. Eeek! > And of course, you have to run and use it under Windows *sigh* > I am also worried about the different EULAs, licence and all that other > stuff "tainting" me - even though I do believe that all of this stuff isn't > legal binding for me anyway. But you never know. > > So, my question: Where can I obtain *free* information about the API's, > their working etc. What do you use? Books you can advise? search.microsoft.com. That's where I get quite some information from. Apart from that, mostly web searches and my pretty good collection of books (it's starting to extend to 1 meter of expert windows books now :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 3, 2002

Re: dynamic .fon conversion

by Huw D M Davies

On Tue, Apr 02, 2002 at 11:38:53PM +0900, Dmitry Timoshkov wrote: > "Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > > > > Now, IIRC (Huw will correct me if I'm wrong), it was said that > > > FreeType also supports Postscript fonts and .fon fonts. So the way to go > > > would be to extend Wine's FreeType support to .fon fonts. > > > > Yes, that's the idea. At the moment we ignore any font that isn't > > sfnt format (that's anything that isn't TT or OpenType). The issues > > are that we need to implement something sensible for GetGlyphOutline > > and GetOutlineTextMetrics for bitmap or Type1 fonts. > > I would expect that for at least very first time that functions will > fail for bitmap fonts and return glyph data in GGO_BEZIER format for > Type1 fonts. Later we can add cubic <-> quadratic spline conversion > routines and some special handling for bitmap fonts. Most applications > don't use or provide advanced vector graphics at all. As a side effect > of adding support for bitmap fonts will be retired x11drv font support. > and a possibility for real WYSIWYG in printing. For bitmap fonts to be useful GetGlyphOutline will have to return the bitmaps for GGO_BITMAP (this probably isn't what Windows does, but I think we can live with the difference). Of course once we do it for .fon's then .pcf/.bdf come almost for free. Actually I expect the hard bit is getting the TEXTMETRICs right. Huw.

April 3, 2002

Re: Regression: Wine won't compile with latest cvs shlwapi

by Ulrich Weigand

Alexandre Julliard wrote: > That's most likely the usual gcc bug with local WINAPI function > pointers. Doh, I'd completely forgotten that one :-/ Thanks, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

April 3, 2002

apologies to all

by Lonnie Cumberland

Hello All, I am VERY VERY sorry for sending the entire list such a large attachment. I hope that you all will forgive me and it will not happen again. I have no excuse except to say that I was getting too excited about the implementation and did not look at the size of the files. Sorry again, Lonnie -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: Lonnie(a)OutStep.com : Lonnie_Cumberland(a)yahoo.com The Basis Express Virtual Office & Data Backup and Recovery Services URL: http://www.basis-express.com "The Virtual Office without boundaries!!!"

April 3, 2002

Re: warn:wave:OSS_OpenDevice Another thread ...

by Duane Clark

Eric wrote: > This patch would be the correct way of fixing the issue. Would you mind > trying it? This patch causes hangs for me. The audio and app ran for awhile, but then everything, including the app, suddenly froze up.

April 3, 2002

Re: Removed sorting of registry key values

by Tels

-----BEGIN PGP SIGNED MESSAGE----- Moin, On 03-Apr-02 Andriy Palamarchuk carved into stone: > A program can expect to retrieve values in the order > they were created. In particular, the problem can be > if the app creates names like Item1, ..., Item10. > After sorting Item10 will be after Item1, not after > Item9. But is this documented? Are there programs which will relly rely on this? And is this guarantied no to change, for instance in other windows versions? I would say: Don't fix things that are not broken.;) Cheers, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' authoritatively disintermediate prospective materials -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPKtOtncLPEOTuEwVAQEfwAf+Nj8XZoVB84RoFcTbdvQ6qKBMh23cQ5EO d7c17jkVbGENWvEHR5NjToYDd3evEfM8emOe86ywxw6MrHdJZ+3RlSukcfprV33k EZoi2dgIzz7u+I3q//iaGkGrkGoW962XO2DiFXF3C33Es5DbORl8PMPq96+PJsz0 yCTgrzapD47+VvJLXBDgUHsPpyyFIjLP1+7/WhAB/qOEUae1a1lNSAAsbmY/zpT9 jL01/6bH28BDOGSmDI1j02hy8A9VZG/ErcLuhVOmBWEuYVq5+85t3PILCNJr5idP 597pu8baDfFYxjdaMO5E9zPiRib8jMGfWS+M5HRWSEiUEy66eEMKZQ== =ueqX -----END PGP SIGNATURE-----

April 3, 2002

Re: Removed sorting of registry key values

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > I don't have any doubts that existing code is faster. > The point of the patch is compatibility with Windows > behaviour. Unless we find a real-life application that depends on that, there isn't much point in being compatible here. -- Alexandre Julliard julliard(a)winehq.com

April 3, 2002