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

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

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. 15, 2001

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

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

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

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