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

Re: New breakages

by gerard patel

At 05:46 PM 02/05/2001 -0700, you wrote: >could you please give this a try? <snip> Excellent, this is fixing the painting problems. Now, all I have to do is to find the tooltip bug, the Eudora combo display problem and the 2 remaining crashes and my toy test suite will be in as good shape as before :-) Gerard

May 3, 2001

Re: Wine and NetBSD

by Bang Jun-Young

Francois Gouget wrote: > Maybe you already fixed that but... > In configure.in there's a NetBSD section that seems incomplete > wrt. how one links a builtin dll. And this might be related to your > problem. See thos lines: > > if test "$ac_cv_c_dll_netbsd" = "yes" > then > LDSHARED="\$(CC) -Wl,-Bshareable,-Bforcearchive" > LDDLLFLAGS="" #FIXME <--- doesn't look good > fi Starting from release 1.5, NetBSD has completely switched its native binary format to ELF, so the current gcc(egcs)/binutils toolchain is almost same as those being used on Linux or FreeBSD. What you pointed out is relevant to 1.4 and earlier versions. I'm not sure Wine is able to be compiled on such releases. Anyway, we need to correct some configure messages to have clearer meanings (i.e. Linux dll -> (Linux-style) ELF dll or Linux/FreeBSD/NetBSD dll, NetBSD dll -> NetBSD a.out dll, etc.). Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 3, 2001

Re: Wine and NetBSD

by Bang Jun-Young

eric pouech wrote: > No, a native program doesn't need a .spec file. However, it rather seems > that the native modules don't get registered, hence the error. > you should check that __wine_dll_register gets actually called (I bet > it isn't). And, in your case the .spec for the emulator (wine.spec) is > not registered, hence the error. > It's likely to be a loader issue. Look in the .spec.c files with the > __asm__dummy_dll_init and __wine_spec_wine_init functions. The first one > is put in the .init section so that the loader executes every function > from this section when the module (wine in this case) is loaded into > memory. It's very likely this doesn't happen in your case. Thanks for giving the explaination(!). I'm going to examine the code soon. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

May 3, 2001

Re: New breakages

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > [patch snipped] > > I got the following results : > > Word viewer 32 bits, 16 bits, Lotus Notes (AFAICT), Statview, QuattroPro 1, and a > few old 16 bits apps I have display more or less as well as before (some crud for WW32 > that was not before, though :-/) Thanks a lot for tracking this down; I think I found the real bug, could you please give this a try? Index: windows/dce.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/dce.c,v retrieving revision 1.53 diff -u -r1.53 dce.c --- windows/dce.c 2001/04/24 23:28:52 1.53 +++ windows/dce.c 2001/05/03 00:37:31 @@ -671,7 +671,12 @@ * means that we have to recompute the visible region. */ if( dce->DCXflags & DCX_DCEBUSY ) + { + /* Dirty bit has been cleared by caller, set it again so that + * pGetDC recomputes the update region. */ + SetHookFlags16( dce->hDC, DCHF_INVALIDATEVISRGN ); USER_Driver.pGetDC( dce->hwndCurrent, dce->hDC, dce->hClipRgn, dce->DCXflags ); + } else /* non-fatal but shouldn't happen */ WARN("DC is not in use!\n"); break; -- Alexandre Julliard julliard(a)winehq.com

May 3, 2001

Re: New breakages

by gerard patel

At 02:30 PM 25/04/2001 +0200, I wrote: >At 09:30 AM 25/04/2001 +0200, I wrote: > >Also several apps are not erasing parts of the screen : among others the word viewer 97 >(freeware downloadable). A few other strange crashes. Still talking to myself... I feel I'm soon one of these sad cases talking alone in the street ;-) I have found one way to fix a lot of the ugliness that the evil patch of 24 april has done; by doing : --- dce.c.orig Thu May 3 00:02:35 2001 +++ dce.c Wed May 2 23:49:19 2001 @@ -551,7 +551,7 @@ dce->DCXflags &= ~DCX_DCEDIRTY; hdc = dce->hDC; - if (bUpdateVisRgn) SetHookFlags16( hdc, DCHF_INVALIDATEVISRGN ); /* force update */ + if (bUpdateVisRgn) flags |= 0x8000; if (!USER_Driver.pGetDC( hwnd, hdc, hrgnClip, flags )) hdc = 0; and --- winpos.c.orig Wed Apr 25 01:28:52 2001 +++ winpos.c Wed May 2 23:49:01 2001 @@ -355,7 +355,8 @@ TSXSetClipOrigin( display, physDev->gc, dc->DCOrgX, dc->DCOrgY ); #endif - updateVisRgn = (dc->flags & DC_DIRTY) != 0; + updateVisRgn = (flags & 0x8000) != 0; + dc->flags &= ~DC_DIRTY; GDI_ReleaseObj( hdc ); if (updateVisRgn) I got the following results : Word viewer 32 bits, 16 bits, Lotus Notes (AFAICT), Statview, QuattroPro 1, and a few old 16 bits apps I have display more or less as well as before (some crud for WW32 that was not before, though :-/) Doing things in such a way is more conforming to the way they were done before - and it seems more simple that the SetHookFlags trick IMHO ;-) Gerard

May 2, 2001

Re: Script to get committed patches

by eric pouech

> Documented ? Oops, I missed completely this part. > This weekend I have browsed the wonderful Wine user manual for the > first time , since I have now a computer with a working db2html - now > I know what *is* the Wine user manual ;-) > I have not seen where this info is hiding. well, it has been only published on the winehq administrators list... sorry about that. > Btw, your successor has problems to get in the game; I noticed on LinuxToday > that the last Kernel Cousin Wine was showing a 'slow week' - the week > where Marcus posted CUPS support - IMHO the more interesting patch > since months for all non-games apps. He is not following wine-patches and > wine-cvs it seems :-/ well, as things go, Brian is only browsing the wine-devel list from winehq, but list of patches hasn't been moved back in. a matter of a few issues I think A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

May 2, 2001

Re: FreeLibrary() library freeing

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > If you remember, there are glibc problems with dlclose. Alexandre Julliard > said that it was not a problem because FreeLibrary was not doing anything. > So I guess that people with 'old' glibc could have now new crashes. Actually we still cannot dlclose builtin libraries; the change I made is to free memory used by PE dlls. Freeing builtins properly will require dll separation to be completed first. And once this is done we will no longer rely on glibc dlclose reference counting so the bug shouldn't impact us. -- Alexandre Julliard julliard(a)winehq.com

May 2, 2001

Re: Wine and NetBSD

by Francois Gouget

On Tue, 1 May 2001, Bang Jun-Young wrote: > Hi, > > For the last couple of weeks I spent some time doing porting Wine to > NetBSD (there used to be a port but was too out of date). After applying > patches my own, it has been successfully compiled and started running. > > The most serious problem occurs, however, whenever I try to run a > Windows binary with it: > > $ wine c:\\windows\\sol.exe > No built-in EXE module loaded! Did you create a .spec file? > > Obviously sol.exe doesn't need a .spec file to run. When/Why do I get > such an error? Maybe you already fixed that but... In configure.in there's a NetBSD section that seems incomplete wrt. how one links a builtin dll. And this might be related to your problem. See thos lines: if test "$ac_cv_c_dll_netbsd" = "yes" then LDSHARED="\$(CC) -Wl,-Bshareable,-Bforcearchive" LDDLLFLAGS="" #FIXME <--- doesn't look good fi -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Resume: design before you implement.

May 2, 2001

Re: FreeLibrary() library freeing

by Andreas Mohr

On Wed, May 02, 2001 at 10:09:24AM +0200, gerard patel wrote: > At 11:23 PM 01/05/2001 +0200, you wrote: > > <snip> > >I believe the potential problems that this can cause are way more important > >than some claims that "there are some problems with library freeing". > >I've had that FreeLibrary() #if hack removed for a long time, > >and I haven't see any adverse effects (not that it's too easy to spot > >and attribute to this problem probably, though). > > If you remember, there are glibc problems with dlclose. Alexandre Julliard > said that it was not a problem because FreeLibrary was not doing anything. > So I guess that people with 'old' glibc could have now new crashes. Well, do you really think we should severely punish people with new versions in order to make it work on rather outdated versions ? ;-)) (yes, people with old versions still have the same "unfreed handle" punishment, of course, but that's not the point, is it ?) And you could always state that people who are using Linux should be accustomed to heavy upgrading anyway... (ok, I know, that one's a bit risky) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

May 2, 2001

Re: FreeLibrary() library freeing

by Andreas Mohr

On Tue, May 01, 2001 at 06:19:26PM -0700, Alexandre Julliard wrote: > Andreas Mohr <a.mohr(a)mailto.de> writes: > > > I for one would truly like to see it fixed ASAP. > > > > If FreeLibrary() has a problem, then we need to fix it. > > Running away from the problem by implementing strange hacks does no good > > to anybody. > > Agreed; I have uncommented the VirtualFree, and you are hereby > volunteered to track down and fix any crash caused by this ;-) Hey, I got that ! This is the direct revenge for my lock level objection sentence ! Grmbl ! ;-) *sigh* back to fixing library problems, then... P.S.: I did tell that I couldn't find any adverse effects, did I ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

May 2, 2001