September 2003 - Wine-Devel

Re: wine & ccache

by Mike Hearn

On Tue, 2003-09-30 at 01:40, Alexandre Julliard wrote: > One problem is that most makefiles specify different defines, so you > basically need to have one different rule for each C file. Then there > are many files that have explicit rules. It could be done, but I don't > think it's worth it, and the result would be really messy and hard to > maintain. Maybe oneday it would be worth porting the Wine build system to SCons (http://www.scons.org/) From "What makes SCons better": * Configuration files are Python scripts--use the power of a real programming language to solve build problems. * Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types. * Built-in support for C, C++, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types. * Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce. * Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files. * Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps. * Improved support for parallel builds--like make -j but keeps N jobs running simultaneously regardless of directory hierarchy. * Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs. * Global view of all dependencies--no more multiple build passes or reordering targets to build everything. * Building from central repositories of source code and/or pre-built targets. * Ability to share built files in a cache to speed up multiple builds. * Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.

Sept. 30, 2003

Re: Start menu (especially for Alexandre Julliard)

by Mike Hearn

On Mon, 2003-09-29 at 22:06, Robert van Herk wrote: > As I understand (from the explanation by Russell Howe (thanx:-))), > there is a script called wineshelllink that is supposed to install the > created start menu items in your KDE menu. Indeed. It is rather broken though. It works sometimes, but only for KDE <= 3.1, not 3.2 or GNOME2. > Second: from looking at the script it seems that this menu is not > synchronized with the actual contents of your start menu, which would > seem more fancy to me. Because Windows users will be aquainted with > the fact that the Start menu directory actually contains the contents > of the start menu. This is easier said than done. Remember that in future all menu items will be controlled via vFolders (freedesktop.org) > What I would propose is a system in which the contents of the wine > menu would be in continuous synchronization with your start menu. That > would mean: So when does the sync occur? > Wouldn't you agree such a system would be better? Certainly. I look forward to seeing your patch ;) thanks -mike

Sept. 30, 2003

Re: Wineconf 2004, otherwise known as...

by Mike Hearn

On Tue, 2003-09-30 at 05:40, Dmitry Timoshkov wrote: > 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 :-) I notice vodka isn't in that list of common exaggerations - party on! :)

Sept. 30, 2003

Re: Trouble installing MS SQLserver 2000 Client Tools

by Mike Hearn

On Mon, 2003-09-29 at 18:07, Craig Davison wrote: > Hi, > > I've been trying to install the SQLserver Client Tools with Wine 20030911 > (on Redhat 9). The setup process fails near the beginning because it > cannot install MDAC ("Setup is installing Microsoft Data Access Components > (MDAC) ..."). Strange, I remember installing MDAC just fine a few months ago. > It exits with a dialog that says "Installation of the Microsoft Data > Access Components package failed. (-1)". The following console messages > are displayed: Well you would need to debug this further. The only message that looks like it *might* cause problems is the first: > fixme:process:CreateProcessA (F:\standard\x86\other\sqlredis.exe,...): > CREATE_SEPARATE_WOW_VDM ignored > I can't install MDAC standalone (MDAC_TYP.EXE from microsoft's website) > either What errors does this get you? > , but I don't think that matters because SQLserver setup will always > try to install MDAC. That's dumb. Why would it try to install something that is already present? > Note that I have IE 5.5SP2 installed, and I think DCOM98 (I can't tell if > that failed or succeeded) according to instructions in the WineHQ appdb. To force usage of the stuff DCOM98 installed you need to run wine with "--dll ole32,oleaut32,rpcrt4=n", or with CVS versions of wine like this: WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n" wine setup.exe > Wine is emulating "win98". Try changing it. It might come good. thanks -mike

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Mike Hearn

On Mon, 2003-09-29 at 21:18, Alexandre Julliard wrote: > Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > > > wouldn't something like Xnest help here ? > > Yes, it would be one way to implement it (and arguably it's the right > way in an X environment, there's no reason for Wine to duplicate that > functionality). 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'm not sure how well Xnest supports X extensions and > hardware acceleration, though that could probably be fixed. IIRC it does not support Xrender at all. 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)? thanks -mike

Sept. 30, 2003

Re: [dx82] Recode all the lights support

by MichaelGuennewig＠gmx.de

Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > Changelog > > MaxActiveLights means number of concurrent lights, but any number can > be set up. Change support for lights into a linked list and only set > up an equivalent gl light when the light is enabled. > > Jason > > PS If this causes any regressions please let me know. I have tested it > as far as possible and havent seen anything wrong with it. When trying to playing "The Elder Scrolls III: Tribunal" version 1.4.1313 german I get now the following fixme's: fixme:d3d:IDirect3DDevice8Impl_LightEnable Light enabled requested but light not defined, so defining one! Now the cone's of the lights are visible on surfaces near a source. Looks better now, but the known issues (body texture missing, crash after a while) still persists. Michael

Sept. 30, 2003

RE: uxtheme.dll

by Mike Jackson

I would be glad to be of any assistance I can be in this matter. I think wine is a great project, and I have been looking for the right project to immerse my self in. I think I've just found it :-) Mike Jackson -----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On Behalf Of Shachar Shemesh Sent: Tuesday, 30 September 2003 6:26 PM To: Roderick Colenbrander Cc: Kevin; wine-devel(a)winehq.com Subject: Re: uxtheme.dll Roderick Colenbrander wrote: >I hope you know what you will begin with. (For the ones that don't know >uxtheme.dll is the dll that takes care of all theming on WinXP and it >is the dll that dlls like comctl32 and all others use for theming) > >Some time ago I checked out uxtheme.dll a bit and it seems that it >needs changes all over Wine. As I understand it WinXP ships with two >sets of comctl32.dll and friends. One is the "old" version and one is a >new uxtheme aware version. The uxtheme aware version contains lots of >changes and uses uxtheme for theming. To use uxtheme you need to add >uxtheme support to the dlls that need it which looks like a huge job. > It does. > Perhaps this is something post Wine-1.0? > Why? This seems liks something that can be done incrementally. Kevin is interested in doing it. Is there any reason to wait? Kevin should be aware of what he's getting himself into, of course, but otherwise it's his call. That's what free software development is all about. >Roderick Colenbrander > > Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

Sept. 30, 2003

Re: uxtheme.dll

by Shachar Shemesh

Roderick Colenbrander wrote: >I hope you know what you will begin with. (For the ones that don't know >uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll >that dlls like comctl32 and all others use for theming) > >Some time ago I checked out uxtheme.dll a bit and it seems that it needs >changes all over Wine. As I understand it WinXP ships with two sets of >comctl32.dll and friends. One is the "old" version and one is a new uxtheme aware >version. The uxtheme aware version contains lots of changes and uses uxtheme for >theming. To use uxtheme you need to add uxtheme support to the dlls that need >it which looks like a huge job. > It does. > Perhaps this is something post Wine-1.0? > Why? This seems liks something that can be done incrementally. Kevin is interested in doing it. Is there any reason to wait? Kevin should be aware of what he's getting himself into, of course, but otherwise it's his call. That's what free software development is all about. >Roderick Colenbrander > > Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

Sept. 30, 2003

Re: Question about WineX licences

by Jonathan Wilson

> Everything that's LGPL should be listed on the above page. Additionally, > code in ReWind is X11. Anything else in WineX may be assumed AFPL, but > may also be released as X11 at TransGaming's discretion. I think most > non-DirectX code (and even a limited subset of the DirectX code) could > be released as X11 on request, although that's up to Gav. To me it makes sense for TransGaming to give back everything except DirectX since the focus of WineX is gaming and its the DirectX code and the copy protection support that is the bits that are making transgaming the money. One advantage is that then TransGaming could move more of the "support dlls" (things like ole32, oleaut32 & so on) up to the latest WINE LGPL code (since they would no longer have any custom modifications to those dlls) and both base WINE and WineX would get better as a consequence. OTOH, there may be valid reasons for TransGaming not to licence things like OLE/COM improvements back as X11 or LPGL.

Sept. 30, 2003

Re: Question about WineX licences

by Mike McCormack

My guess is that Transgaming has signed an NDA with one or more of the companies that write copy protection schemes for games (eg. Safedisk), and is not even able to discuss what is required to make such hooks in Wine, or how to change the build procedure to make it possible for the scheme to work. Mike > 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...

Sept. 30, 2003