- Wine-Devel - list.winehq.org

Packaging Questions, New Debian Package, Packagers Guide
by Scott Ritchie Nov. 24, 2004

Nov. 24, 2004

The Debian packages have gotten rather out of date, and it looks like Ove's not going to be making them any more. I took the initiative and decided to try making one myself. I'm polishing off a new Debian package now. Some major things I noticed: 1) There were a lot of old hacks in the package that are probably no longer necessary, due to advancements in wine like wineprefixcreate and such. There was also the remenants of a very old problem with compiling using flex (which I remember experiencing the old days) in the form of a special exception for installing newer flex packages. 2) Very old packages like winesetuptk should now be officially obsoleted by making them conflicted and replaced. I also did the same to the libwine-* packages that weren't doing anything but making documentation folders, like libwine-alsa. 3) Making my package looks to be a lot simpler than what's implied in the (now year out of date) package makers guide. I found that documentation quite useless (and didn't even find it until I was about half way done anyway). Again, this is probably due to advancements in wine itself. 4) What I didn't find is a standard list of packages that aren't strictly required for wine (like libxt-dev and flex), but that wine can benefit from. A good example would be the alsa development files. These are all things that should be included in the build dependencies for the package. So far, my list of build dependant packages is the following: flex, bison, libx11-dev, libasound2-dev, libxt-dev, libicu28-dev However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine? Now, this leads to the question: is it worth even having a package maintainers guide? If so, who wants to update it? Thanks, Scott Ritchie

8 20

Fwd: Re: [Wine]DC++ crashes with current CVS wine
by Pavel Troller Nov. 24, 2004

Nov. 24, 2004

Hi! I've sent the message below to wine-users mailing list and nobody has replied until now. So I subscribed do wine-devel and I'm posting the message here. Of course I cannot distinguish whether this problem is important enough to be fixed, but I think it's some problem with wine dlls so it can help other apps too.. With regards, Pavel Troller ----- Forwarded message from Pavel Troller <patrol(a)sinus.cz> ----- > Hi! > I have a problem, that DC++ client now crashes in wine. The problem is that it > crashes using its own exception handler, from the wine's point of view the app > is running OK. The client simply pops up a dialog box saying that it just > crashed and the debug info is placed in a file called exceptioninfo.txt. OK, the > file is really there and it really shows something important: > > Code: c0000005 > Version: 0.4034 > Major: 4 > Minor: 10 > Build: 67766446 > SP: 0 > Type: 0 > Time: 2004-11-21 08:09:57 > TTH: EJEUEI5NYOW2OQOXRJC7OHZ2ZUSLA5JF6IPD6TI > > c:\documents\vcprojects\dcplusplus\windows\transferview.cpp(195): ? > c:\documents\vcprojects\dcplusplus\windows\transferview.h(50): ? > c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3017): ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > user32!0x666ED284: ? > user32!0x666EE099: ? > user32!0x666EE2D5: ? > comctl32!0x57758097: ? > comctl32!0x5775D2C5: ? > comctl32!0x5775DFAE: ? > comctl32!0x5775E518: ? > comctl32!0x577666D7: ? > comctl32!0x577675C7: ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3020): ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > user32!0x666A3996: ? > c:\documents\vcprojects\include\wtl-7.5.4196\atlapp.h(499): ? > c:\documents\vcprojects\dcplusplus\windows\main.cpp(270): ? > 0x1F83D6C8: ? > > Because user32 and comctl32 are both mentioned in the backtrace, I tried to > switch them to native, but the program then crashed in a much worse way, > ending at a wine-dbg> prompt. > This exception info is shown, when win98 is emulated. Normally I'm emulating > nt40, in which case the backtrace is missing but the crash is looking very > similar from the user's point of view. > No important information (like unimplemented call etc.) is shown in the > wine's stdout/stderr. > Is there a developer which can help with this problem ? > With regards, Pavel Troller Hi! I have a lot of news in this case: I've downloaded sources for DC++ unstable and looked onto them to see in which place the program crashes. I've found that it occurs when the download/upload progress bar is about to be drawn. I've also found that progress bar drawing can be disabled in advanced setting (oh yes, source is the best user's manual You can have :-) ). I did so and DC++ started to work for me. I think that it is a good starting point for a wine developer to find, what's happening there, it should be easy to find when the source code which exhibits the bug is available and exact location of bug invocation is known. Because I know windows at a zero level, I cannot help with this, but I hope that others can, and fixing this bug may help other apps too (and, even in DC++, the bars are a nice eye-candy :-) ). Should I post this message to wine-devel, or is it enough to post it here, in wine-users ? With regards, Pavel Troller ----- End forwarded message -----

1 0

Re: Implement OleDuplicateData
by Dmitry Timoshkov Nov. 24, 2004

Nov. 24, 2004

"Robert Shearman" <rob(a)codeweavers.com> wrote: > + logpalette->palVersion = 1; /* FIXME: what should this be? */ All Microsoft and other samples I've seen initialize this filed to 0x300. -- Dmitry.

1 0

Re: Problem roundup
by Ivan Leo Puoti Nov. 23, 2004

Nov. 23, 2004

> So perhaps it would be better to build the RPMs against "pure" installs of > each distro, from the CDs? As i think nobody wants buggy systems, this will mean using --force to install RPMs of old headers. I've never heard of such an update breaking my RPMs so I won't do any such thing without considerable proof that it is really necessary and there is no better option. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

Re: Version Resources
by Dan Kegel Nov. 23, 2004

Nov. 23, 2004

Tom wrote: > I hope this patch looks better. :) > If anything is incorrect just let me know. FYI, please don't use # in patch filenames. Sometimes that's a comment character, and it gives us shell programmers the willies. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

System colors
by Kevin Koltzau Nov. 23, 2004

Nov. 23, 2004

CreateBrushIndirect under Wine currently returns stock brushes if the brush requested matches the color. In gdi/brush.c the following comment is made: /* If a solid brush is created in a color matching one of the * stock brushes, native returns the stock object (GDI heap * optimisation). Some apps rely on this as they otherwise * would leak their brushes. */ However under both Windows 95 and Windows XP this does not seem to be the case. Under Windows, the following holds true, but fails under Wine GetStockObject(BLACK_BRUSH) != CreateSolidBrush(RGB(0,0,0)) This issue currently breaks applications making calls to SetSysColors as stock brushes are deleted as the new colors are added. Does anyone know why this was setup in this way? Or which version of Windows that exhibits the behavior mentioned in the comment? -Kevin

2 1

Problems with mailing list
by Robert van Herk Nov. 23, 2004

Nov. 23, 2004

Hi all, Last month I moved, as did my ip address. Since then, I don't seem to get any messages from the wine devel mailing list, although I am still subscribed. I don't know whom to send this to, but can somebody (the admin of the list) please try to find out what is the problem? Thanx, Robert

2 1

Handles in GDI
by lats Nov. 23, 2004

Nov. 23, 2004

I have been trying to track a problem in gdiobj.c where I had a handle of 0x107e. In GDI_GetObjPtr the handle & 2 is said to indicate a GDI Heap handle. From everything else I have read, that bit is supposed to indicate a Moveable handle. Is there something special about GDI handles that I should know about? Jeff

1 0

Configure missing a step
by Scott Ritchie Nov. 23, 2004

Nov. 23, 2004

I managed to get past configure and then have a compile error due to a missing header file: intrinsic.h Configure should be checking for this file, like it checks for flex and bison and such. The package I needed to install was libxt-dev I'm on Ubuntu at the moment, but this should be true for all Debian systems. Could someone else clean this up? I'm scared to touch configure. -Scott Ritchie

1 0

Re: syscolors: do not delete stock brushes
by Kevin Koltzau Nov. 23, 2004

Nov. 23, 2004

Please do not apply this patch On Thursday 11 November 2004 11:38 pm, Kevin Koltzau wrote: > This is a bit of a bad hack, but very bad things happen when a stock brush is deleted > > Changelog > Prevent deletion of stock brushes when system colors change >

1 0