September 2003 - Wine-Devel

Re: PATCH: stop crashes in desktop mode

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Do we really want a dependency on Xnest, which is usually not installed > by default on most distributions (and is quite large i think)? I don't think that's a problem. If you want desktop mode you can install Xnest. > IIRC it does not support Xrender at all. Yes that would need to be fixed. > The other way would be to extend managed mode so we don't need to use > Desktop mode for InstallShield (which is the primary offender). I find > simply setting the default mode to managed makes most of them work but > of course that probably breaks some other apps. What is the reason for > unmanaged to be the default (in is_window_managed)? The default is managed mode, and has been for a long time now. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2003

Re: Start menu (especially for Alexandre Julliard)

by Francois Gouget

On Thu, 2 Oct 2003, Mike McCormack wrote: > > > Robert van Herk wrote: > > Mike McCormack wrote: > > > >> Ideally, you'd want to write a Gnome VFS module that calls shell32.dll > >> and queries the shell name space to generate the start menu the same > >> way Windows does. You need to use some RPC mechanism to do that, as > >> you can't link wine dlls directly into your gnome vfs module. However this approach would only work with Gnome. Then you'd have to do something else for KDE. And then you would still not integrate correctly with Mandrake's special KDE and Gnome menus, or with SuSE's special KDE and Gnome menus, or the Debian based menuing systems, or the menus of WindowMaker, BlackBox, Enlightenment, fvwm, etc. etc. etc. <rant> The Linux desktop menus are a total mess. FreeDesktop came up with a broken standard (vfolders) to 'unify' KDE and Gnome (which were already pretty similar and relatively easy to work with). But what we need is a truly standard way to create menus for all desktop environments on any Linux distribution. Something like the Debian menuing system, maybe with improved support for internationalization and other bells and whistles. </rant> -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Sept. 30, 2003

Re: Wineconf 2004, otherwise known as...

by Keith Matthews

On Tue, 30 Sep 2003 13:40:50 +0900 "Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > "Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > > > I have always wanted to see the Russian Winter so I guess > > St. Paul in January is good practice. > > Well, "the Russian Winter" is a common exaggeration, like > a stray bear in every russian town, a hidden communist in > each russian, and many others :-) > Too may people been watching Dr Zhivago !!

Sept. 30, 2003

Re: PATCH: server/trace.c cleanup (RETRY)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > [ 2nd attempt. I really don't see any viable alternative to these > casts; keeping the status quo certainly seems bad. ] That code is generated, there's no point in fixing it. You need to change tools/make_requests. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2003

Re: Wineconf 2004, otherwise known as...

by Marcus Meissner

On Mon, Sep 29, 2003 at 11:33:00AM +0300, Boaz Harrosh wrote: > Just a crazy taught: > What about a twin Wineconf, one in north-America one in Europe taking > place at the same time with live tele-conference. (Europe cameras on me) > I am sure it will be good for publicity, Journalists like that stuff. > But seriously how many are European (proximity) and how many are north > American. Do we have any kind of counts. I don't think this is a fruitful idea. I witnessed teleconferencing in my study times and it does not have the feeling and usefulness of a real conference. Ciao, Marcus

Sept. 30, 2003

Re: Updated winetests.exe

by Dimitrie O. Paun

On September 29, 2003 05:31 pm, Ferenc Wagner wrote: > I did not like this idea either, but decided to go with it > in the end. First, to generate summaries I have to > correlate files anyway, which *is* problematic already, and > having a master file could only make it simpler and also > make the cause more obvious if some inconsistency is found. > Second, we want to include build failure reports, which can > be lengthy (eg. compiler logs), and do not seem to belong to > the test results. For an example, see how the dsound test > build failure is noted on the page. The summary line could > also easily be customized. OK, this can work too, of course, if you feel you can deal with it, I'm easy. If we go down that path, I have a few suggestions: -- this master file should be emailed to wine-tests just like the regular tests. The processing script should recognize it as such, and process it accordingly. -- we should include in the master file and the test output some sort of unique identifier (a MD5 sum of sorts?) so we make sure we correlate the test output with the correct master file. -- you have to be able to deal (how?) with tests results that arrive before the master file. -- a simple to generate format would be: KEY:<the uuid> *** <dll> (section repeated for each DLL) * <dlls/<dll>/tests/file.c>:<CVS version> (multiple times, for each file) <any errors/warnings generated during compilation, verbatim> <output of 'wine dlls/<dll>/tests/<dll>_test.exe.so> > One more thing, I really do not > have the faintest idea about how to integrate this into the > WineHQ page. There may be reasons there, too, like eg. the > need to notify the system about a new build, which could be > done by uploading the information skeleton... Well, this is what I'm thinking: -- master file and test results are emailed to wine-tests(a)winehq.org this is simple to do, Jakob should just change the submit method to email, and it should work. In fact, Jakob why don't we start doing that, to see how it works? -- We need to integrate your processing script with sendmail, just like mailman is. This way, when an email arrives on the wine-tests list, you get to process it right away. The result template could be placed right in the website, if Jer is OK with the idea. Jer, do you have any special requirements for this stuff? -- Dimi.

Sept. 30, 2003

Re: Question about WineX licences

by Ove Kaaven

tir, 30.09.2003 kl. 17.16 skrev Dimitrie O. Paun: > On September 30, 2003 09:16 am, Ove Kaaven wrote: > > Now the LGPL-ness of Wine > > actually makes it an advantage to hold code back from Wine in some > > circumstances, whether you and I like it or not. > > Your argument is valid right now because there was not attempt > to abstract the copy protection through some kind of interface. > We've had this discussion before, and Alexandre was willing to > accommodate such hooks, but the argument was put forward that > this is not possible. I simply do not believe you can't abstract > it, anything can be. One reason why you may not want to is that > you may be afraid that if people see the interface, they will > figure out how to write their own copy-protection code. But this > is a business, rather then a technical or legal reason... Well, there is a legal reason, Gav is afraid of the DMCA. There is also a licensing agreement with Macrovision that could be jeopardized by doing anything that made their copy protection scheme easier to "crack" (or whatever they're afraid of). And it's "impossible" because the patch we're talking about does not actually implement copy protection. It only makes Wine implement certain Windows quirks. For Wine not to implement these quirks in certain APIs may be considered bugs, and how do you abstract away bugfixes? Anyway, if you're really insistent, perhaps you can get Gav to let you sign a NDA and see the code for yourself, then come up with a way to abstract it, but you'd have to talk to him about it. It's not certain it would do much good for the paranoid game companies that currently contract us for Mac ports though.

Sept. 30, 2003

Re: uxtheme.dll

by Roderick Colenbrander

The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which is the same as on other Windows versions. Version 6 is the new version. One of the biggest changes is that this updated dll handles both the user and common controls. Further all controls now include some area in which can be drawn for theming. For more info check out: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html… Roderick Colenbrander On Tuesday 30 September 2003 17:06, Dimitrie O. Paun wrote: > On September 30, 2003 10:57 am, Roderick Colenbrander wrote: > > Microsoft releases two sets of > > comctl32 dlls. One of them is meant for backwards compatibility. > > Do you have any idea why would that be needed?

Sept. 30, 2003

Re: [ANN] Conformance testing campaign

by Dimitrie O. Paun

On September 29, 2003 05:57 pm, Ferenc Wagner wrote: > > In other words, he is supposed to detect a hanged test, > > and report an error? > > Now I lost you here. Who is he? Jakob, that is winetests.exe. It should read, "winetests.exe is supposed to detect a hanged test, kill it, and report an error?" But yeah, we seem to be on the same wavelength here. > > For sure we need to append a number, but my point is that > > once we generate that name dinamically, it's ugly and it > > shouldn't be displayed. > > An occasional 1, 2 or 3 at the end of your tag? Why not? Sure, if you thnk that's helpful, I just thought that it's a bit redundant to have columns named like this: win95_1 win95_2 win95_3 win95_4 ... the number just duplicate their position... > > As for who submitted it, we already have that, so we're > > good. > > But it can not possibly be displayed (a name is too wide and > you may have submitted several tests) Of course you can't display it in the column name, but you can get to it by clicking on the "reporter". Bottom line, I don't have a beef with it, if you find it useful, include it, other might find it useful as well. > > What about the max number of errors in all tests? > > Possible, but it would destroy the consistency of the > links in the column. May be worth it, though. I guess you mean the links to results.txt. Yeah, those should go, they would be confusing. We can make them be links to the OS's home page or something. Or maybe a historical overview table with test results only for that OS... :) -- Dimi.

Sept. 30, 2003

Re: shlwapi 405/406

by Dimitrie O. Paun

On September 29, 2003 05:31 pm, Jon Griffiths wrote: > But since you're adament, this should probably be made a janitorial > task; internal stdcall functions are currently used in other places > (5 other files in shlwapi, for example). It doesn't seem that much of a problem, a patch would be simpler than to introduce a new janitorial task... :) -- Dimi.

Sept. 30, 2003