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

audio.c regression on Nov. 10th
by Ori Pessach Nov. 19, 2001

Nov. 19, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Despite my previous report on this, something did break in audio.c between November 9th and November 10th. I checked out a version from 11/09/2001, and it works. I updated just audio.c with -D 11/10/2001, and Humongous Entertainment games don't recognize the sound card anymore. There have been substantial changes to audio.c during those 24 hours - enough to confuse diff, as a matter of fact. I'll look into it, but I wanted to report this first. The reason I thought earlier that the problem went away was that I had a sticky date on audio.c that I wasn't aware of. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE7+VXUzA/uWWyw6uQRAmkHAJ94A+IW82jXdhhLl6ODWaUs7I+SwACg16oT FIIymJ5xAP6eNc+5GlbQ3SU= =zHkd -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard Nov. 19, 2001

Nov. 19, 2001

Francois Gouget <fgouget(a)free.fr> writes: > I guess that one day Alexandre is going to argue that Linux should > stop polluting the namespace with 'struct user'... Well, struct user is the only reason for including sys/user.h, so I guess it can be considered acceptable; but anything else defined in there (like struct user_regs_struct on Linux) is namespace pollution too IMO. And if there comes a day when the server is managing users, the corresponding struct will definitely be named struct user, not struct wine_unique_prefix_0918274_user or whatever (and note that we don't really need user.h even on Linux, we could just as well hardcode the offset). -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard Nov. 19, 2001

Nov. 19, 2001

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > FreeBSD isn't polluting the namespace. <sys/user.h> is a > a non-standard header file. It's still made available to applications, and there is really no reason for exporting internal kernel names this way. At least it could be renamed or put inside #ifdef _KERNEL. The alternative is of course to avoid sys/user.h, or play with #defines on the Wine side; but prefixing our structures with wine_ is not a solution. -- Alexandre Julliard julliard(a)winehq.com

4 4

Re: Fix to audio.c 1.46 loop problem + choppy sound
by Michael Stefaniuc Nov. 19, 2001

Nov. 19, 2001

On Fri, Nov 16, 2001 at 07:59:20PM -0800, Simon Britnell wrote: > This patch should fix a loop playing failure reported > by Eric and a problem with choppy sound I experienced > playing total annihilation Hmm ... this patch horrible breaks the sound in Quicktime. The sound is now (audio.c 1.47) practicaly nonexistand: every 5-7 seconds you hear something for about 1/2 seconds. Before that (audio.c 1.45,1.46) the sound was choppy and played at 4/5 of the normal speed whereas with audio.c 1.44 the sound plays perfect. I'm using Quicktime 5.02 standalone in the german version. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard Nov. 19, 2001

Nov. 19, 2001

Francois Gouget <fgouget(a)free.fr> writes: > Renaming struct thread it the right thing to do though. Why > doesn't changing thread to wine_thread in request.h work? No, the right thing is to fix the FreeBSD headers to stop polluting the namespace. struct thread is a perfectly valid identifier for an application to use (and we are certainly not the only application using it). -- Alexandre Julliard julliard(a)winehq.com

2 1

Kdevelop and Wine
by Chuck Fischer Nov. 19, 2001

Nov. 19, 2001

Hello, I'm new to Linux, Kdevelop and Wine. I've been given the task of getting a Windows application to run on *nix. After some surfing I found KDevelop and Wine. I would like to use KDevelop to build my Windows app with WineLib. Can this be done? Has it been done? What do I need to do to get it to work? Also, are there any plans or thoughts about integrating WineLib with KDevelop? TIA, Chuck

2 1

Re: Build failure due to winsock.h changes, specifically htonl
by Gerald Pfeifer Nov. 19, 2001

Nov. 19, 2001

On Thu, 15 Nov 2001, Francois Gouget wrote: > Yes. This one is actually simple to solve: do not include > 'winsock2.h'. AFAICT including 'winsock2.h' is not necessary since 1.66 > (2000/08/31) when get_socket_event and FD_MAX_EVENTS where removed. > I am working on the other compilation problems... I just performed a cvs update and now was able to again build Wine on FreeBSD 4.4 due to your latest changes. Thanks a lot! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

readdir broken when called from wine
by Lionel Elie Mamane Nov. 19, 2001

Nov. 19, 2001

Hi, After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled from tarballs), suddenly it didn't find my "C:\Windows" any more. Worked before, same 'puter, config files, etc (TM). Tried with CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we ruled out the obvious (yes, the directory exists, here is my config file, no, I don't confuse root and non-root, ...), and got down to add traces and dug in the code. So, for some reason, the readdir calls from files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')! So I checked if readdir worked generally on my system, it does, this program does the expected thing: int main(void) {//Tst code DIR *mydir; struct dirent *entr; mydir = opendir("/"); while ((entr = readdir(mydir))) { TRACE("Dir_entry: %s\n", entr->d_name); } closedir(mydir); } I even went the extra mile and compiled it with exactly the same options (minus the various -I's) as dos_fc.c gets in wine, it works. Then, I added that code snippet (without the "int main(void)", obviously) to wine's main(). Worked. So I went down the stack of called functions, putting that same snippet in each function to see when it breaks: It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That function calls files/directory.c:DIR_Init(), and there, it doesn't work (ie name is always empty string) in DIR_Init(). After DIR_Init() returns, it still works in MAIN_MainInit(). I tried to find a difference between these files, but they get compiled with the same compile options, combined by "ld -r" along with other .o's in files/files.o, resp. loader/loader.o, and the two latter go in libntdll.so. What could be the difference that makes readdir "break"? I've put the test code snippet just before the call to DIR_Init in MAIN_MainInit, and just after variable declaration in DIR_Init, so it's not a function that DIR_Init calls that "breaks havoc". Well... We're lost there. No idea. Anyone of you? Anyway, here's some info on my system, just giving random info, I don't really know which one will be useful: Pentium III 500 / 440BX motherboard SuSE 6.4 distrib "base" with several self-compiled "add-ons", "upgrades", and some newer SuSE RPM's installed (from 7.0, 7.1 or 7.2). Along the latter (newer RPM than SuSE 6.4), the glibc... glibc-2.2-9 Linux 2.2.20 (Was using .19 when problem started) Soundblaster AWE32 3Com NIC (3C905B) Adaptec SCSI controller (AHA-3950U2) gcc 2.95.2 GNU ld 2.9.5 binutils-2.9.5.0.24-30 Err... What more??? Any additional info useful? Just ask. (except r00t password, "of course" ;-> ) Thank you for your time, -- Lionel Elie Mamane RFC 1991 (PGP 2.x) 2048 bits Key Fingerprint (KeyID: 20C897E9): 85CF 986F 263E 8CD0 80FD 4B8C F5F9 C17D OpenPGP DH/DSS 4096/1024 Key Fingerprint (KeyID: 3E7B4B73): 9DAD 3131 3ADA F50B D096 002A B1C4 7317 3E7B 4B73

3 3

Query on ActiveX components support from Wine.
by Ganesh.S Nov. 19, 2001

Nov. 19, 2001

Hi, Is it possible to run an application that uses MSGrid ActiveX component and other database related components. My application was developed in VB6.0 which uses Microsoft Access in the backend. When I run the application the datas are not comming. Also few of the screens are not coming up saying that can't load the ActiveX component and the application gets killed. Is there any patch or solution for this. Can you suggest me the solution for this. thanks in advance, with regards, Ganesh.S Success is the progressive Realisation of a Worthy Goal. HCL Peripherals

1 0

Re: misc. code fixes
by Alexandre Julliard Nov. 18, 2001

Nov. 18, 2001

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > - make listbox.c use reasonable bounds checking That's a completely gratuitous change, it makes absolutely no difference to the code. If you like your way better you are free to use it on your own code; but please don't go around "fixing" other people's code like this. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Patches for FreeBSD 5.x compilation
by Francois Gouget Nov. 18, 2001

Nov. 18, 2001

On Sun, 18 Nov 2001, Steve Kargl wrote: > The following patches are required to compile > the latest wine sources on FreeBSD 5.x. Note, I have a patch that I think should fix this compilation problem. I sent it on the 15th but it got loast without a trace so I resent it today (search for 'Solaris and FreeBSD compilation fixes (fwd)'). > Index: wine/dlls/wsock32/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/wsock32/socket.c,v > retrieving revision 1.16 > diff -u -r1.16 socket.c > --- wine/dlls/wsock32/socket.c 2001/11/14 21:26:23 1.16 > +++ wine/dlls/wsock32/socket.c 2001/11/18 18:42:14 > @@ -42,6 +42,7 @@ > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > +#include <sys/socket.h> > #ifdef HAVE_SYS_SOCKIO_H > # include <sys/sockio.h> > #endif This should have a #ifdef HAVE_SYS_SOCKET_H around it. See my patch. > Index: wine/include/winsock.h > =================================================================== > RCS file: /home/wine/wine/include/winsock.h,v > retrieving revision 1.37 > diff -u -r1.37 winsock.h > --- wine/include/winsock.h 2001/11/14 21:26:24 1.37 > +++ wine/include/winsock.h 2001/11/18 18:42:17 > @@ -894,14 +894,10 @@ > struct WS(servent)* WINAPI WS(getservbyport)(int,const char*); > int WINAPI WS(getsockname)(SOCKET,struct WS(sockaddr)*,int*); > int WINAPI WS(getsockopt)(SOCKET,int,int,char*,int*); > -u_long WINAPI WS(htonl)(u_long); > -u_short WINAPI WS(htons)(u_short); > unsigned long WINAPI WS(inet_addr)(const char*); > char* WINAPI WS(inet_ntoa)(struct WS(in_addr)); > int WINAPI WS(ioctlsocket)(SOCKET,long,u_long*); > int WINAPI WS(listen)(SOCKET,int); > -u_long WINAPI WS(ntohl)(u_long); > -u_short WINAPI WS(ntohs)(u_short); > int WINAPI WS(recv)(SOCKET,char*,int,int); > int WINAPI WS(recvfrom)(SOCKET,char*,int,int,struct WS(sockaddr)*,int*); > int WINAPI WS(send)(SOCKET,const char*,int,int); This will break Winelib. I guess this was to fix the compilation errors in 'server/trace.c'. In that case I think a better solution is to not include 'winsock2.h' at all in server/trace.c since it appears to no longer be needed. > Index: wine/server/context_i386.c > =================================================================== > RCS file: /home/wine/wine/server/context_i386.c,v > retrieving revision 1.18 > diff -u -r1.18 context_i386.c > --- wine/server/context_i386.c 2001/07/11 17:30:59 1.18 > +++ wine/server/context_i386.c 2001/11/18 18:42:55 > @@ -20,9 +20,6 @@ > #ifdef HAVE_SYS_PARAM_H > # include <sys/param.h> > #endif > -#ifdef HAVE_SYS_USER_H > -# include <sys/user.h> > -#endif What is the problem with 'sys/user.h' ? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

2 2

Re: Excessive redraw in Lotus Notes with Wine 20011108
by Glenn Schrader Nov. 18, 2001

Nov. 18, 2001

Toby Haynes wrote: >I've just compiled up Wine 20011108 and given it a little testing. QuickTime >installer works fine and QuickTime player comes up, although it wants to be >fullscreen most of the time (something to do with strange mouse click handling >I think). SameTime installer runs (at least for version 1.5) although I can't >get the actual program to start (Unhandled exception). > >Lotus Notes 5.0.4 also appears to run fine with this build (I couldn't reply to >messages with the October WINE release) but there is one headache-inducing >problem. When composing a message or editing a document, the screen redraws for >every letter. It does this pretty quickly but the effect is that the screen >flashes as I type. It's bad enough that I type with my eyes closed to avoid >looking at the screen and edit any mistakes I make at the end. It's not a >problem at other times such as reading messages or browsing databases - only >editing seems to suffer from this. > >Setting double-buffer visuals doesn't seem to help. Managed or desktop >configurations both suffer from this. > >Does anyone have any clues as to settings to tweak to minimise/stop this >happening? I'd rather not go back to 20010326 (my stable backup build) but I >will if I can't solve this problem. > >Thanks, >Toby Haynes > I have been having a similar problem with a different app. Try the attached patch and see if it helps. --- Glenn Schrader Index: painting.c =================================================================== RCS file: /home/wine/wine/windows/painting.c,v retrieving revision 1.61 diff -u -r1.61 painting.c --- painting.c 2001/10/16 21:58:59 1.61 +++ painting.c 2001/11/18 22:48:09 @@ -345,23 +345,12 @@ TRACE("hrgnUpdate = %04x, \n", hrgnUpdate); - if (GetClassLongA( hwnd, GCL_STYLE ) & CS_PARENTDC) - { - /* Don't clip the output to the update region for CS_PARENTDC window */ - if( hrgnUpdate ) - DeleteObject(hrgnUpdate); - lps->hdc = GetDCEx( hwnd, 0, DCX_WINDOWPAINT | DCX_USESTYLE | - (bIcon ? DCX_WINDOW : 0) ); - } - else - { - if( hrgnUpdate ) /* convert to client coordinates */ - OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, - wndPtr->rectWindow.top - wndPtr->rectClient.top ); - lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | - DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); - /* ReleaseDC() in EndPaint() will delete the region */ - } + if( hrgnUpdate ) /* convert to client coordinates */ + OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, + wndPtr->rectWindow.top - wndPtr->rectClient.top ); + lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | + DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); + /* ReleaseDC() in EndPaint() will delete the region */ TRACE("hdc = %04x\n", lps->hdc);

1 0

Re: readdir broken when called from wine
by Gerard Patel Nov. 18, 2001

Nov. 18, 2001

At 08:17 PM 18/11/2001 +0100, you wrote: >After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled >from tarballs), suddenly it didn't find my "C:\Windows" any >more. Worked before, same 'puter, config files, etc (TM). Tried with >CVS version. <snip> >What could be the difference that makes readdir "break"? Take a look at the 'cvs-regression' file in the documentation directory. Gerard

2 1

Re: cleanup patch
by Marcus Meissner Nov. 18, 2001

Nov. 18, 2001

> diff -u -r1.5 dib.c > --- dlls/ddraw/dsurface/dib.c 10 Sep 2001 23:12:16 -0000 1.5 > +++ dlls/ddraw/dsurface/dib.c 18 Nov 2001 13:47:22 -0000 > @@ -386,7 +386,11 @@ > > dbuf = (BYTE*)ddesc.lpSurface+(xdst.top*ddesc.u1.lPitch)+(xdst.left*bpp); > > - dwFlags &= ~(DDBLT_WAIT|DDBLT_ASYNC);/* FIXME: can't handle right now */ > + if (dwFlags & (DDBLT_WAIT|DDBLT_ASYNC)) > + { > + FIXME("dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.\n"); > + dwFlags &= ~(DDBLT_WAIT|DDBLT_ASYNC); > + } I do not want to see this FIXME 50 times or more per second. Ciao, Marcus

1 0

I've been too damn bored today...
by Andreas Mohr Nov. 17, 2001

Nov. 17, 2001

Hi all, that was the result: http://home.nexgo.de/andi.mohr/download/nicegraph.png -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: SystemParametersInfo: Screen Save actions
by Alexandre Julliard Nov. 16, 2001

Nov. 16, 2001

Francois Gouget <fgouget(a)free.fr> writes: > In fact, I disagree with Alexandre when he says: > > > If users want to reconfigure X behavior, they have to use the X > > configuration programs. > > I think Wine is about more than just running Windows applications on > Linux. It's about integrating Windows and Linux applications and thus > they should be able to manipulate these kind of settings. Otherwise Wine > would only support the 'desktop mode' or it would not exist at all and > everyone would be happy with running Windows in a sand-box ala VMWare. I also said there could be exceptions... I agree temporarily disabling the screen saver can be useful, so we probably want to allow at least that. I'm not sure we want to allow messing with the timeout though. -- Alexandre Julliard julliard(a)winehq.com

5 7

AutoCad2000 Error ...
by Ancient Computers Nov. 16, 2001

Nov. 16, 2001

Wine release 20011108 Standard config. starting with wine acad.exe in a windows install ... fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--12-120-75-75-p-64-tis620.2533-1' has unknown character encoding '1' in known registry 'tis620 .2533' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--13-130-75-75-p-71-tcvn-5712' has unknown character encoding '5712' in known registry 'tcvn' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-46-iso8859-9e' has unknown character encoding '9e' in known registry 'iso8859' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-49-tatar-cyr' has unknown registry 'tatar' and character encoding 'cyr' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-50-koi8-c' has unknown character encoding 'c' in known registry 'koi8' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-51-koi8-k' has unknown character encoding 'k' in known registry 'koi8' err:font:XFONT_BuildMetrics failed to load -macromedia-king richard-medium-r-normal--100-*-100-100-p-0-ascii-0 err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

1 0

Re: SystemParametersInfo: Screen Save actions
by Andreas Mohr Nov. 16, 2001

Nov. 16, 2001

On Wed, Nov 14, 2001 at 07:22:39AM -0800, Andriy Palamarchuk wrote: > Change log: > > SystemParametersInfo. Implemented processing for > actions SPI_GET/SETSCREENSAVETIMEOUT, > SPI_GET/SETSCREENSAVEACTIVE, > SPI_GET/SETSCREENSAVERRUNNING. Removed integration > with X Window screen saving. Hmm, why did you remove X11 screen saving completely ?? Probably because it was horribly broken, right ? (SPI_SETSCREENSAVEACTIVE *activated* screen saver instead of *enabling* it - doh !) Why don't you fix this strange code instead of removing it ? I guess I should do it... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

3 3

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill Nov. 16, 2001

Nov. 16, 2001

Found the problem, not the fix. message.c function PeekMessageW. It used to call FindWinToRepaint but that has been moved into the server. But FindWinToRepaint was able to return a window handle other than the original message window handle. 1. So what about the IsIconic line following it? Now it's testing the wrong handle. 2. (The real problem)PeekMessageW returns the message. Now the handle it returns is the unadulterated one, not the potential child. So what do we do about that? Get the server to return it? Bill > -----Original Message----- > From: Alexandre Julliard [mailto:julliard(a)winehq.com] > Sent: Wednesday, November 14, 2001 1:29 PM > To: wine-cvs(a)winehq.com > Subject: wine/ dlls/user/message.c include/win.h server ... > > > ChangeSet ID: 1005773317852080273907632 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/11/14 16:28:37 > > Modified files: > dlls/user : message.c > include : win.h > server : queue.c user.h window.c > windows : win.c > > Log message: > Moved WIN_FindWinToRepaint functionality to the server. > > Patch: http://cvs.winehq.com/patch.py?id=1005773317852080273907632 > > Revision Changes Path > 1.12 +0 -6 wine/dlls/user/message.c > 1.64 +0 -1 wine/include/win.h > 1.19 +3 -3 wine/server/queue.c > 1.5 +1 -0 wine/server/user.h > 1.10 +46 -1 wine/server/window.c > 1.169 +0 -104 wine/windows/win.c > > >

2 1

Re: [RFC]: Overlapped I/O implementation
by Alexandre Julliard Nov. 15, 2001

Nov. 15, 2001

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > B) The check_async() function in synchro.c operates on file descriptors > rather than async requests. Once an overlapped I/O request is > issued by the application, it is queued either in the readers or > writers list of the async object (which is obtained from the server). > If both the readers and writers lists were NULL beforehand, the fd > is inserted into the list for check_async to work on. But the list has to be stored in the server, otherwise you cannot guarantee the request order across processes. I think you need to put just about everything except the actual read/write call in the server. > check_async() activates the first element(s) of both the readers and > writers lists (where activate means that the actual read/write call > is triggered). For FIFOS, only one element would be activated; for > regular files several requests up to a given limit (e.g. 4). > > If the file is on a device where normal I/O would be blocking, a > new thread is created for each activated request to satisfy it. I don't think we want to use threads at all. This has major overhead and compatibility problems. IMO normal file I/O should always be done synchronously; it may impact performance a bit when reading from floppy, but this is better than slowing down all async operations with the need to manage threads and locks. -- Alexandre Julliard julliard(a)winehq.com

3 5

MIDL and COM
by Ove Kaaven Nov. 15, 2001

Nov. 15, 2001

OK, since list traffic is low at the moment (which might be because /var on WineHQ got full again, and as usual the secondary MX provided by Corel seems to have the functionality of a black hole, so I've now moved the apache logs off /var), I thought I'd try to liven it up a bit with a couple of things I'm wondering about... Problem 1: MIDL-generated code. midl.exe is Microsoft's IDL compiler, it reads .idl files which describe RPC and COM interface, from which it generates .c files, .h files, and typelibs. (It is possible to find copies of midl.exe floating on the net, as some people have put together "COM kits" for Borland C++ that contains midl.exe and some standard .idl files and put them on the web) But can the machine-generated sources that MIDL outputs be put into the official Wine source? And how about source IDL files? Can we put into Wine IDL extracted from real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from MIDL-generated Windows SDK .h files, like objidl.h, with a script? Problem 2: RPCSS rpcss.exe is the place that keeps track of which process owns which RPC endpoints, exported COM objects, and object activation tables. The IRunningObjectTable interface, for example, is managed by rpcss.exe, and keeps track of certain kinds of COM objects on the computer, so that other processes can connect to running COM objects. We probably don't want Wine to have to run a separate process for this? If not, can we put this kind of COM stuff into the wineserver?

1 0

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill Nov. 15, 2001

Nov. 15, 2001

This patch causes the listview class to enter some sort of infinite repaint loop on our application. Is someone else already tackling it? Bill > -----Original Message----- > From: Alexandre Julliard [mailto:julliard(a)winehq.com] > Sent: Wednesday, November 14, 2001 1:29 PM > To: wine-cvs(a)winehq.com > Subject: wine/ dlls/user/message.c include/win.h server ... > > > ChangeSet ID: 1005773317852080273907632 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/11/14 16:28:37 > > Modified files: > dlls/user : message.c > include : win.h > server : queue.c user.h window.c > windows : win.c > > Log message: > Moved WIN_FindWinToRepaint functionality to the server. > > Patch: http://cvs.winehq.com/patch.py?id=1005773317852080273907632 > > Revision Changes Path > 1.12 +0 -6 wine/dlls/user/message.c > 1.64 +0 -1 wine/include/win.h > 1.19 +3 -3 wine/server/queue.c > 1.5 +1 -0 wine/server/user.h > 1.10 +46 -1 wine/server/window.c > 1.169 +0 -104 wine/windows/win.c > > >

1 0

Re: Need to increase REQUEST_MAX_VAR_SIZE
by Andreas Mohr Nov. 15, 2001

Nov. 15, 2001

On Thu, Nov 15, 2001 at 01:54:29PM +0100, Uwe Bonnes wrote: > Hallo, > > some aplication tries to set a reather longish windows text with over 512 > characters > > 0970c7a0:Call kernel32.lstrlenA(41b6bd8c "License for required features not available\n\n\nSorry, no Synplicity license is av"...) ret=006f06c2 > 0970c7a0:Ret kernel32.lstrlenA() retval=0000026b > ... > 0970c7a0:Call user32.SetWindowTextA(0001002e,41b6bb0c "License for required features not available\n\n\nSorry, no Synplicity license is av"...) ret=00 > 6fce93 > ... > wine: client.c:136: wine_server_alloc_req: Assertion `size <= 1024' failed. > > For the serrver call this is translated into Unicode and so 1024 byte is not > enough for the string. Argh, why is stupid license speak always so darned long ??? This is the second time that I've seen problems caused by license stuff. (I had a similar problem with dbgstring_a() output). We should really tell lawyers to behave themselves a lot better :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: 3D Studio 4 notes
by Gerard Patel Nov. 15, 2001

Nov. 15, 2001

At 04:58 AM 15/11/2001 +0100, you wrote: <snip> >091d38d8:Call ws2_32.getsockopt(ffffffff,0000ffff,00007008,00f1ca84,45e96d54) ret=00de3f47 >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >trace:winsock:WSOCK32_getsockopt socket: ffffffff, opt 0xffff, ptr f1ca84, len 4 >091d38d8:Ret ws2_32.getsockopt() retval=ffffffff ret=00de3f47 Yes, this is not the old bug - the same call would fail under Windows. Even if the option is not supported by Wine, using a socket of -1 is probably incorrect. So either the app has a bug that occurs also under Windows, or the invalid value comes from a previous problem (maybe because of an invalid installation) Also, this app is using msvcrt. Make sure that you use 'native' msvcrt if you have it (-debugmsg +loaddll). Maybe the problem has nothing to do with sockets. Gerard

1 0

Re: wine_anon_mmap MAP_FIXED patch
by Ove Kaaven Nov. 14, 2001

Nov. 14, 2001

On Thu, 15 Nov 2001, Bang Jun-Young wrote: > on MAP_FIXED flag. On Linux, it shouldn't do any harm. Yes, it would do harm. See http://www.winehq.com/hypermail/wine-devel/2000/11/0167.html

1 0

Re: 3D Studio 4 notes
by Gerard Patel Nov. 14, 2001

Nov. 14, 2001

At 04:43 PM 14/11/2001 +0100, you wrote: <snip> >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >MSG .0 fatal: getsockopt(SO_OPENTYPE) failed - Invalid handle This error message has already been posted several times on the news group. It was linked to the previous Wine version (october) Do you use last version (1108) or current Cvs ? Gerard

2 2

Re: patch.py?id=1005690229526658676564693 (fwd)
by Alexandre Julliard Nov. 14, 2001

Nov. 14, 2001

lawson_whitney(a)juno.com writes: > Hmmm, I put the patch back, and took desktop= out of the config. The > problem only happens in desktop mode. That is not so bad, I don't have > to spend 45 minutes reverting the patch just to get mail. Still, I > guess I should try to debug it. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine_anon_mmap MAP_FIXED patch
by Ulrich Weigand Nov. 14, 2001

Nov. 14, 2001

Bang Jun-Young <junyoung(a)mogua.com> wrote: > Why this is necessary is because most Win32 binaries expect itself > to be loaded at fixed address (0x400000). GCC and M$ compilers seem > to strip relocation info on .exe by default, so we need to ensure > that on some OS, i.e. NetBSD. Refer to NetBSD/FreeBSD mmap(2) manpage > on MAP_FIXED flag. On Linux, it shouldn't do any harm. On Linux and Solaris, MAP_FIXED has a different meaning: it will *replace* any pre-existing mapping at the given address, typically causing corruption. I'm not sure what the BSD behaviour is; are you sure they handle MAP_FIXED differently? On Linux, this is not a problem because *without* MAP_FIXED, it will always use the specified address unless there is a conflict with existing mappings. On Solaris, we've implemented a hack that emulates the Linux behaviour in this respect (look at the routine solaris_try_mmap, which is called from wine_anon_mmap). I guess the proper fix would be to implement a similiar BSD specific workaround inside wine_anon_mmap. The Solaris version will probably not work unchanged on BSD, however. If you are correct in your interpretation of the semantics of MAP_FIXED on BSD, a workaround could look like this: first, try mapping with MAP_FIXED; if this fails, repeat without. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

Re: patch.py?id=1005690229526658676564693 (fwd)
by Gerard Patel Nov. 14, 2001

Nov. 14, 2001

At 10:10 PM 13/11/2001 -0500, you wrote: >Good day! > >regapi still works. My little winelib program exits with no error, but >leaves a stale socket and does nothing. juno.exe, progman, >I_view32.exe, and Dmitry's little About.exe leave a stuck wine process >and a stale wineserver socket. I expect there is general consternation, >or else it has been fixed already, but I guess I will have to reverse >the patch to see. > general consternation ? Well, I have about 20 test apps and 2 don't start anymore, the rest working as well as before. That's pretty ordinary ;-) I'm not completely sure if the patch is the culprit (I use Cvs and I get several patches at the same time). I don't have the time to investigate further right now. More later. Gerard

2 3

patch.py?id=1005690229526658676564693 (fwd)
by lawson_whitney＠juno.com Nov. 14, 2001

Nov. 14, 2001

Good day! regapi still works. My little winelib program exits with no error, but leaves a stale socket and does nothing. juno.exe, progman, I_view32.exe, and Dmitry's little About.exe leave a stuck wine process and a stale wineserver socket. I expect there is general consternation, or else it has been fixed already, but I guess I will have to reverse the patch to see. 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/web/.

2 1

Re: [RFC]: Overlapped I/O implementation
by Mike McCormack Nov. 14, 2001

Nov. 14, 2001

Hi Martin, >However, I assume you have had good reasons to abaondon the old >server-centric implementation, so I'm reluctant to go that way. Not really. The main reason i did it was because the server is slow and clunky and i thought i'd be able to squeeze a bit of extra performance out of the code by putting it in the client. The best starting point for solving the problems you describe is to revert my patch that put async I/O in the client. i'll even do it if you like... Now who said that premature optimization is the root of all evil? :-) Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Yet another async I/O issue: block devices
by Martin Wilck Nov. 13, 2001

Nov. 13, 2001

Hi, I just discovered yet another problem that arises for overlapped I/O on normal disk files, more correctly, for any file on a block device. Obviously IO requests on block devices on Linux are _always blocking_. I wrote a very simple test program for reading from a floppy disk and found exactly this behaviour, no matter if O_NONBLOCK was set or not. "man 2 open" also says that O_NONBLOCK may or may not have any effect on non-socket fd's and for block devices it clearly has none. I don't know the reason for this, but it may have to do with Linux' caching algorithms. This means that - with ReadFile() etc. on regular files, the asynch code will never be executed. Instead, the call will block when trying to read immediately, and then return success. - I am not 100% sure in what context the asynchronous handlers are executed, but the read() write() calls there will be blocking as well. I assume this is not what we want. - I guess that for programs that "know" some IO is going to take a lot of time (read()s on floppies, network file systems, ...) will potentially be broken if they try to do overlapped IO and "do something else" while the IO is executing. I do see the need, therefore, to have an approach that mimics Windows' behaviour here. - The only simple approach that I can see for making this happen is creating a separate thread for reading/writing asynchronous IO. The simplest approach would actually be to do a clone() for each async request with CLONE_FILES | CLONE_VM | CLONE_PARENT. I don't know how this would fit into Wine's general synchronization approach - please give me hints. - The separate thread itself would be very simple for files on block devices, because it can simply execute the blocking read and finish when the read finishes, leaving some status information somewhere. - For other devices that _do_ support O_NONBLOCK, it may be cool to mimic this simple behaviour by clone()ing too, dup() ing the fd, resetting the O_NONBLOCK flag, and doing a blocking IO request just the same. That means to basically leave it up to the kernel to handle synchronization. This would also mean that we wouldn't have to worry about differences between files and sockets/pipes, because I'm 99% sure the kernel would do it right. I don't understand the concept of the wine service thread well enough yet to judge if that could be used for doing what I just suggested. Perhaps someone can help me out with that, I'll be studying the sources in the meantime. Cheers, Martin PS. I guess another possible approach would be using raw I/O, but I am very certain this is not what we want. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Local USER classes act as global
by Joshua Thielen Nov. 13, 2001

Nov. 13, 2001

Hello, When I checked out the latest CVS, all the dialog boxes in Finale stopped working (again) . This happened since Alexandre fixed a function call from GetModuleHandleA("USER") to GetModuleHandle16("USER") in my previous GetClassInfo16 patch (thanks Alexnadre!). My patch had worked because GetModuleHandleA returned hInstance 0 for USER and Finale would proceed to register a window class with hInstance 0. Since classes with hInst=0 are treated sort of like global classes in wine, the window class was found. After more investigating, I discovered that in Win16, any window class that is registered with a USER instance handle will be found even if the hInstance passed to the function (GetClassInfo, CreateWindow etv c.) is completely different. This happens even for classes without the CS_GLOBALCLASS style. I have some small test apps if anyone is intrigued by this. Anyway, this patch implements this undocumented bug, uh.. er.. feature in wine and gets Finale working again . Changelog: Local classes registered with USER instance handle now are now found in CLASS_FindClassByAtom. Modified Files: wine/windows/wnd16.c Josh Thielen Index: wine/windows/class.c =================================================================== RCS file: /home/wine/wine/windows/class.c,v retrieving revision 1.42 diff -u -r1.42 class.c --- wine/windows/class.c 2001/11/06 20:57:27 1.42 +++ wine/windows/class.c 2001/11/13 23:23:39 @@ -279,10 +279,14 @@ * NOTES * 980805 a local class will be found now if registred with hInst=0 * and looed up with a hInst!=0. msmoney does it (jsch) + * + * Local class registered with a USER instance handle are found as if + * they were global classes. */ static CLASS *CLASS_FindClassByAtom( ATOM atom, HINSTANCE hinstance ) { - CLASS * class, *tclass=0; + CLASS * class, *tclass = 0, *user_class = 0; + HINSTANCE hUser = GetModuleHandle16("USER"); TRACE("0x%08x 0x%08x\n", atom, hinstance); @@ -293,16 +297,20 @@ if (class->style & CS_GLOBALCLASS) continue; if (class->atomName == atom) { - if (hinstance==class->hInstance || hinstance==0xffff ) + if (hinstance==class->hInstance || hinstance==0xffff) { TRACE("-- found local %p\n", class); return class; } - if (class->hInstance==0) tclass = class; + if (class->hInstance == 0) tclass = class; + else if(class->hInstance == hUser) + { + user_class = class; + } } } - /* Then search global classes */ + /* Then search global classes */ for (class = firstClass; (class); class = class->next) { @@ -312,6 +320,13 @@ TRACE("-- found global %p\n", class); return class; } + } + + /* Check if there was a local class registered with USER */ + if( user_class ) + { + TRACE("--found local USER class %p\n", user_class); + return user_class; } /* Then check if there was a local class with hInst=0*/

1 0

weird linux/solaris problem.
by Roger Fujii Nov. 13, 2001

Nov. 13, 2001

Well, I finally figured out the major problem I've been having with wine and virtualdub under solaris, but I'm not sure what to do about it. In memory/virtual.c, there are 2 problems: 1) in function anon_mmap_aligned, there is a section that tries to release extra memory. The problem is that under solaris, munmap length parameter is defined as: The munmap() function removes the mappings for pages in the range [addr, addr + len), rounding the len argument up to the next multiple of the page size as returned by sysconf(3C). It's not exactly clear what the linux munmap does, but I think that the linux one does what you think it SHOULD do, and the solaris one does what is documented (i.e. will unmap more pages than what the linux one thinks it would since it rounds UP the len). Now, I can see 2 fixes: 1 is to #ifdef __svr4 and compute the compensated len before unmapping. The other is to just not do this release (or at least not do it for __svr4). Any comments? 2) For some reason I don't quite understand, a call is made to VirtualProtect with a READONLY protection, and soon after, something tries to memcpy into that block. I'm not sure if this is a thread sync issue, or maybe this is supposed to work like c's const (ie, it's readonly AFTER the first write). Kind of puzzling, since it does work under linux. Any suggestions? (my current fix is to treat READONLY as RW, which works, but I know is wrong). Thanks. -r Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

1 0

Re: [RFC]: Overlapped I/O implementation
by Martin Wilck Nov. 13, 2001

Nov. 13, 2001

Hi Mike, all, I have thought some more. Having understood the problem with the possibly duplicate process fds, it is clear that in order to treat multiple simultaneous requests correctly, there must be some server-side support on a per-IO-object basis. With the current implementation as a guideline, I see only one possibility to do this: The server maintains two semaphores for async reading and writing for each I/O object (file, socket, comm port...) that has the OVERLAPPED flag set. The semaphores have a max count of 1 for FIFOS and some larger number for random-access files (this will be set by object-type-dependent functions). The async_private struct has a Semaphore field. When the client schedules an async request, it gets the suitable semaphore handler (read/write) of the I/O object from the server and stores it in the async_private struct. The async_handler function does not start actual I/O before acquiring the semaphore, and releases it when finished. The handler is in IO_PENDING state until it gets the semaphore and remains in that state after obtining access until it releases the semaphore. This provides a rather elegant framework for limiting the number of concurrent readers and writers. I am not sure, though, if the async_handler functions are allowed to wait for semaphores ??? Perhaps we'd need to use Unix semaphores ? Any other approach I've thought of so far seems to imply a lot of client-server interaction and mangling in the NtCurrentTeb()->pending_list. Please notify me if you have better ideas. The other possible solution would be to go back to the server-centric implementation of 8 months ago, or something similar. Most likely the NtCureentTeb()->pending_list would have to be dropped in that case, and server-side communications used instead. However, I assume you have had good reasons to abaondon the old server-centric implementation, so I'm reluctant to go that way. There is another concern, though. You wrote: > When the thread waits upon any server object, all (unix) fds with > pending overlapped operations are polled on. This is a minor problem > in the design; if the thread never waits upon an object the overlapped > can never complete, however the thread must wait upon the overlapped's > hEvent to check whether it has completed... AFAICS, there will not even be an I/O request unless the client waits on something (at least in ReadFileEx()). I wonder if this can cause the advantages of async IO to be lost if a a long time elapses before the client waits on anything. Definitely, if the first wait the client issues is on the async request itself, the handler will have done nothing in the meantime and there is no real asynchronicity any more. Meanwhile all arriving data must be buffered by the kernel. This is probably no problem on a serial port, but what if you're dealing with a fully loaded ethernet connection or a local socket with a lot of traffic? Anyway, That's probably a minor issue. Please tell me if you think the semaphore idea is feasible. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Pajama Sam audio problems mysteriously gone; Film at eleven
by Ori Pessach Nov. 12, 2001

Nov. 12, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In my attempts to figure out which change caused some games not to detect the sound card on my machine, I started checking out historic versions from CVS, building them, and testing whether they work or not. They all worked. All in all, I tested versions from 10/07/2001, the last version I knew worked, to the current CVS version, in a binary search pattern. The games still exhibit the problems I reported earlier - the sound is breaking up, and the colorful cursors don't show up, but at least I have something to debug now. If anybody has any ideas about the sound (waveOut*) that weren't discussed yet, I'd love to hear about them. I'd like to thank everyone for their time, especially Eric, who waded through megabytes of relay messages on what turned out to be a wild goose chase. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE78JUUzA/uWWyw6uQRAutEAKCs/nb8dqkcoqOxKfonO8B5d5HyUgCgwImR rwT2dIFiZ5Yo7MzODLio2hw= =9RtW -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Regression errors
by Gerard Patel Nov. 12, 2001

Nov. 12, 2001

At 11:06 AM 10/11/2001 -0500, you wrote: > >Thanks Gerard. I will try it Tuesday. Going out of town till then. Well, I have advanced a bit this weekend. I noticed that one of my test app does indeed show this regression after the patch we are talking about. As the case is a lot more simple than the one I was trying to debug before for this problem, I have been able to understand better what is happening. The problem shows itself in the following case : - invalidating a window - hiding it - deleting it and after that the paint count is > 0. I can make the paint count change correctly with the following change : --- winpos.c.orig Thu Nov 8 01:57:34 2001 +++ winpos.c Mon Nov 12 09:47:08 2001 @@ -883,10 +883,10 @@ if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { - WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); /* clear the update region */ -// RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | -// RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | + RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); } else if ((wndPtr->dwStyle & WS_VISIBLE) && !IsRectEmpty( &oldWindowRect ) && IsRectEmpty( &newWindowRect )) Now, I don't know why this RedrawWindow call was commented out :-/ Gerard

2 1

Re: Yet another async I/O issue: block devices
by Mike McCormack Nov. 12, 2001

Nov. 12, 2001

Hi Martin, Probably better to get the ordered overlappeds working on sockets and serial ports first before trying to perfect block devices. That will bring Wine's feature set inline with Win9x overlapped I/O. I've never had anybody complain that overlapped I/O on block devices doesn't work for any program. Most programs avoid using features that only work on NT... you're likely to find that only NT services use those API calls.... and they won't work on Wine anyhow, seeing we don't support services properly yet. It seems like a good idea to try to make everything perfect from the start, but an incremental approach is usually better. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi, > >I just discovered yet another problem that arises for overlapped >I/O on normal disk files, more correctly, for any file on a block device. > >Obviously IO requests on block devices on Linux are _always blocking_. >I wrote a very simple test program for reading from a floppy disk and >found exactly this behaviour, no matter if O_NONBLOCK was set or not. >"man 2 open" also says that O_NONBLOCK may or may not have any effect on >non-socket fd's and for block devices it clearly has none. > ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: x11ddraw fix
by Alexandre Julliard Nov. 12, 2001

Nov. 12, 2001

geschrader <geschrader(a)mediaone.net> writes: > When X11DRV_XF86DGA2_CreatePalette( ) creates the palette > used by X11DRV_DDHAL_DestroyPalette( ) and > X11DRV_DDHAL_SetPalEntries( ), the display which is used is > returned by thread_display( ). This patch makes these two functions > also use thread_display( ) ( rather than gdi_display ). This bug was > causing a BadColor (i.e. invalid colormap) error in the X server > when X11DRV_DDHAL_SetPalEntries( ) was called, followed by > an application crash. I think it would be better to create the palette on the gdi_display, this way it can be manipulated by other threads too. Could you try if this works for you? Index: dlls/x11drv/dga2.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dlls/x11drv/dga2.c 2001/09/11 00:32:33 1.5 +++ dlls/x11drv/dga2.c 2001/11/07 20:28:34 @@ -174,8 +174,8 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); - data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); + data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(gdi_display, DefaultScreen(gdi_display), + dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, data->lpColorTable); @@ -199,10 +199,9 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { - TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); + TSXDGAInstallColormap(gdi_display, DefaultScreen(gdi_display), data->lpDDPalette->u1.dwReserved1); } data->ddRVal = DD_OK; return DDHAL_DRIVER_HANDLED; -- Alexandre Julliard julliard(a)winehq.com

3 2

[RFC]: Overlapped I/O implementation
by Martin Wilck Nov. 12, 2001

Nov. 12, 2001

Hi, I'd like to summarize my thoughts about an implementation of overlapped I/O in Wine that will offer full Windows functionality. I havent't thought it through in all detail, but I have a clear enough picture to write an RFC. I regard the following points as crucial: 1 "Generic" routines like ReadFileEx() need to work with files of almost arbitrary type, i.e. normal files, pipes, sockets, comm ports, ... 2 Different file types imply different semantics for overlapped I/O. In particular: a Files that don't support positioning (i.e. FIFOs, or basically everything except regular files) need to be accessed sequentially, i.e. there may only be one reader and one writer at a time, and these must be scheduled in the same order in which they were submitted by the application. Otherwise, the data read or written will be potentially scrambled. For regular files, on the other hand, spawning several I/O requests in parallel may be beneficial. b Files on some devices (in particular, block devices on Linux) need to spawn a separate thread for the async I/O operation, because I/O on such devices is always blocking, which is undesirable. Neither the process itself nor the service thread should be blocked by a time-consuming floppy I/O operation, for example. 3 The semantics of individual asynchronous I/O requests depend on the function that was called by the application, e.g. ReadFile() or WSARecv(), which take different arguments. Such calls may be mixed by the application, although it's certainly not good programming practice to do so. Based on these arguments, I'd suggest the following: A) The generic functions need to find out what the properties of a file descriptor wrt asynch I/O are. The most general way to implement this is to have an element int (*get_async) (struct object*, struct file_async*) in the obj_ops array. For non-file objects, this element would be NULL or no_get_async(). For non-overlapped file descriptors, the function would assign NULL to the file_async* argument, and return an error, a valid pointer would be assigned to file_async* otherwise. struct file_async would contain per-file information about asynch I/O, e.g. struct file_async { struct async_private *readers; /* list of async read requests */ struct async_private *writers; /* list of async write requests */ int flags /* supports positioning? Is I/O blocking on host OS ? etc. */ int (*get_timeout) (struct object *obj, int type, int count); /* function that returns timeout for device, needed e.g. for serial comm */ } I currently see no need for other file-type dependedent functions; It should be possible to write generic routines that handle the requests correctly according to the flags variable. The Wine server API would containe a file_get_async() request that returns the file_async structure associated with the file by calling the get_async() element of obj_ops. The async_private struct would look pretty similar as it looks now, with a generic part and a part that depends on the function invoked for doing async I/O (e.g. for sockets, whether ReadFile() or WSARecv() was called on the socket fd). IMO the async_private should not contain file type-dependent information which is per-file. It should rather contain a pointer to the respective file_async struct. Most importantly, the async_private struct it carries a pointer to a function that does the actual I/O, and another function pointer that handles the termination of the request (invocation of user completion routine etc.) B) The check_async() function in synchro.c operates on file descriptors rather than async requests. Once an overlapped I/O request is issued by the application, it is queued either in the readers or writers list of the async object (which is obtained from the server). If both the readers and writers lists were NULL beforehand, the fd is inserted into the list for check_async to work on. check_async() activates the first element(s) of both the readers and writers lists (where activate means that the actual read/write call is triggered). For FIFOS, only one element would be activated; for regular files several requests up to a given limit (e.g. 4). If the file is on a device where normal I/O would be blocking, a new thread is created for each activated request to satisfy it. When the requests' I/O routine (separate thread or not) is completed, it activates an event that triggers the generic "finish" routine. The finish routine calls the finish routine of the request, cleans up, and activates a new request if there is one that was queued but not activated. If both the readers and writers queue are empty after finishing the request, the file descriptor is removed from the list of handles to check in check_async(). C) If CancelIo() is called or a file is closed, all pending IO requests are removed from the file's async readers and writers lists; potential subthreads are terminated. With this approach, the wineserver would only be needed for retreiving the file's async I/O properties. The biggest change to the wine core would be the addition of a new function to obj_ops. I am looking forward to comments. Regards, Martin PS. A minor remark: The above approach would make it unnecessary to check for the return value of xyz_get_info() to be FD_TYPE_OVERLAPPED when initiating overlapped I/O. Instead, one could simply check if the async object returned by get_async() is non-NULL. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: GetDlgItem16 - is id signed or not?
by Gerard Patel Nov. 12, 2001

Nov. 12, 2001

At 07:07 PM 11/11/2001 -0500, you wrote: > >It hasn't gotten itself fixed in the ordinary way of progress, so I have >finally gotten around to a regression in juno-1.49. It crashes just >after getting back 0 from GetDlgItem16, so I added a little trace inside >GetDlgItem. Now I know why it crashes, but I don't know - is id really >unsigned, or is GetControl16 incorrectly failing to extend the sign? >I guess I could try it each way and see which one does least damage, but >probably several of you know which way it is meant to go. I'd cast id to unsigned in GetDlgItem16. Gerard

2 1

Re: Regression errors
by Eric Pouech Nov. 12, 2001

Nov. 12, 2001

> At 11:06 AM 10/11/2001 -0500, you wrote: > > > >Thanks Gerard. I will try it Tuesday. Going out of town till then. > > Well, I have advanced a bit this weekend. I noticed that one of my > test app does indeed show this regression after the patch we are talking > about. > > As the case is a lot more simple than the one I was trying to debug > before for this problem, I have been able to understand better what > is happening. The problem shows itself in the following case : > > - invalidating a window > - hiding it > - deleting it IIRC, before the big window overhaul (when paint count was attached to each window), when a window was hidden, its paint count wasn't set to 0 (or when the window was actually shown, its paint count wasn't set to 1). This lead to some painting errors... I don't know if this is fully related (and I didn't follow closely the new window stuff), but it may be related... in case this helps... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Re: More overlapped I/O issues (important)
by Mike McCormack Nov. 12, 2001

Nov. 12, 2001

Hi Martin, You're right, i never considered multiple overlapped requests at the same time... To fix the problem correctly, you will need to move (some of) the overlapped code back to the wineserver, so that requests from different processes can be handled correctly. (i moved it out of the wineserver about a year ago for efficiency reasons.) Have a look at rev 1.7 of server/async.c to see how this worked. http://cvs.winehq.com/cvsweb/wine/server/async.c?rev=1.7&content-type= text/x-cvsweb-markup The current overlapped code (with the above exception) is similar to what win 9x supports, so it does not support overlapped on normal files, and file offsets in OVERLAPPED structures. If that could be implemented too, it would be good. i guess there is choice now... implement overlapped sockets with the existing structure, or make a rather large change to the wine architecture, which might take a while. Maybe a good first step is to back out my change which put overlapped operations into the client side code... Alexandre thought this could be done using POLLIO instead... Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi Mike, all, > >I see a severe problem with the current overlapped I/O implementation, >especially wrt extending it to Winsock2 overlapped I/O. > >The problem I see is with buffer ordering. > >For normal files, the file position from which to read is on the >OVERLAPPED struct. This was not in the Wine implementation, the patch in >my last email fixes it. > >For sockets and other FIFOs, this makes no sense. In this case Windows >specifies that buffers are read / written **in the same order they were >submitted**. This matters only if users spawn several asynchronous I/O >requests at the same time, but this is allowed and actually beneficial >for application performance (at least on Windows). > >Unless I oversee something essential, the current wine implementation >does not guarantee such behaviour. Actually, since new requests are >inserted at the head of the NtCurrentTeb() list, they will be considered >first in subsequent asynchronous reads - i.e. the order will be reversed. >If I/O requests don't complete in a single read() or write() call, the >ordering will be basically random. > >IMO this implies that for sockets, asynchronous reads and writes must >be scheduled such that only one request for a given socket is actually >reading at a time, and all others are blocked until this request is >finished. Again, this holds only for FIFO-type files. > >With the current structure, it seems to be very complex to sort this out. >One could recheck the fd list in check_async and remove duplicate fds. >One could also try to "lock" the fd somehow. Still it would be necessary >to ascertain that the correct request gets the lock first. > >With this min mind, it seems more natural for me to organize the >asynchronous requests in the "file" data structure itself. One would >have a reader's and a writers's list there, and make sure that for FIFOS >only the first list element can actually issue a read(), write(), send(), >or recv() system call. For normal files all elements in the lists could be >doing IO at the same time, question is if that makes sense or not. > >As I see it, this would mean both the readers and writers lists must >be stored in the file data structure in the wine server. >This would of course strongly affect the current implementation. > >Note that with Winsock2 overlapped I/O in place, it must >be possible to use also ReadFile(), ReadFileEx() etc. on >overlapped sockets, and get correct behaviour. >Thus the ReadFile() etc. code must be able to deal with both sockets >and ordinary files, and it makes no sense to intriduce a different >approach for sockets only. > >Please give me your opinion on these issues ASAP. > >Regards >Martin > >-- >Martin Wilck Phone: +49 5251 8 15113 >Fujitsu Siemens Computers Fax: +49 5251 8 20409 >Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com >D-33106 Paderborn http://www.fujitsu-siemens.com/primergy ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Loop (and other) problem in audio.c 1.45 located
by Simon Britnell Nov. 12, 2001

Nov. 12, 2001

The problem is that I advance to the next wavehdr automatically in FeedDSP, which skips the first wavehdr sent to the wodPlayer. Doh! A patch will follow to fix this (which will be built on top of the race condition fix patch). __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

Re: Winsock2 & overlapped IO
by Mike McCormack Nov. 11, 2001

Nov. 11, 2001

Hi Martin, Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> >I have taken a closer look at this code. I believe a very similar approach >is possible for Winsock. However, there are a few problems: Good to see you are a man of action, not just words! >typedef struct async_private .. >What do you think about this? > >It would be cleaner to define a "general" async structure >containing either a type-specific union or a pointer to >type-specific data, and using void* for pointers. However, that would >require even more changes in the async file I/O code, which I'd like to >avoid at the moment. i agree with you it would be better to use a union... i'll have a go at making a patch to do this. i'll probably understand the mess i've created in files/file.c more easily ;-) >Another difference is that the overlapped Winsock routines cause >asynchronous success notification (i.e. calling the completion routine or >signalling the lpOverlapped->hEvent) even if they are immediately >successful, which seems not to be the case for asynchronous file I/O. > >That would require a minor change in the check_async_list() routine. Cool, go for it. >Please tell me your opinion! > >Regards, >Martin i wrote a longer reply with a union definition in it, but accidently resized my Netscape window an lost it when the page reloaded :-( Could be about time to give up on this web-based email thing. Mike btw. in the patch in your other mail, you have: -typedef struct _OVERLAPPED * LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; + +typedef struct _WSAOVERLAPPED { + DWORD Internal; + DWORD InternalHigh; + DWORD Offset; + DWORD OffsetHigh; + WSAEVENT hEvent; +} WSAOVERLAPPED, *LPWSAOVERLAPPED; + can you just use the following? typedef OVERLAPPED WSAOVERLAPPED; typedef LPOVERLAPPED LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; or even #define... ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 3

GetDlgItem16 - is id signed or not?
by lawson_whitney＠juno.com Nov. 11, 2001

Nov. 11, 2001

Good day! It hasn't gotten itself fixed in the ordinary way of progress, so I have finally gotten around to a regression in juno-1.49. It crashes just after getting back 0 from GetDlgItem16, so I added a little trace inside GetDlgItem. Now I know why it crashes, but I don't know - is id really unsigned, or is GetControl16 incorrectly failing to extend the sign? I guess I could try it each way and see which one does least damage, but probably several of you know which way it is meant to go. trace:dialog:DIALOG_CreateControls BEGIN trace:dialog:DIALOG_GetControl16 STATIC '' 1164, 12, 4, 232, 45, 50020000, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Get and Send Mail' 1162, 10, 55, 56, 28, 5003000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Just Get Mail' 1163, 70, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON 'Cancel' 1161, 130, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Help' 57669, 190, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_CreateControls END trace:dialog:GetDlgItem GWL_ID 48c id 48a trace:dialog:GetDlgItem GWL_ID 48a id 48a trace:dialog:GetDlgItem GWL_ID 48c id 48b trace:dialog:GetDlgItem GWL_ID 48a id 48b trace:dialog:GetDlgItem GWL_ID 48b id 48b trace:dialog:GetDlgItem GWL_ID 48c id 489 trace:dialog:GetDlgItem GWL_ID 48a id 489 trace:dialog:GetDlgItem GWL_ID 48b id 489 trace:dialog:GetDlgItem GWL_ID 489 id 489 trace:dialog:GetDlgItem GWL_ID 48c id ffffe145 trace:dialog:GetDlgItem GWL_ID 48a id ffffe145 trace:dialog:GetDlgItem GWL_ID 48b id ffffe145 trace:dialog:GetDlgItem GWL_ID 489 id ffffe145 trace:dialog:GetDlgItem GWL_ID e145 id ffffe145 wine: Unhandled exception, starting debugger... Regards, Lawson The Devil finds work for idle minds.

1 0

Latest CVS Wine winmm
by Ori Pessach Nov. 10, 2001

Nov. 10, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I tried running Pajama Sam today (a Humongous Entertainment game), which used to run, with some sound problems, a while ago. Now, I get a dialog box on startup, saying that "No sound card was detected". 'wine -debugmsg +wave,+msys' shows multiple instances of the message: trace:mmsys:DriverCallback Null ! - From a quick look at mmsystem.c, it's not immediately clear whether this is a problem or not. At some point later on, I get: err:msacm:wodCallback Bad data But, this only happens after I close the dialog box, so that can't be the cause of the failure. Again, this used to work before. I first tried it with Simon's recent patch, and then checked out current the CVS version of mmsystem.c, and I don't see a difference. Any ideas? I have a complete dump the trace messages, but I'd rather not post it here, since it's fairly big. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE77KsXzA/uWWyw6uQRApmPAKDOJ5LmmUzwWczXJ/So263BrFR26ACfeLkr SbhwMyhft7A5pmgIO1azzfA= =VyBD -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 2

Re: Regression errors
by Gerard Patel Nov. 10, 2001

Nov. 10, 2001

At 12:38 AM 10/11/2001 -0500, you wrote: >1. SetTimer call is not always generating WM_TIMER messages as it should. I >see: > >0806bb20:Call user32.SetTimer(00020057,00001003,00000000,6003a04c) >ret=6001e9e4 >0806bb20:Ret user32.SetTimer() retval=00001003 ret=6001e9e4 > >in the trace, but never is the callback routine invoked. Without the above >patch, the callback is invoked and does the painting. I am not sure if it's related, but I have seen something like that. I have seen it since much longer than this patch, though. It's about the paint count in the server. When there is a paint count > 0 in the server and the number of windows found to need a repaint (at the client level) is less than the paint count, the client can never get a timer event again. Try this patch to dlls/user/message.c to see if your problem is related : --- message.c.orig Sat Nov 10 07:03:29 2001 +++ message.c Sat Nov 10 07:08:27 2001 @@ -1861,6 +1861,7 @@ USER_Driver.pMsgWaitForMultipleObjectsEx( 0, NULL, 0, 0, 0 ); hwnd = WIN_GetFullHandle( hwnd ); +yetanothergoto: locks = WIN_SuspendWndsLock(); if (!MSG_peek_message( &msg, hwnd, first, last, @@ -1884,8 +1885,19 @@ /* need to fill the window handle for WM_PAINT message */ if (msg.message == WM_PAINT) { - if (!(msg.hwnd = WIN_FindWinToRepaint( hwnd ))) return FALSE; - + if (!(msg.hwnd = WIN_FindWinToRepaint( hwnd ))) + { + TRACE("FIXME : server paint count > 0 but no window needs painting\n"); + SERVER_START_REQ( inc_queue_paint_count ) + { + req->id = (void *)GetWindowThreadProcessId( hwnd, NULL ); + if (!req->id) req->id = (void *)GetCurrentThreadId(); + req->incr = -100000; /* reset paint count */ + SERVER_CALL(); + } + SERVER_END_REQ; + goto yetanothergoto; + } if (IsIconic( msg.hwnd ) && GetClassLongA( msg.hwnd, GCL_HICON )) { msg.message = WM_PAINTICON; I have no idea about your second problem. Gerard

2 1

Help with Revelant demo
by Paul Millar Nov. 10, 2001

Nov. 10, 2001

Hi, [I'm prefacing this by saying know next to nothing about Windows] I've had a quick go at getting the (newer) demo of Eidos' Revenant game to run. The install works ok, but when I try to run the demo, I get a msgbox saying: "FATAL ERROR", "Unable to initialize Network" and the following appearing on stderr: > fixme:ole:CoCreateInstance no classfactory created for > {2fe8f810-b2a5-11d0-a787-0000f803abfc}, hres is 0x80040154 Rerunning with the "-debugmsg +ole" option, I get some (not terribly useful) extra info: > trace:ole:OLE32_DllEntryPoint 0x4087b000 0x1 0x1 > trace:ole:CoInitializeEx ((nil), 2) > trace:ole:CoInitializeEx () - Initializing the COM libraries > trace:ole:RunningObjectTableImpl_Initialize () > trace:ole:WINE_StringFromCLSID > 0x5a27f8->{2FE8F810-B2A5-11D0-A787-0000F803ABFC} > trace:ole:CoGetClassObject > CLSID: {2fe8f810-b2a5-11d0-a787-0000f803abfc}, > IID: {00000001-0000-0000-c000-000000000046} > fixme:ole:CoCreateInstance no classfactory created for > {2fe8f810-b2a5-11d0-a787-0000f803abfc}, hres is 0x80040154 > trace:ole:OLE32_DllEntryPoint 0x4087b000 0x0 0x1 I did a Google search and "2fe8f810-b2a5-11d0-a787-0000f803abfc" seems to be the CLSID of DirectPlayLobby. On a seperate note, I can't figure out which bit (or lack) of WINE is causing the "network error". From what I can see, there doesn't seem to be any network activity as rerunning with "-debugmsg +wnet,+winsock" doesn't produce any extra output. FWIW, there is an .INI file with the following: > [Network] > ConnectType=none > SessionName=none > Provider=IPX > ConnectTime=5 So my questions are: 1. How easy would it be to fix/add CLSID_DirectPlayLobby? (where do I start)? 2. Any suggestions how to go about debugging the apparently fatal "No Network" msgbox? Cheers, Paul. ------------------------------------------------------------------------------ Paul Millar yo-yo, n. : Particle Physics Theory Group Something that is occasionally Department of Physics and Astronomy up but normally down. University of Glasgow, (see also Computer) Glasgow G12 8QQ, paulm(a)physics.gla.ac.uk Scotland +44 (0)141 330 4717 ------------------------------------------------------------------------------

1 0

Regression errors
by Guy L. Albertelli Nov. 9, 2001

Nov. 9, 2001

I have noticed two other regression issues with the patch to "Store in the server all the window info... " (01/10/22 15:08:34). Both of these occur in Outlook Express 4. 1. SetTimer call is not always generating WM_TIMER messages as it should. I see: 0806bb20:Call user32.SetTimer(00020057,00001003,00000000,6003a04c) ret=6001e9e4 0806bb20:Ret user32.SetTimer() retval=00001003 ret=6001e9e4 in the trace, but never is the callback routine invoked. Without the above patch, the callback is invoked and does the painting. 2. A WM_KEYUP (wparam is VK_CNTL) message is generated and processed even though no key is touched on the keyboard. If "-debugmsg +key" is specified the message never appears, nor does any trace:key: entry. Has anybody else seen or trapped these bugs? Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0