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

Re: Recent patches introduced a regression error

by Paul Millar

On 1 Aug 2002, Alexandre Julliard wrote: > Note that the wininet tests try to connect to www.winehq.com, so the > failure could be caused by a network connectivity problem (of course > it may also be a bug in our code). Actually, the networking turned out to be the problem after all. Web proxies here at Glasgow Uni are a little complex (and IMO sub-optimal). The problem was with a machine Comp.Serv. forgot to reboot after a UPS died (killed by lightning). This lead to the situation where I could see www.winehq.com, but quisquiliae couldn't. The weird thing is that the calls to InternetConnectA() and HttpOpenRequestA() in dlls/wininet/tests/http.c succeeded despite the connection failing. Is this correct? The MSDN entries ([1] and [2]) suggest that they should fail if the connection cannot be made, but the code says otherwise ... Cheers, Paul. [1] http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/i… [2] http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/h… ---- Paul Millar

Aug. 4, 2002

Re: sys/asoundlib.h:1: This header is deprecated

by Marco Pietrobono

On Sun, 4 Aug 2002, Gerald Pfeifer wrote: > On a SuSE Linux 8.0 box[1] I'm getting the following #warning a few times > while building the current CVS version of Wine: > > In file included from alsa.h:23, > from audio.c:46: > /usr/include/sys/asoundlib.h:1: warning: #warning This header is > deprecated, use <alsa/asoundlib.h> instead. Hi Gerald, sys/asoundlib.h is the old 0.5 version header, and it seems that SuSE has added it just for backward compatibility. Can you try the attached patch? I had prepared it few days ago but I've forgot to submit it... > Gerald bye, /pietrobo -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ?

Aug. 4, 2002

sys/asoundlib.h:1: This header is deprecated

by Gerald Pfeifer

On a SuSE Linux 8.0 box[1] I'm getting the following #warning a few times while building the current CVS version of Wine: In file included from alsa.h:23, from audio.c:46: /usr/include/sys/asoundlib.h:1: warning: #warning This header is deprecated, use <alsa/asoundlib.h> instead. Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Aug. 4, 2002

PATCH: formatting fixes in files/smb.c

by Gerald Pfeifer

I am also Cc:ing this patch to wine-devel because I think it shows that there is an issue that deserves a bit of thought: Code formatting. We certainly should not get anal rentative on this, but something like int trn = 1234,i=0; from files/smb.c where even a single line is inconsistent really makes me wonder. Also I am not aware of any coding style that asks for blanks around the assignment but does not use a blank after the comma. The patch below fixes at least the worst problems, by consistently using a blank after a comma in variable declarations. Gerald ChangeLog: Fix formatting of variable declarations. Index: smb.c =================================================================== RCS file: /home/wine/wine/files/smb.c,v retrieving revision 1.8 diff -u -3 -p -r1.8 smb.c --- smb.c 19 Jul 2002 03:17:19 -0000 1.8 +++ smb.c 4 Aug 2002 17:35:54 -0000 @@ -123,7 +123,7 @@ struct NB_Buffer static int netbios_name(const char *p, unsigned char *buffer) { char ch; - int i,len=0; + int i, len=0; buffer[len++]=' '; for(i=0; i<=MAX_HOST_NAME; i++) @@ -146,7 +146,7 @@ static int netbios_name(const char *p, u static DWORD NB_NameReq(LPCSTR host, unsigned char *buffer, int len) { - int trn = 1234,i=0; + int trn = 1234, i=0; NBR_ADDWORD(&buffer[i],trn); i+=2; NBR_ADDWORD(&buffer[i],0x0110); i+=2; @@ -203,9 +203,9 @@ static BOOL UNC_SplitName(LPSTR unc, LPS static BOOL NB_Lookup(LPCSTR host, struct sockaddr_in *addr) { - int fd,on=1,r,len,i,fromsize; + int fd, on=1, r, len, i, fromsize; struct pollfd fds; - struct sockaddr_in sin,fromaddr; + struct sockaddr_in sin, fromaddr; unsigned char buffer[256]; fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); @@ -288,7 +288,7 @@ err: static BOOL NB_SessionReq(int fd, char *called, char *calling) { unsigned char buffer[0x100]; - int len = 0,r; + int len = 0, r; struct pollfd fds; TRACE("called %s, calling %s\n",called,calling); @@ -571,7 +571,7 @@ static BOOL SMB_NegotiateProtocol(int fd static BOOL SMB_SessionSetup(int fd, USHORT *userid) { unsigned char buf[0x100]; - int pcount,bcount; + int pcount, bcount; struct NB_Buffer rx, tx; memset(buf,0,sizeof buf); @@ -667,7 +667,7 @@ static BOOL SMB_TreeConnect(int fd, USHO { unsigned char buf[0x100]; int slen; - struct NB_Buffer rx,tx; + struct NB_Buffer rx, tx; TRACE("%s\n",share_name); @@ -731,7 +731,7 @@ static BOOL SMB_NtCreateOpen(int fd, USH DWORD attributes, HANDLE template, USHORT *file_id ) { unsigned char buffer[0x100]; - int len = 0,slen; + int len = 0, slen; TRACE("%s\n",filename); @@ -886,9 +886,9 @@ static BOOL SMB_Open(int fd, USHORT tree DWORD creation, DWORD attributes, USHORT *file_id ) { unsigned char buf[0x100]; - int slen,pcount,i; + int slen, pcount, i; USHORT mode = SMB_GetMode(access,sharing); - struct NB_Buffer rx,tx; + struct NB_Buffer rx, tx; TRACE("%s\n",filename); @@ -944,8 +944,8 @@ static BOOL SMB_Open(int fd, USHORT tree static BOOL SMB_Read(int fd, USHORT tree_id, USHORT user_id, USHORT dialect, USHORT file_id, DWORD offset, LPVOID out, USHORT count, LPUSHORT read) { - int buf_size,n,i; - struct NB_Buffer rx,tx; + int buf_size, n, i; + struct NB_Buffer rx, tx; TRACE("user %04x tree %04x file %04x count %04x offset %08lx\n", user_id, tree_id, file_id, count, offset); @@ -1285,7 +1285,7 @@ done: static int SMB_GetSocket(LPCSTR host) { - int fd=-1,r; + int fd=-1, r; struct sockaddr_in sin; struct hostent *he; @@ -1390,7 +1390,7 @@ HANDLE WINAPI SMB_CreateFileA( LPCSTR un { int fd; USHORT tree_id=0, user_id=0, dialect=0, file_id=0; - LPSTR name,host,share,file; + LPSTR name, host, share, file; HANDLE handle = INVALID_HANDLE_VALUE; name = HeapAlloc(GetProcessHeap(),0,lstrlenA(uncname)); @@ -1540,7 +1540,7 @@ BOOL WINAPI SMB_ReadFile(HANDLE hFile, L SMB_DIR* WINAPI SMB_FindFirst(LPCSTR name) { int fd = -1; - LPSTR host,share,file; + LPSTR host, share, file; USHORT tree_id=0, user_id=0, dialect=0; SMB_DIR *ret = NULL; LPSTR filename;

Aug. 4, 2002

Re: DDraw Clipper fix

by Lionel Ulmer

> I'm 99% sure I fixed this in my last patch submission to winehq a while > ago. Seems Alexandre applied it after 20020710, though. So I don't think > your patch applies on top of CVS. Damn your right... At least my patch shoud be right as we produced exactly the same code (I just diffed my source tree with the latest CVS and only the comments differ). This will teach me to work on out-dated trees :-) So Alexandre, please discard this patch... Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 3, 2002

Re: DDraw Clipper fix

by Ove Kaaven

On Sat, 3 Aug 2002, Lionel Ulmer wrote: > This should hopefully fix bug : > Bug 936 - Incorrect placement of DirectDraw output (offset outside the Windows 'window') > > Basically, the logic to compute the clipping window was wrong (or at least I > did not understand all the subtilities of the code :-) ). At least with this > fix, this particular application now runs fine. I'm 99% sure I fixed this in my last patch submission to winehq a while ago. Seems Alexandre applied it after 20020710, though. So I don't think your patch applies on top of CVS.

Aug. 3, 2002

Re: New CVS and Agent

by Oliver Sampson

I just built a new CVS version for myself and this problem seems to have gone away. BTW, brand spanking new version of Agent (1.92) runs well under the current wine. I'll be updating the appDB shortly. Oliver On Mon, 15 Jul 2002 17:22:05 +0200, Oliver Sampson <olsam(a)quickaudio.com> wrote: >Howdy, >I just built a new CVS version--the first one in a while. I got >caught by the -managed and the -winver options going away--a little >searching through the list archives, and the problems were solved! > >Anyhow, I generally run with two instances of Forte Agent v1.9 open. >Since I've built the new CVS, there's a change in behavior that I >thought I'd the devel community know about. When pressing the >shortcut buttons on the Agent instance that was first opened, nothing >happened. When pressing on the buttons in the second instance, they >worked normally. I closed the second instance, and the buttons in the >first instance now work normally. > >Perhaps the messages are being captured and sent to the wrong place? >(They're not being sent to the wrong instance of Agent.) Also there >was no obvious output messages in the console window. > >That's the only change in behavior I've found so far. It still runs >great. Thanks to the devel community! > >Oliver > >==================================================== >Oliver Sampson >olsam(a)quickaudio.com >http://www.oliversampson.com > ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

Aug. 3, 2002

Re: Bug in winetest's configure???

by DJ Lucas

Tony Lambregts wrote: > This issue seems to be delt with in bug 787 and there is even a patch > for it. > > http://bugs.winehq.com/show_bug.cgi?id=787 > > It seems this patch is not in CVS and I do not recall it being > submitted to wine patches either. Any coment? > > This patch is from Mike Castle dalgoda(a)ix.netcom.com > > Index: winetest.c > <snip> Kewl, Tony, thanks for the patch. I've passed it on to the list at LFS.

Aug. 3, 2002

Re: Bug in winetest's configure???

by Tony Lambregts

DJ Lucas wrote: >I dont' know if this has been brought up before or not, haven't searched >the archives or anything, but this seems to be dependant on how perl was >installed. > >For some reason, when perl, 5.6.1 or 5.8.0 is configured with >./configure.gnu, when you go to build wine, in the winetest Makefile, >the ccflags variable (leftover from perl install) is included in >LDFLAGS. Obviously this is in error, but attempting to figure out if >this should be brought to Wine or Perl Developers. :-$ See the >following URLs for archives of the LFS mailing lists where this has been >previously discussed. The second seems to be more relevant. > >http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/07/0547.h >tml > >http://archive.linuxfromscratch.org/mail-archives/blfs-support/2002/08/0 >024.html > >Thanks in advance > >DJ Lucas > >PS, if this has been previously identified, please CC me in the first >reply, no need to flood the mailing list. ;-) > > > > > This issue seems to be delt with in bug 787 and there is even a patch for it. http://bugs.winehq.com/show_bug.cgi?id=787 It seems this patch is not in CVS and I do not recall it being submitted to wine patches either. Any coment? This patch is from Mike Castle dalgoda(a)ix.netcom.com Index: winetest.c =================================================================== RCS file: /home/wine/wine/programs/winetest/winetest.c,v retrieving revision 1.5 diff -u -r1.5 winetest.c --- winetest.c 10 Mar 2002 00:21:20 -0000 1.5 +++ winetest.c 1 Aug 2002 20:38:29 -0000 @@ -152,7 +152,7 @@ /* perl extension initialisation */ -static void xs_init(void) +static void xs_init(pTHX) { extern void boot_wine(CV *cv); newXS("wine::bootstrap", boot_wine,__FILE__);

Aug. 2, 2002

Re: rpcrt / epmapper / scm

by Ove Kaaven

On Fri, 2 Aug 2002 juergen.schmied(a)debitel.net wrote: > Hi! > > Some time ago I did send the rpcrt patches from ove ported to the cvs. > It didn't got included. Are there any special reasons? > > The epmapper was implemented in the wineserver. Should it be a standalone server? Alexandre has expressed that he prefers that, yeah. I guess it makes some sense, since I'm not sure how you'd put related stuff like the Running Object Table into the wineserver anyway. > 1) If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call. In real windows, endpoint lookups are cached in the client, and they aren't done that often anyway, so this won't be a large problem. > 2) What IPC should we use locally? We could implement LPC like reactos. Either that or stick with named pipes like now... > 3) We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this? I've considered it for a while, and the best idea I have so far is to let the client (rpc_epmap.c) try to connect to the epmapper (LPC or named pipe), and if it isn't there, launch it with CreateProcess and try to connect again. Keep the connection to it open until the app exits (or unloads rpcrt4). Then the epmapper process (rpcss.exe, wasn't it?) can simply exit cleanly when the last connection to it closes, similar to the way wineserver itself unloads itself. But I'm not likely to work on the server part for a while. Whenever I do get around to resuming working on DCOM stuff, I'm more likely to work on the IDL compiler and the bytecode marshalling.

Aug. 2, 2002