June 2004 - Wine-devel - list.winehq.org

AT_SYSINFO under RedHat 8
by Bill Medland 28 Jun '04

28 Jun '04

preloader.c doesn't make due to the most recent change. Presumably AT_SYSINFO is supposed to be in the Elf.h? Bill -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

Crash when resizing window in Desktop mode
by Uwe Bonnes 28 Jun '04

28 Jun '04

Hallo, resizing the window of ISE (Xilinx FPGA programming suite), the mouse remains captured inside the wine desktop and following backtrace can be requested: Backtrace: =>1 0x404fdc04 DebugBreak+0x4 [debugger.c:274] in kernel32 (0x406ef1fc) 2 0x41f11067 error_handler+0x87(display=0x78089550, error_evt=0x406ef248) [x11drv_main.c:186] in x11drv (0x406ef210) 3 0x4114fc6b (0x406ef2c0) 4 0x4114e086 (0x406ef300) 5 0x41148f15 (0x406ef340) 6 0x41148ff5 (0x406ef360) 7 0x41130269 (0x406ef380) 8 0x41ee08a1 BITBLT_InternalStretchBlt+0x6e1(physDevDst=0x403d8f60, xDst=0x53, yDst=0x64, widthDst=0x286, heightDst=0x4, physDevSrc=0x0, xSrc=0x0, ySrc=0x0, widthSrc=0x0, heightSrc=0x0, rop=0x5a0049) [bitblt.c:1429] in x11drv (0x406ef424) 9 0x41ee0d93 X11DRV_PatBlt+0x43(physDev=0x403d8f60, left=0x53, top=0x64, width=0x286, height=0x4, rop=0x5a0049) [bitblt.c:1533] in x11drv (0x406ef470) 10 0x408a34ec PatBlt+0x5c(hdc=0xb38, left=0x53, top=0x64, width=0x286, height=0x4, rop=0x5a0049) [bitblt.c:42] in gdi32 (0x406ef49c) 11 0x41f0d8f7 draw_moving_frame+0x67(hdc=0xb38, rect=0x406ef58c, thickframe=0x1) [winpos.c:1763] in x11drv (0x406ef4cc) 12 0x41f0e7b4 X11DRV_SysCommandSizeMove+0xae4(hwnd=0x20028, wParam=0xf008) [winpos.c:2062] in x11drv (0x406ef5c8) 13 0x407c03e1 NC_HandleSysCommand+0x1b1(hwnd=0x20028, wParam=0xf008, lParam=0x25302d3) [../../windows/nonclient.c:1499] in user32 (0x406ef5f4) 14 0x407b0b5f DEFWND_DefWinProc+0x98f(hwnd=0x20028, msg=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/defwnd.c:528] in user32 (0x406ef684) 15 0x407b10c3 DefWindowProcA+0xa3(hwnd=0x20028, msg=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/defwnd.c:916] in user32 (0x406ef6b0) 16 0x407ba2d2 DefFrameProcA+0x42(hwnd=0x20028, hwndMDIClient=0x1002a, message=0x112, wParam=0xf008, lParam=0x25302d3) [../../windows/mdi.c:1272] in user32 (0x406ef6d4) 17 0x6c376a27 (0x406ef7bc) 18 0x6c371cea (0x406ef7dc) 19 0x40e41ccc (0x0000f008) 20 0x00000000 (0x00000000) This is with today's CVS -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Re: fix typo in wwn
by Ivan 28 Jun '04

28 Jun '04

> And they don't use the metric system. Shame. The matric system is way more used in the UK than in the US, where it's hardly used at all. Ivan.

1 0

Re: Change REFIID to IID* for stack declarations in oaidl_p.c to avoid initializers being discarded
by Mike Hearn 27 Jun '04

27 Jun '04

On Sun, 27 Jun 2004 21:13:17 +0200, Marcus Meissner wrote: >> + It is usually generated directly by MIDL, however this file has >> + been tweaked since then to account for slight differences in the way >> + gcc and MSVC++ compile it. In particular, in some functions REFIIDs >> + declared on the stack have been converted to plain IID* in order to eliminate >> + the constness of the REFIID type, ensuring that the zero initializer is not >> + discarded. >> + >> + Therefore, please do not regenerate this file. >> +*/ > > The comment is not understandable. > > Shouldn't it read '"REFIID" should not be used, because the value is not "const"'? I don't understand that wording of the comment either unfortunately :( It's not that it shouldn't be used, it's more that in the original generated code (I think) it was written like this: REFIID riid; (REFIID ) riid = 0; I'm not sure why MIDL did this, but as REFIID is simply #define REFIID const IID* const changing those instances to IID* should "fix" it without any warnings about assigning to a readonly variable. REFIID can still be used elsewhere though. thanks -mike

1 0

Re: Tooltips: Start of Balloon Support
by Dmitry Timoshkov 27 Jun '04

27 Jun '04

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > This patch marks the start of balloon tip support. Note that it also has > the same bug as native due to regions not being handled the same as on > Windows. Do you mean a bug in FrameRgn? If yes, ReactOS might have that bug fixed in their implementation. Could you have a look? -- Dmitry.

2 1

Re: Change REFIID to IID* for stack declarations in oaidl_p.c to avoid initializers being discarded
by Marcus Meissner 27 Jun '04

27 Jun '04

On Sun, Jun 27, 2004 at 05:23:27PM +0100, Mike Hearn wrote: > This can cause a subtle marshalling failure in some cases > (inter-thread IDispatch, native MSI, etc) > > > Mike Hearn <mh(a)codeweavers.com> > Change REFIID to IID* for stack declarations in oaidl_p.c to avoid > initializers being discarded > Index: oaidl_p.c > =================================================================== > RCS file: /home/wine/wine/dlls/oleaut32/oaidl_p.c,v > retrieving revision 1.2 > diff -u -p -w -r1.2 oaidl_p.c > --- oaidl_p.c 5 Sep 2003 23:08:33 -0000 1.2 > +++ oaidl_p.c 27 Jun 2004 16:17:04 -0000 > @@ -1,5 +1,14 @@ > -/* this ALWAYS GENERATED file contains the proxy stub code */ > +/* This file contains the proxy/stub code for core COM interfaces. > > + It is usually generated directly by MIDL, however this file has > + been tweaked since then to account for slight differences in the way > + gcc and MSVC++ compile it. In particular, in some functions REFIIDs > + declared on the stack have been converted to plain IID* in order to eliminate > + the constness of the REFIID type, ensuring that the zero initializer is not > + discarded. > + > + Therefore, please do not regenerate this file. > +*/ The comment is not understandable. Shouldn't it read '"REFIID" should not be used, because the value is not "const"'? Ciao, Marcus

1 0

Wine/WineX and subfs
by Uwe Bonnes 27 Jun '04

27 Jun '04

Hallo, when trying to install programs from subfs mounted CDROMS, wine stumbled on several occasions (GetVolumenInformation?), running on Suse 9.1. I had not yet time to investigate deeper. However the announcement for WineX 3.3.2 tells explicit about changes for CDROMs and subfs for Suse9.1. Anybody from Transgaming reading hear, willing to submit a patch or explain the changes? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

FILE_GetNtStatus Converting errno 38 to STATUS_UNSUCCESSFUL
by Jürgen Leibner 27 Jun '04

27 Jun '04

Hi there, i'm trying to install a Software for Schools using wine-20040505-SuSELinux90.i586.rpm. After launching wine as user with: # wine setup.exe i get this message: .... # fixme:ntdll:FILE_GetNtStatus Converting errno 38 to STATUS_UNSUCCESSFUL Is anybody out there, who is able to explain what happens and what to do to get succsess? Thanks, Jürgen

3 3

Re: Change Desktopsize for _INS5576._MP in config
by Uwe Bonnes 27 Jun '04

27 Jun '04

>>>>> "Uwe" == Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: Uwe> Changelog: documentation/samples/config: Uwe> [AppDefaults\\_INS5576._MP\\x11drv] Change Desktop size to 800x600 Uwe> With a desktop siye of 640y480, Sage PC Kaufmann Setup aborts, Uwe> asking for higher resolution. Looking at http://frankscorner.org/modules.php?op=modload&name=Sections&file=index&req… the small desktopsize used until now for _INS5576._MP seems to cause problems with the photoshop installer too... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Suppressing NTDLL Relay messages
by Uwe Bonnes 27 Jun '04

27 Jun '04

Hallo, as the include and exclude lists for relay logging are initialized later than our ntdll is loader, relay logs contain all ntdll calls, even if the user didn't request them. Does anybody have an idea how to make the ntdll relay behave better? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0