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

Re: Does Wine's winhlp work?

by Waldek Hebisch

David D. Hagood wrote: >Is Wine's WinHelp program supposed to work? By that I mean, if I invoke >that program with a Windows help file, is it supposed to be able to >display the contents of the help file as Window's winhelp.exe would? I was about to ask the same question. My impression was that: i) 'winhelp' is completely non-functional ii) part reading help files only handles very old help files I implemented code to read somewhat newer help files, to degree that 'hlp2sgml' program is able to get some output, but since data structures used by graphical part are largly NOT filled, 'winhelp' itself has more reasons not to work (I have not sent patch to 'hlpfile.c' in case 'winhelp' actually can read some files). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

Aug. 17, 2001

Re: not-yet-connected sockets?

by Ove Kaaven

On Thu, 16 Aug 2001, Daniel Walker wrote: > The problem is that poll returns POLLHUP when a socket isn't connected, > then wine ignores the socket and it's events .. I realize this has been > known for a some time(since linux 2.4), but why hasn't it been fix? > Doesn't this effect a lot of non-blocking socket applications? No, since this problem was fixed half a year ago, it shouldn't affect anything.

Aug. 17, 2001

Re: err:module:map_image Could not map section .data, file probably truncated

by Uwe Bonnes

>>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: mdew> a number of apps that wouldve worked normally ..are now failing to mdew> load due to this error.. err:module:map_image Could not map mdew> section .data, file probably truncated /usr/local/bin/wine: can't mdew> exec './xxx.exe': error=21 -- Did the files perhaps catch a Virus? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 17, 2001

Re: Does Wine's winhlp work?

by Huw D M Davies

On Thu, Aug 16, 2001 at 08:28:27PM -0500, David D. Hagood wrote: > Is Wine's WinHelp program supposed to work? By that I mean, if I invoke > that program with a Windows help file, is it supposed to be able to > display the contents of the help file as Window's winhelp.exe would? > > I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses > WinHelp format documents for some of its normal operation, and 2) I have > a WinHelp format file I'd dearly like to be able to access directly from > Wine. > > When I try to launch Wine's Winhelp, it brings up a window, but the > window is empty. If I go to File->Open and try to open a WinHelp file, I > get the same result. Is there some setup I'm missing? > IIRC there are two formats; 16 and 32 bit. Wine's winhelp only understands the former, while of course any help file shipped today is likely to be in the latter format. Huw.

Aug. 17, 2001

err:module:map_image Could not map section .data, file probably truncated

by mdew

a number of apps that wouldve worked normally ..are now failing to load due to this error.. err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

Aug. 17, 2001

Re: not-yet-connected sockets?

by Daniel Walker

Daniel Walker wrote: > > Dan Kegel wrote: > > > > Daniel Walker wrote: > > > > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > > then wine ignores the socket and it's events .. I realize this has been > > > known for a some time(since linux 2.4), but why hasn't it been fix? > > > Doesn't this effect a lot of non-blocking socket applications? > > > > Can you define the problem a bit more? Do you mean you get a POLLHUP > > *while waiting* for connection? > > No, I mean that a socket is created using socket() then, say, ioctl() > is run on it. ioctl() then ,through the wineserver, runs sock_reselect() > then poll() returns POLLHUP in revents and the wineserver stop watching > the socket .. Since most non-blocking applications run socket() then > ioctl() I would think that several applications would be effected.. This problem has already been documented. The Linux Kernel 2.4 changed the way poll() works. But wine apparently hasn't been updated to work with the way poll() currently works .. Under some situations an application will open a socket then set it as non-blocking with ioctl() , while all that is happening the wineserver gets a POLLHUP (btw, I'm talking about revents) from poll() and subsequently ignores all other event on the socket.. the issue is discussed at the bottom of this WWN .. http://www.winehq.com/News/2000-26.html

Aug. 17, 2001

Re: not-yet-connected sockets?

by Dan Kegel

Daniel Walker wrote: > > Dan Kegel wrote: > > > > Daniel Walker wrote: > > > > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > > then wine ignores the socket and it's events .. I realize this has been > > > known for a some time(since linux 2.4), but why hasn't it been fix? > > > Doesn't this effect a lot of non-blocking socket applications? > > > > Can you define the problem a bit more? Do you mean you get a POLLHUP > > *while waiting* for connection? > > No, I mean that a socket is created using socket() then, say, ioctl() > is run on it. ioctl() then ,through the wineserver, runs sock_reselect() > then poll() returns POLLHUP in revents and the wineserver stop watching > the socket .. Since most non-blocking applications run socket() then > ioctl() I would think that several applications would be effected.. When I run the following program, I get n=0 consistently on linux 2.2 or 2.4. Did I misunderstand the test condition? #include <stdio.h> #include <sys/poll.h> main() { int fd; struct pollfd pfds[1]; int n; fd = socket(); pfds[0].fd = fd; pfds[0].events = POLLIN|POLLOUT; n = poll(pfds, 1, 0); printf("n %d, revents %x\n", n, pfds[0].revents); } -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 17, 2001

Re: not-yet-connected sockets?

by Daniel Walker

Dan Kegel wrote: > > Daniel Walker wrote: > > > > The problem is that poll returns POLLHUP when a socket isn't connected, > > then wine ignores the socket and it's events .. I realize this has been > > known for a some time(since linux 2.4), but why hasn't it been fix? > > Doesn't this effect a lot of non-blocking socket applications? > > Can you define the problem a bit more? Do you mean you get a POLLHUP > *while waiting* for connection? No, I mean that a socket is created using socket() then, say, ioctl() is run on it. ioctl() then ,through the wineserver, runs sock_reselect() then poll() returns POLLHUP in revents and the wineserver stop watching the socket .. Since most non-blocking applications run socket() then ioctl() I would think that several applications would be effected.. Daniel Walker

Aug. 17, 2001

Re: not-yet-connected sockets?

by Dan Kegel

Daniel Walker wrote: > > The problem is that poll returns POLLHUP when a socket isn't connected, > then wine ignores the socket and it's events .. I realize this has been > known for a some time(since linux 2.4), but why hasn't it been fix? > Doesn't this effect a lot of non-blocking socket applications? Can you define the problem a bit more? Do you mean you get a POLLHUP *while waiting* for connection? - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 17, 2001

not-yet-connected sockets?

by Daniel Walker

The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications? Daniel Walker

Aug. 17, 2001

Re: Does Wine's winhlp work?

by Bobby Bingham

On Thursday 16 August 2001 09:28 pm, you wrote: > Is Wine's WinHelp program supposed to work? By that I mean, if I invoke > that program with a Windows help file, is it supposed to be able to > display the contents of the help file as Window's winhelp.exe would? > > I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses > WinHelp format documents for some of its normal operation, and 2) I have > a WinHelp format file I'd dearly like to be able to access directly from > Wine. > > When I try to launch Wine's Winhelp, it brings up a window, but the > window is empty. If I go to File->Open and try to open a WinHelp file, I > get the same result. Is there some setup I'm missing? I get the same thing. I think Wine's winhelp isn't supposed to work yet. If you have access to the windows winhlp32.exe, it runs perfectly under wine (afaict better than in windows. I have a help file that creating a search index always crashes it under windows. Under wine it doesn't work, but it recovers without crashing). I may take a look at it if I can find the file format. Bobby Bingham

Aug. 17, 2001

Does Wine's winhlp work?

by David D. Hagood

Is Wine's WinHelp program supposed to work? By that I mean, if I invoke that program with a Windows help file, is it supposed to be able to display the contents of the help file as Window's winhelp.exe would? I ask because 1) I have a program (DeLorme's AAA MapNGo) that uses WinHelp format documents for some of its normal operation, and 2) I have a WinHelp format file I'd dearly like to be able to access directly from Wine. When I try to launch Wine's Winhelp, it brings up a window, but the window is empty. If I go to File->Open and try to open a WinHelp file, I get the same result. Is there some setup I'm missing?

Aug. 17, 2001

Re: Toolbar background error

by Gerard Patel

At 05:10 PM 16/08/2001 GMT, you wrote: >It's the client rectangle in the toolbar (I believe). I've handed the >issue back to Guy. I think that's a general issue, not specific to toolbars. We are seeing it for toolbars because it's a trick that is used mainly for toolbars. What happens I think is that some apps are not satisfied with the standard toolbar look. They want to have a bigger border around the buttons. That is not provided by the standard control, at least when these apps were written (maybe it is now, I am not following these matters closely). What these apps are doing is playing with WM_NCCALCSIZE to restrict the client rectangle to something smaller than what remains when the system clips the true nonclient area. In the case of one of my test apps, this is done by subclassing (the Wine code is never called). Since GetWindowRect returns only the width and the height of the client area, and is setting the origin to 0 - 0, the custom client area appears higher that it is to WM_ERASEBKGND and the lower part of the window is not painted (toolbar in the case of the app I see) Now, I don't know yet how should be done the erasing of this custom nonclient area :-/ Gerard

Aug. 17, 2001

Refcounting in SelectObject

by Uwe Bonnes

Hallo, we discussed this January 2001 with no final outcome. Some application (gcprevue version 9) does 080673a0:Call gdi32.SelectObject(000011d4,000011d8) ret=5f485bb1 080673a0:Ret gdi32.SelectObject() retval=00000044 ret=5f485bb1 080673a0:Call gdi32.DeleteObject(000011d8) ret=5f487813 080673a0:Ret gdi32.DeleteObject() retval=00000001 ret=5f487813 080673a0:Call gdi32.BitBlt(000011d4,00000000,00000000,0000008c,000001a7,000009d0,00000000,00000000,00cc0020) ret=0048d1e6 and gets an XErrorEvent and fails to Debugbreak. Starting theapplication with winedbg still gets this error, but DebugBreak isn't executed and the application proceeds. The Windows Api explicitly tells for DeleteObject: Return Value: ... If the specified handle is not valid or is currently selected into a device context, the return value is FALSE. Windows Internals tells about some elements in GDIOBJHDR in debugbuild of windows and has pseudo code for incrementing some refrence counters in SelectObject. Appended patch tries to implement this scheme. The original discussion dissolved into nothing after Andi saw the need for such refcounting, but also mentioned possible resource leakage. Appended code tries to clean up better by: - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount - Call DeleteObject in SelectObject when the RefCount of the released handle is 0x8000 - Decrementing the RefCount when a hBitmap is still selected into a DC when DeleteDC is called for that DC - Call DeleteObject in DeleteDC when RefCount is 0x8000 For some applications I tested, I always saw the delayed DeleteObject done after the refused DeleteObject in the first place. Is this approach better? Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/include/gdi.h =================================================================== RCS file: /home/wine/wine/include/gdi.h,v retrieving revision 1.50 diff -u -r1.50 gdi.h --- wine/include/gdi.h 2001/08/15 23:33:20 1.50 +++ wine/include/gdi.h 2001/08/16 23:23:12 @@ -45,6 +45,9 @@ HANDLE16 hNext; WORD wMagic; DWORD dwCount; + WORD wMetaList; + WORD wSelCount;/* only in debug builds of windows */ + WORD wObjTask;/* only in debug builds of windows */ } GDIOBJHDR; Index: wine/objects/gdiobj.c =================================================================== RCS file: /home/wine/wine/objects/gdiobj.c,v retrieving revision 1.54 diff -u -r1.54 gdiobj.c --- wine/objects/gdiobj.c 2001/08/16 19:13:52 1.54 +++ wine/objects/gdiobj.c 2001/08/16 23:23:13 @@ -374,6 +374,7 @@ obj->hNext = 0; obj->wMagic = magic|OBJECT_NOSYSTEM; obj->dwCount = ++count; + obj->wSelCount = 0; TRACE_SEC( *handle, "enter" ); return obj; @@ -545,6 +546,15 @@ GDI_ReleaseObj( obj ); return TRUE; } + + if(header->wSelCount) + { + TRACE("delayed for %04x because object in use, count %d\n", + obj,header->wSelCount); + header->wSelCount+=0x8000; /* mark for delete */ + GDI_ReleaseObj( obj ); + return FALSE; + } TRACE("%04x\n", obj ); @@ -814,12 +824,32 @@ HGDIOBJ WINAPI SelectObject( HDC hdc, HGDIOBJ handle ) { HGDIOBJ ret = 0; + GDIOBJHDR *header; + DC * dc = DC_GetDCUpdate( hdc ); if (!dc) return 0; TRACE("hdc=%04x %04x\n", hdc, handle ); if (dc->funcs->pSelectObject) ret = dc->funcs->pSelectObject( dc, handle ); GDI_ReleaseObj( hdc ); + if (ret) + { + if (!(header = GDI_GetObjPtr( handle, MAGIC_DONTCARE ))) return 0; + header->wSelCount++; + GDI_ReleaseObj(handle); + if (!(header = GDI_GetObjPtr( ret, MAGIC_DONTCARE ))) return 0; + if(header->wSelCount) + header->wSelCount--; + if(header->wSelCount == 0x8000) /* handle delayed DeleteObject*/ + { + header->wSelCount = 0; + GDI_ReleaseObj(ret); + TRACE("executing delayed DeleteObject for %04x\n",ret); + DeleteObject(ret); + } + else + GDI_ReleaseObj(ret); + } return ret; } Index: wine/objects/dc.c =================================================================== RCS file: /home/wine/wine/objects/dc.c,v retrieving revision 1.62 diff -u -r1.62 dc.c --- wine/objects/dc.c 2001/08/16 19:01:23 1.62 +++ wine/objects/dc.c 2001/08/16 23:23:14 @@ -766,6 +766,25 @@ if (dc->hGCClipRgn) DeleteObject( dc->hGCClipRgn ); if (dc->pAbortProc) THUNK_Free( (FARPROC)dc->pAbortProc ); if (dc->hookThunk) THUNK_Free( (FARPROC)dc->hookThunk ); + if (dc->hBitmap) + { + GDIOBJHDR * header; + if ((header = GDI_GetObjPtr( dc->hBitmap, MAGIC_DONTCARE ))) + { + if(header->wSelCount ) + header->wSelCount--; + if(header->wSelCount == 0x8000) + { + header->wSelCount = 0; + GDI_ReleaseObj(dc->hBitmap); + TRACE("executing delayed DeleteObject for %04x\n",dc->hBitmap); + DeleteObject(dc->hBitmap); + } + else + GDI_ReleaseObj(dc->hBitmap); + + } + } PATH_DestroyGdiPath(&dc->path); GDI_FreeObject( hdc, dc );

Aug. 17, 2001

Re: DC lock in CreateDIBitmap

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> CreateDIBitmap is called with the HDC lock hold, and when the >> (fColor) clause is true, CreateDCA() checks that the lock is not >> hold. A laymans approach to release hdc before CreateDCA() and reopen >> it afterwards resulted in this report asr startup, with no visual >> output: Alexandre> I don't think we should be using CreateDC at all in Alexandre> CreateDIBitmap. Could you try this? The patch works as expected. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by lawson_whitney＠juno.com

On Thu, 16 Aug 2001, Bill Medland wrote: > Ah. That might explain some of my problems (the "inline" of > perfect_graphics in graphics/x11drv/bitblt.c which is explicitly static and > possibly one with DPtoLP in windows/defwnd.c I am looking into just now). > > Be aware that the problems are still there in 2.96-85 so there's not much > point in updating from the RedHat site. I guess I am about to follow > advice and back down to 2.95. (Does anyone know; is it simply a matter of > using rpm to remove the new and install the old or am I about to start > tearing my hair out?) > > Bill > I built gcc-2.95.3 from source and patches, so I don't have the rpm installed, but nothing else I have installed from Mandrake 7.2 has wanted gcc, so I think you may not have too hard a time with it. Sorry, I can't work out how to do the requires/provides queries on an uninstalled package. I am a little casual with --nodeps and --force, too. I started with Slackware, so I like those options best of all rpm capabilities. 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/tagj.

Aug. 16, 2001

Re: DC lock in CreateDIBitmap

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause > is true, CreateDCA() checks that the lock is not hold. A laymans approach to > release hdc before CreateDCA() and reopen it afterwards resulted in this > report asr startup, with no visual output: I don't think we should be using CreateDC at all in CreateDIBitmap. Could you try this? Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.59 diff -u -r1.59 dib.c --- objects/dib.c 2001/08/15 23:33:20 1.59 +++ objects/dib.c 2001/08/16 21:08:12 @@ -875,12 +875,7 @@ /* Now create the bitmap */ - if (fColor) - { - HDC tmpdc = CreateDCA( "DISPLAY", NULL, NULL, NULL ); - handle = CreateCompatibleBitmap( tmpdc, width, height ); - DeleteDC( tmpdc ); - } + if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

Re: patch.py?id=997918367324549717828631

by lawson_whitney＠juno.com

On 16 Aug 2001, Alexandre Julliard wrote: > No, the CheckNotSysLevel calls were not done before. I added a few of > them in GDI to find potential locking bugs; seems pretty successful so > far ;-) > > I think this should fix your problem: > > Index: objects/dc.c Yes, that's lovely. Sorry to be so long to confirm it. The _CheckNotSysLevel touches winbase.h, so the mighty P-120 had to recompile nearly everything to put it back again. All better, thanks. 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/tagj.

Aug. 16, 2001

Re: [resend] Don't crash when CUPS is installed

by mm＠caldera.de

In article <997995321.1690.4.camel(a)bugg> you wrote: > Hi all, > Having CUPS installed and a printer in CUPS configured would crash an > application I'm looking at. The reason was that the printer would be > added with a NULL name. > - if (!AddPrinterA(NULL,2,(LPBYTE)&pinfo2a)) { > + if (!AddPrinterA(printers[i],2,(LPBYTE)&pinfo2a)) { This will just make the printer not added AT ALL, since there is the following code in AddPrinterW: if(pName != NULL) { ERR("pName = %s - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return 0; } Please do not apply. Ciao, Marcus

Aug. 16, 2001

DC lock in CreateDIBitmap

by Uwe Bonnes

Hallo, with the new GDI_CheckNotLock() stuff, some application (gcprevue 9) fails with > err:win32:_CheckNotSysLevel Holding lock 0x4079b9e8 level 3 Backtrace is: Backtrace: =>0 0x400e21d1 (_CheckNotSysLevel+0x51(lock=0x4079b9e8) [syslevel.c:152] in libntdll.so) (ebp=405c6090) 1 0x4078261c (GDI_CheckNotLock+0x1c [gdiobj.c:510] in libgdi32.so) (ebp=405c60a0) 2 0x4077823d (CreateDCA+0x1d(driver=0x407909d3, device=0x0, output=0x0, initData=0x0, s=0x0, s=0x0, s=0x407909d3) [dc.c:558] in libgdi32.so) (ebp=405c61e8) 3 0x4077bbc6 (CreateDIBitmap+0x166(hdc=0xdec, header=0x41eadb50, init=0x0, bits=0x0, data=0x41eadb50, coloruse=0x0) [dib.c:881] in libgdi32.so) (ebp=405c6218) 4 0x409f9479 (X11DRV_DIB_CreateDIBSection+0x359(dc=0x404225f4, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:3914] in libx11drv.so) (ebp=405c62a0) 5 0x4077bd75 (DIB_CreateDIBSection+0x65(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0, ovr_pitch=0x0) [dib.c:944] in libgdi32.so) (ebp=405c62d4) 6 0x4077bdd1 (CreateDIBSection+0x31(hdc=0xdec, bmi=0x41eadb50, usage=0x0, bits=0x411000d8, section=0x0, offset=0x0) [dib.c:961] in libgdi32.so) (ebp=405c6304) 7 0x00401fba (gcprevue.exe..text+0xfba in D:\cae\gcp9.0.0.8\gcprevue.exe) (ebp=ffffffff) CreateDIBitmap is called with the HDC lock hold, and when the (fColor) clause is true, CreateDCA() checks that the lock is not hold. A laymans approach to release hdc before CreateDCA() and reopen it afterwards resulted in this report asr startup, with no visual output: fixme:win32:PE_CreateModule Security directory ignored err:win32:_LeaveSysLevel (0x4079ba08, level 3): Invalid state: count 0 mutex (nil). err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=030f err:ntdll:RtlpWaitForCriticalSection section 0x4010fb88 "rtl.c: peb_lock" wait timed out, retrying (60 sec) fs=031f err:ntdll:RtlpWaitForCriticalSection section 0x4079ba08 "gdiobj.c: GDI_level" wait timed out, retrying (60 sec) fs=008f How to cure this problem? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by Mike Bond

On Thu, Aug 16, 2001 at 01:43:43PM +0000, Bill Medland wrote: > Ah. That might explain some of my problems (the "inline" of > perfect_graphics in graphics/x11drv/bitblt.c which is explicitly static and > possibly one with DPtoLP in windows/defwnd.c I am looking into just now). > > Be aware that the problems are still there in 2.96-85 so there's not much > point in updating from the RedHat site. I guess I am about to follow > advice and back down to 2.95. (Does anyone know; is it simply a matter of > using rpm to remove the new and install the old or am I about to start > tearing my hair out?) Darn, and here I just got through with upgrading and was rebuilding :(. -- TTFN MikeB

Aug. 16, 2001

Re: Stupid Winedbg question

by Dan Kegel

Bobby Bingham wrote: > > Ok, I feel like an idiot for having to ask this, but it's my first time > realing using the debugger. When wine starts the debugger on an exception, > it opens it up in another xterm. Is there an easy way to copy it's output? > The usual select and middle-click isn't working because it doesn't let me > select the text to begin with. I had the same problem, and I was highly annoyed at winedbg for not allowing cut and paste or any sort of session logging. - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 16, 2001

Re: Extra space at bottom of toolbar

by Guy L. Albertelli

-----Original Message----- From: Bobby Bingham <uhmmmm(a)ameritech.net> To: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, August 16, 2001 12:28 AM Subject: Extra space at bottom of toolbar >Has anyone else seen this... In WinZip 8.0 (I don't know about other >versions/software), there are about 6 extra pixels at the bottom of the >toolbar below the buttons. Does anyone know what's causing this? I can look >into it if I get some time, but I was wondering if anybody knew. > >Bobby Bingham > > The current CVS shows the following differences between the builtin control and the native one: 1. Button top-left corner is 2 pixels too high. 2. Button is 2 pixels too short. 3. Background bar is 2 pixels too wide. This gives the 6 pixels you noticed. Items 1 & 2 are definitely within the toolbar.c. Item 3 may be in either toolbar or rebar. I need to work on moving screenshots from Win to Linux for comparison. Guy

Aug. 16, 2001

Re: Protocol for adding FIXMEs

by Alexandre Julliard

"Bill Medland" <medbi01(a)accpac.com> writes: > However I am occasionally frustrated by the number of times I see the same > FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also > recognise from posts that these disconcert newbies whereas after a couple > of weeks one gets used to them. > > So maybe it is better to use FIXME comments where one knows that something > is wrong but it doesn't seem to matter. FIXME macros should be used in cases where we know something is wrong but we don't expect this part of the code to ever get used. This way if some app triggers the wrong code we can hear about it. It doesn't make sense to add FIXME output to parts of the code we know are going to be called, it just generates noise; a comment is much better in this case. > (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and > if it is TRUE then the lParam no longer points to a simple rectangle but to > a structure whose first element is a rectangle. Very little if any code > handles that case explicitly.) I don't think this specific case is a FIXME at all. Apps are allowed to ignore the extra information if they don't have any use for it. -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

Re: patch.py?id=997918367324549717828631

by Alexandre Julliard

lawson_whitney(a)juno.com writes: > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. No, the CheckNotSysLevel calls were not done before. I added a few of them in GDI to find potential locking bugs; seems pretty successful so far ;-) I think this should fix your problem: Index: objects/dc.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dc.c,v retrieving revision 1.61 diff -u -r1.61 dc.c --- objects/dc.c 2001/08/15 23:33:20 1.61 +++ objects/dc.c 2001/08/16 17:34:45 @@ -524,7 +524,9 @@ success=FALSE; } GDI_ReleaseObj( hdcs ); + GDI_ReleaseObj( hdc ); DeleteDC( hdcs ); + if (!(dc = DC_GetDCPtr( hdc ))) return FALSE; } GDI_ReleaseObj( hdc ); return success; -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

_CheckNotSysLevel (was: patch.py?id=997918367324549717828631)

by lawson_whitney＠juno.com

On Thu, 16 Aug 2001 whit(a)giftie.alien.org wrote: > Good day! > > I can't remember that I've ever seen the fixme that was here before, > but I'll check again when I send this. > Is that a new fixme? I reversed just this patch and there are more of this fixme than any other. Hope the backtrace I sent before is useful. 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/tagj.

Aug. 16, 2001

Re: Stupid Winedbg question

by James Hatheway

> Ok, I feel like an idiot for having to ask this, but it's my first time > realing using the debugger. When wine starts the debugger on an exception, > it opens it up in another xterm. Is there an easy way to copy it's output? > The usual select and middle-click isn't working because it doesn't let me > select the text to begin with. Hold the Shift key while selecting the text. Or, in your ~/.wine/user.reg change the [Software\Wine\WineDbg] UseXTerm key from 01 to 00. I find that is more useful so that all the output can be put into a file for later perusal. (ie. I usually run the debugger with: ./debugger/winedbg 2>&1 | tee output.log) -James -- James Hatheway james(a)macadamian.com ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. "Software solutions for leading ISVs and e-Business"

Aug. 16, 2001

Re: _CheckNotSysLevel Patch

by Bobby Bingham

On Thursday 16 August 2001 01:43 pm, you wrote: > Bobby Bingham <uhmmmm(a)ameritech.net> writes: > > winedbg winzip32 > > ... > > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > > Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in > > C:\Program Files\WinZip\WINZIP32.EXE) > > If you run under winedbg directly the CheckNotSysLevel breakpoints are > ignored, and it only stops at the program entry point; and the > backtrace there is useless. Please run it under wine and let it start > the debugger by itself when encountering the first CheckNotSysLevel, > then you should get a proper backtrace. Ok, let's try this again: wine winzip32 ... err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 In 32-bit mode. Wine-dbg>bt Backtrace: =>0 0x400db0a8 (_CheckNotSysLevel+0x58 in libntdll.so) (ebp=406167c4) 1 0x407e81cb (GDI32.DLL.RemoveFontResourceW+0xbcb in libgdi32.so) (ebp=406167d4) 2 0x407de49c (GDI32.DLL.CreateDCA+0x1c in libgdi32.so) (ebp=4061691c) 3 0x407e7a52 (GDI32.DLL.RemoveFontResourceW+0x452 in libgdi32.so) (ebp=4061698c) 4 0x407e8889 (GDI32.DLL.GetObjectW+0x69 in libgdi32.so) (ebp=406169a8) 5 0x4109da44 (WINEPS.DLL.EndDoc+0x6b4 in libwineps.so) (ebp=40616a90) 6 0x410a1867 (WINEPS.DLL.SelectObject+0xe7 in libwineps.so) (ebp=40616ab0) 7 0x407e8c76 (GDI32.DLL.SelectObject+0x66 in libgdi32.so) (ebp=40616ad0) 8 0x407deb70 (GDI32.DLL.DeleteDC+0x170 in libgdi32.so) (ebp=40616af4) 9 0x407c8a9c (GDI32.DLL.102+0xcc in libgdi32.so) (ebp=40616c40) 10 0x409e25eb (WINSPOOL.DRV.DocumentPropertiesA+0x7b in libwinspool.drv.so) (ebp=40616c78) 11 0x409e27ea (WINSPOOL.DRV.DocumentPropertiesW+0x10a in libwinspool.drv.so) (ebp=40616cac) 12 0x409e341c (WINSPOOL.DRV.AddPrinterW+0x32c in libwinspool.drv.so) (ebp=40616cf8) 13 0x409e388f (WINSPOOL.DRV.AddPrinterA+0xff in libwinspool.drv.so) (ebp=40616d24) 14 0x409e128d (WINSPOOL.DRV..data+0x128d in libwinspool.drv.so) (ebp=40616dd0) 15 0x409e1948 (WINSPOOL.DRV..data+0x1948 in libwinspool.drv.so) (ebp=40616e10) 16 0x409e7d6a (WINSPOOL.DRV.EntryPoint+0x2a in libwinspool.drv.so) (ebp=40616e1c) 17 0x4009084a (PE_InitDLL+0x6a in libntdll.so) (ebp=40616e40) 18 0x4008c5e9 (MODULE_InitDLL+0x79 [module.c] in libntdll.so) (ebp=40616e64) 19 0x4008c709 (MODULE_DllProcessAttach+0xb9 in libntdll.so) (ebp=40616e88) 20 0x4008c6e5 (MODULE_DllProcessAttach+0x95 in libntdll.so) (ebp=40616ea8) 21 0x4008c6e5 (MODULE_DllProcessAttach+0x95 in libntdll.so) (ebp=40616ec8) 22 0x400d6f1b (start_process+0xdb [process.c] in libntdll.so) (ebp=40616f30) 23 0x400dab46 (SYSDEPS_DoCallOnStack+0x86 in libntdll.so) (ebp=40616ff0) 24 0x400dab87 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff78c) 25 0x400dabfe (SYSDEPS_SwitchToThreadStack+0x5e in libntdll.so) (ebp=bffff7c8) 26 0x400d735c (PROCESS_InitWine+0x1dc in libntdll.so) (ebp=bffff7e0) 27 0x0804c16f (main+0x2f in wine) (ebp=bffff7f8) 28 0x0804c155 (main+0x15 in wine) (ebp=bffff818) 29 0x4028a520 (NTDLL.DLL.sqrt+0x3bd80 in libc.so.6) (ebp=bffff858) 30 0x08049021 (_start+0x21 in wine) (ebp=00000000) Wine-dbg>c ... Bobby Bingham

Aug. 16, 2001

Stupid Winedbg question

by Bobby Bingham

Ok, I feel like an idiot for having to ask this, but it's my first time realing using the debugger. When wine starts the debugger on an exception, it opens it up in another xterm. Is there an easy way to copy it's output? The usual select and middle-click isn't working because it doesn't let me select the text to begin with. Thanks in advance for your patience. Bobby Bingham

Aug. 16, 2001

Re: _CheckNotSysLevel Patch

by Alexandre Julliard

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > winedbg winzip32 > ... > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program > Files\WinZip\WINZIP32.EXE) If you run under winedbg directly the CheckNotSysLevel breakpoints are ignored, and it only stops at the program entry point; and the backtrace there is useless. Please run it under wine and let it start the debugger by itself when encountering the first CheckNotSysLevel, then you should get a proper backtrace. -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by Alexandre Julliard

Mike Bond <mbond(a)cox.rr.com> writes: > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. This patch should fix the build failure, though it doesn't explain why gcc doesn't inline such a simple function. Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /opt/cvs-commit/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.39 diff -u -r1.39 kernel32.spec --- dlls/kernel/kernel32.spec 2001/08/06 17:50:42 1.39 +++ dlls/kernel/kernel32.spec 2001/08/16 16:30:03 @@ -922,7 +922,9 @@ @ stub GetProcessPriorityBoost @ stdcall GetThreadPriorityBoost(long ptr) GetThreadPriorityBoost @ stdcall InterlockedCompareExchange (ptr long long) InterlockedCompareExchange +@ stdcall InterlockedCompareExchangePointer(ptr ptr ptr) InterlockedCompareExchangePointer @ stdcall InterlockedExchangeAdd (ptr long ) InterlockedExchangeAdd +@ stdcall InterlockedExchangePointer(ptr ptr) InterlockedExchangePointer @ stdcall IsProcessorFeaturePresent(long) IsProcessorFeaturePresent @ stdcall OpenWaitableTimerA(long long str) OpenWaitableTimerA @ stdcall OpenWaitableTimerW(long long wstr) OpenWaitableTimerW Index: scheduler/critsection.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/critsection.c,v retrieving revision 1.30 diff -u -r1.30 critsection.c --- scheduler/critsection.c 2001/08/09 21:21:13 1.30 +++ scheduler/critsection.c 2001/08/16 16:30:11 @@ -86,7 +86,7 @@ /*********************************************************************** * InterlockedCompareExchange (KERNEL32.@) */ -/* PVOID WINAPI InterlockedCompareExchange( PVOID *dest, PVOID xchg, PVOID compare ); */ +/* LONG WINAPI InterlockedCompareExchange( PLONG dest, LONG xchg, LONG compare ); */ __ASM_GLOBAL_FUNC(InterlockedCompareExchange, "movl 12(%esp),%eax\n\t" "movl 8(%esp),%ecx\n\t" @@ -95,10 +95,31 @@ "ret $12"); /*********************************************************************** + * InterlockedCompareExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedCompareExchangePointer( PVOID *dest, PVOID xchg, PVOID compare ); */ +__ASM_GLOBAL_FUNC(InterlockedCompareExchangePointer, + "movl 12(%esp),%eax\n\t" + "movl 8(%esp),%ecx\n\t" + "movl 4(%esp),%edx\n\t" + "lock; cmpxchgl %ecx,(%edx)\n\t" + "ret $12"); + +/*********************************************************************** * InterlockedExchange (KERNEL32.@) */ /* LONG WINAPI InterlockedExchange( PLONG dest, LONG val ); */ __ASM_GLOBAL_FUNC(InterlockedExchange, + "movl 8(%esp),%eax\n\t" + "movl 4(%esp),%edx\n\t" + "lock; xchgl %eax,(%edx)\n\t" + "ret $8"); + +/*********************************************************************** + * InterlockedExchangePointer (KERNEL32.@) + */ +/* PVOID WINAPI InterlockedExchangePointer( PVOID *dest, PVOID val ); */ +__ASM_GLOBAL_FUNC(InterlockedExchangePointer, "movl 8(%esp),%eax\n\t" "movl 4(%esp),%edx\n\t" "lock; xchgl %eax,(%edx)\n\t" -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

Re: Toolbar background error

by Duane Clark

Medland, Bill wrote: > I'll handle it. I have this horrible feeling its the compiler again > (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) > > Bill I don't think it is the compiler. I also am seeing the toolbar background not being painted on RH 6.2 with gcc 2.91.66. The problem started approximately the same time as it did for you, though I have not narrowed it down as accurately as you did. Duane

Aug. 16, 2001

Re: _CheckNotSysLevel Patch

by Bobby Bingham

On Thursday 16 August 2001 01:03 pm, you wrote: > Bobby Bingham <uhmmmm(a)ameritech.net> writes: > > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > > err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) > > Read the Wine Developers Guide on how to set up winedbg or another > > debugger > > > > if the debugger is set up, I can continue, and and it works just fine. > > Before the continue, could you please do a backtrace and mail it to > me? Thanks. winedbg winzip32 ... err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 Stopped on breakpoint 1 at 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program Files\WinZip\WINZIP32.EXE) In 32-bit mode. Wine-dbg>bt =>0 0x004677fa (WINZIP32.EXE.EntryPoint in C:\Program Files\WinZip\WINZIP32.EXE) (ebp=40616f30) 1 0x400dab46 (SYSDEPS_DoCallOnStack+0x86 in libntdll.so) (ebp=40616ff0) 2 0x400dab87 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff6bc) 3 0x400dabfe (SYSDEPS_SwitchToThreadStack+0x5e in libntdll.so) (ebp=bffff6f8) 4 0x400d735c (PROCESS_InitWine+0x1dc in libntdll.so) (ebp=bffff710) 5 0x0804c16f (main+0x2f in wine) (ebp=bffff728) 6 0x0804c155 (main+0x15 in wine) (ebp=bffff748) 7 0x4028a520 (NTDLL.DLL.sqrt+0x3bd80 in libc.so.6) (ebp=bffff788) 8 0x08049021 (_start+0x21 in wine) (ebp=00000000) Wine-dbg>c ... Hope this helps. Bobby Bingham

Aug. 16, 2001

Protocol for adding FIXMEs

by Bill Medland

What do people think? I seem to have a knack for finding things that are probably going to need fixing at some point but for which I do not have time or knowledge currently. My first temptation is to add a FIXME macro in the code directly. However I am occasionally frustrated by the number of times I see the same FIXME (e.g. the pthread_rwlock* and the "kill other threads" one). I also recognise from posts that these disconcert newbies whereas after a couple of weeks one gets used to them. So maybe it is better to use FIXME comments where one knows that something is wrong but it doesn't seem to matter. (For example the WM_NCCALCSIZE message uses wParam as a Boolean value and if it is TRUE then the lParam no longer points to a simple rectangle but to a structure whose first element is a rectangle. Very little if any code handles that case explicitly.) I know that the manual (wine-devel 8.0) says to add FIXMEs I am concerned that this could lead to ridiculously large traces that hide the important stuff (to say nothing of upsetting timing) Any other views? Bill

Aug. 16, 2001

Re: Toolbar background error

by Bill Medland

Duane Clark <dclark(a)akamail.com> wrote in article <3B7C024F.7080103(a)akamail.com>... > Medland, Bill wrote: > > I'll handle it. I have this horrible feeling its the compiler again > > (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) > > > > Bill > > I don't think it is the compiler. I also am seeing the toolbar > background not being painted on RH 6.2 with gcc 2.91.66. The problem > started approximately the same time as it did for you, though I have not > narrowed it down as accurately as you did. > > Duane > > > > > > It's the client rectangle in the toolbar (I believe). I've handed the issue back to Guy.

Aug. 16, 2001

Re: _CheckNotSysLevel Patch

by Alexandre Julliard

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 > err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) > Read the Wine Developers Guide on how to set up winedbg or another debugger > > if the debugger is set up, I can continue, and and it works just fine. Before the continue, could you please do a backtrace and mail it to me? Thanks. -- Alexandre Julliard julliard(a)winehq.com

Aug. 16, 2001

patch.py?id=997918367324549717828631

by lawson_whitney＠juno.com

Good day! I guess native riched32.dll does something nasty to provoke the new DbgBreakPoint in _CheckNotSysLevel. Builtin riched32 doesn't, of course, but then the app won't start. I can't remember that I've ever seen the fixme that was here before, but I'll check again when I send this. I've attached a backtrace. I'd appreciate some guidance on what else might be useful, or maybe a pointer to some doco on critical sections in Wine, even it is in .sgml, .c or .h in case I have to debug it myself. Regards, Lawson

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by Dan Kegel

Mike Bond wrote: > > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. > > I'm not sure what the correct solution would be, other than using the > older function call method for this version of gcc. Perhaps I'm just > missing some variant on the use of inline? There was a thread on 'static inline' vs. 'extern inline' on linux-kernel recently: http://marc.theaimsgroup.com/?l=linux-kernel&m=99679337730171&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=99617009115578&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=98594516710242&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=98590101912992&w=2 You might try replacing 'extern' with 'static' and see what happens. Also replacing 'inline' with '__inline__' might be needed for old gcc's, maybe? - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by hch＠caldera.de

In article <20010816102721.A10210(a)cox.rr.com> you wrote: > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. > > I'm not sure what the correct solution would be, other than using the > older function call method for this version of gcc. Perhaps I'm just > missing some variant on the use of inline? Try 'static inline' - it's even defined in C99. Christoph -- Whip me. Beat me. Make me maintain AIX.

Aug. 16, 2001

Problems building with extern inline functions in winebase.h

by Mike Bond

A couple days ago a number of inline functions were put into winebase.h. Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently this version of gcc thinks that because there is an extern prefixing the inline, even though the function does in fact have a body, that the function really is external. Removing the extern, just having inline as one would do in C++, does not appear to work correctly either, and causes the function to appear as a exported symbol in all the object files that header gets included with, thus resulting in multiple definitions. I'm not sure what the correct solution would be, other than using the older function call method for this version of gcc. Perhaps I'm just missing some variant on the use of inline? -- TTFN MikeB

Aug. 16, 2001

RE: Toolbar background error

by Medland, Bill

I'll handle it. I have this horrible feeling its the compiler again (2.96-85; RedHat 7.1). (It seems to be a side-effect of DPtoLP!!??) Bill > -----Original Message----- > From: Guy L. Albertelli [SMTP:galberte(a)neo.lrun.com] > Sent: Wednesday, August 15, 2001 7:30 PM > To: Bill Medland > Cc: Wine Devel > Subject: Re: Toolbar background error > > > -----Original Message----- > From: Bill Medland <medbi01(a)accpac.com> > To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> > Date: Wednesday, August 15, 2001 4:39 PM > Subject: Re: Toolbar background error > > > >> > >> > >In case you haven't found it yet it is in windows/defwnd.c; the change > made > >between 1.57 and 1.58. Are you going to handle it? > > > >Bill > > > > > Bill, > > Great job in tracking it down. I probably won't get to having time till > Friday evening. If you see the problem and know the fix, by all means go > and > fix it. Otherwise I will look into this Friday. > > Thanks again, > Guy

Aug. 16, 2001

Re: Wine call graph; wineserver; the "big picture"

by Huw D M Davies

On Wed, Aug 15, 2001 at 10:02:58PM -0500, Jeremy White wrote: > > > > Ove Kaven of TransGaming is working on out-of-process COM issues right > > now in the hopes of getting InstallShield V6 installers working. Have > > a look back at the recent wine-devel archive for more information. If > > you want to help, one thing that's needed immediately is a reader for > > older format Typelibs. This is needed so that we can create an appropriate > > 'proxy' object on the client and 'stub' on the server that can marshall > > the data for the functions that are getting called. > > Unless I've totally misunderstood Huw, he's well on his way to having > at least one older Typelib read. He's out right now at a wedding, but > will hopefully be able to speak more coherently for himself later. That's correct. I should be able read at least basic SLTG by the end of next week. Are there other older formats out there? [Out of interest, does anyone know SLTG stands for?] Huw.

Aug. 16, 2001

Re: Problems building with extern inline functions in winebase.h

by Bill Medland

Mike Bond <mbond(a)cox.rr.com> wrote in article <20010816102721.A10210(a)cox.rr.com>... > A couple days ago a number of inline functions were put into winebase.h. > Since then I have been unable to build, using gcc 2.96-81 (RedHat). Apparently > this version of gcc thinks that because there is an extern prefixing the > inline, even though the function does in fact have a body, that the > function really is external. Removing the extern, just having inline as > one would do in C++, does not appear to work correctly either, and causes > the function to appear as a exported symbol in all the object files that > header gets included with, thus resulting in multiple definitions. > > I'm not sure what the correct solution would be, other than using the > older function call method for this version of gcc. Perhaps I'm just > missing some variant on the use of inline? > > -- > TTFN > MikeB > > > > Ah. That might explain some of my problems (the "inline" of perfect_graphics in graphics/x11drv/bitblt.c which is explicitly static and possibly one with DPtoLP in windows/defwnd.c I am looking into just now). Be aware that the problems are still there in 2.96-85 so there's not much point in updating from the RedHat site. I guess I am about to follow advice and back down to 2.95. (Does anyone know; is it simply a matter of using rpm to remove the new and install the old or am I about to start tearing my hair out?) Bill

Aug. 16, 2001

Re: Extra space at bottom of toolbar

by Bill Medland

Bobby Bingham <uhmmmm(a)ameritech.net> wrote in article <20010816042521.OIYP24527.mailhost.col.ameritech.net(a)there>... > Has anyone else seen this... In WinZip 8.0 (I don't know about other > versions/software), there are about 6 extra pixels at the bottom of the > toolbar below the buttons. Does anyone know what's causing this? I can look > into it if I get some time, but I was wondering if anybody knew. > > Bobby Bingham > > > > I spotted something similar. Based on Microsoft's RowList sample from their MSDN samples on my system the toolbar buttons are displayed two pixels down with the result that the bottom border of the button is not displayed or is overwritten by the toolbar background. (I don't know what is causing it) Bill

Aug. 16, 2001

_CheckNotSysLevel Patch

by Bobby Bingham

Ever since _CheckNotSysLevel was implemented in the CVS yesterday, I can't run any programs if the debugger isn't set up. I get: ... err:win32:_CheckNotSysLevel Holding lock 0x40800fe8 level 3 err:seh:start_debugger Couldn't start debugger (winedbg 134640360 52) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger if the debugger is set up, I can continue, and and it works just fine. Somehow I don't recall windows not running programs without setting up the debugger :-) Bobby Bingham

Aug. 16, 2001

Extra space at bottom of toolbar

by Bobby Bingham

Has anyone else seen this... In WinZip 8.0 (I don't know about other versions/software), there are about 6 extra pixels at the bottom of the toolbar below the buttons. Does anyone know what's causing this? I can look into it if I get some time, but I was wondering if anybody knew. Bobby Bingham

Aug. 16, 2001

Re: Wine call graph; wineserver; the "big picture"

by Daniel Walker

Gavriel State wrote: > > Phillip Schmitz wrote: > > > > [I mistakenly posted this to comp.emulators.ms-windows.wine / > > wine-users rather than here. Thanks to eric pouech for his reply > > there. Sorry if you've already seen this there] > > > > Hi, > > > > I've been lurking for a while now with a view to starting work on wine > > - specifically COM and DCOM. I know some people have started some work > > and there might be some patent issues with COM at least - so maybe > > DCOM is a better bet (I had the possibly naive idea of implementing > > COM via DCOM - it would be almost transparent, slower but less > > "dangerous"). > > Ove Kaven of TransGaming is working on out-of-process COM issues right > now in the hopes of getting InstallShield V6 installers working. Have > a look back at the recent wine-devel archive for more information. If > you want to help, one thing that's needed immediately is a reader for > older format Typelibs. This is needed so that we can create an appropriate > 'proxy' object on the client and 'stub' on the server that can marshall > the data for the functions that are getting called. > > Check out some of the previous discussions on Wine-devel to learn more > about this. Any help you can render on that front would be great! > If anyone doesn't know a good reference to look at is the FreeDCE project. I think I read another post saying that Microsoft based their COM/DCOM stuff on DCE . http://freedce.sourceforge.net/ They have a (typelib) idl compiler too, maybe the "old" MS format is similar to the FreeDCE format.. Daniel Walker

Aug. 16, 2001

Re: Wine call graph; wineserver; the "big picture"

by Jeremy White

> > Ove Kaven of TransGaming is working on out-of-process COM issues right > now in the hopes of getting InstallShield V6 installers working. Have > a look back at the recent wine-devel archive for more information. If > you want to help, one thing that's needed immediately is a reader for > older format Typelibs. This is needed so that we can create an appropriate > 'proxy' object on the client and 'stub' on the server that can marshall > the data for the functions that are getting called. Unless I've totally misunderstood Huw, he's well on his way to having at least one older Typelib read. He's out right now at a wedding, but will hopefully be able to speak more coherently for himself later. Jer

Aug. 16, 2001

Re: Wine call graph; wineserver; the "big picture"

by Gavriel State

Phillip Schmitz wrote: > > [I mistakenly posted this to comp.emulators.ms-windows.wine / > wine-users rather than here. Thanks to eric pouech for his reply > there. Sorry if you've already seen this there] > > Hi, > > I've been lurking for a while now with a view to starting work on wine > - specifically COM and DCOM. I know some people have started some work > and there might be some patent issues with COM at least - so maybe > DCOM is a better bet (I had the possibly naive idea of implementing > COM via DCOM - it would be almost transparent, slower but less > "dangerous"). Ove Kaven of TransGaming is working on out-of-process COM issues right now in the hopes of getting InstallShield V6 installers working. Have a look back at the recent wine-devel archive for more information. If you want to help, one thing that's needed immediately is a reader for older format Typelibs. This is needed so that we can create an appropriate 'proxy' object on the client and 'stub' on the server that can marshall the data for the functions that are getting called. Check out some of the previous discussions on Wine-devel to learn more about this. Any help you can render on that front would be great! -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Aug. 16, 2001

Re: Toolbar background error

by Guy L. Albertelli

-----Original Message----- From: Bill Medland <medbi01(a)accpac.com> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Wednesday, August 15, 2001 4:39 PM Subject: Re: Toolbar background error >> >> >In case you haven't found it yet it is in windows/defwnd.c; the change made >between 1.57 and 1.58. Are you going to handle it? > >Bill > Bill, Great job in tracking it down. I probably won't get to having time till Friday evening. If you see the problem and know the fix, by all means go and fix it. Otherwise I will look into this Friday. Thanks again, Guy

Aug. 16, 2001