- Wine-Devel - list.winehq.org

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

Nov. 19, 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. 18, 2001

Nov. 18, 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. 17, 2001

Nov. 17, 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. 16, 2001

Nov. 16, 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. 16, 2001

Nov. 16, 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