- Wine-devel - list.winehq.org

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

16 Nov '01

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 16 Nov '01

16 Nov '01

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 16 Nov '01

16 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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 15 Nov '01

15 Nov '01

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