September 2007 - Wine-Devel

Re: Wine application compatibility

by TheBlunderbuss

Roderick Colenbrander wrote: >> On Saturday 29 September 2007 10:34:19 am Roderick Colenbrander wrote: >> >>> Hi, >>> >>> Every Wine release more and more programs start to work on Wine. A >>> >> serious >> >>> problem is that not all programs can work out of the box. Some games for >>> instance need the windows version to be set to Windows 95 or it will >>> >> crash. >> >>> Other games like Medal of Honour need their OpenGL extension string >>> >> trimmed >> >>> to get it to work on cards which support a lot of OpenGL extensions. >>> >> There >> >>> are dozens of more examples like that. >>> >> The majority of Wine's options are settable via the registry and can be >> given >> app-specific overrides. So how about wineprefixcreate creates registry >> entries for specific apps that are known to need special settings? >> >> Just need to be really really careful that an app needs the change, and >> that >> it's not due to a bug in Wine or something. >> > > Yep wineprefixcreate should handle this and I think in combination with winecfg. One issue that I see is that an executable name is not unique. In case of games if multiple ones are using 'game.exe' then there is a problem. For AppDefaults you can type the whole path but you don't know that in advance. > > I fear that for executable some sort of md5sum needs to be stored (there might be something like that already in the app in the form of a product code or so) for purposes like this. We should check how microsoft handles this. Anyway I think that support in the wine loader is needed. > > Roderick > I agree on the checksum. There could be multiple versions of the same program, even, as with Steam's case. How would the registry fix work with wineprefixcreate? Would the user checksum the target program, and then pass as an argument to wineprefixcreate? I think it would be best to have a GUI element using winecfg, to tell the user if there are fixes to be applied.

Sept. 30, 2007

[PATCH] Fix Ugly borders around undecorated windows in Gnome

by Matthew D'Asaro

This is my first attempt at submitting a patch to WINE, so please excuse me if I have broken any conventions or am going through the wrong channel. As it currently stands, wine is setting the 'MWM_DECOR_BORDER' hint on managed but undecorated windows, such as iTunes, or Winamp. This does not cause problems in KDE, but in Gnome it puts a gray border around such windows. Not setting this hint does not seem to cause problems in KDE and fixes the problem in Gnome. A patch to do just that is attached. Comments? -Matthew D'Asaro

Sept. 30, 2007

Re: New winetricks: 'volnum' command to work around bug 5351, new gecko

by Dan Kegel

On 9/30/07, Hans Leidekker <hans(a)it.vu.nl> wrote: > Renaming drive_c is more intrusive, I wouldn't do it while Wine is > running. Absolutely. I suppose I should put in a warning to that effect.

Sept. 30, 2007

Re: New winetricks: 'volnum' command to work around bug 5351, new gecko

by Hans Leidekker

On Sunday 30 September 2007 17:00:38 Dan Kegel wrote: > > All installers I have seen that require the special volume name also > > have a workaround in the form of a command line switch /x which allows > > you to specify a destination folder for extraction. Look at the msxml4 > > verb for an example. > > Good point, and I've updated the comments in the volnum verb. > Renaming drive_c is more convenient than using /x sometimes, so > the volnum verb should probably stay. Renaming drive_c is more intrusive, I wouldn't do it while Wine is running. And running wineserver -k beforehand precludes some useful testing scenarios. -Hans

Sept. 30, 2007

Weekly Newsletter

by EA Durbin

Who maintains the weekly newsletter? I noticed it hasn't been updated since May. _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

Sept. 30, 2007

Re: New winetricks: 'volnum' command to work around bug 5351, new gecko

by Dan Kegel

On 9/30/07, Hans Leidekker <hans(a)it.vu.nl> wrote: > Hold on a sec... > > All installers I have seen that require the special volume name also > have a workaround in the form of a command line switch /x which allows > you to specify a destination folder for extraction. Look at the msxml4 > verb for an example. Good point, and I've updated the comments in the volnum verb. Renaming drive_c is more convenient than using /x sometimes, so the volnum verb should probably stay. > Attached patch fixes a 404 in the liberation verb. Applied, thanks. Updated winetricks at the usual place, http://kegel.com/wine/winetricks - Dan

Sept. 30, 2007

Re: Wine application compatibility

by Roderick Colenbrander

> On Saturday 29 September 2007 10:34:19 am Roderick Colenbrander wrote: > > Hi, > > > > Every Wine release more and more programs start to work on Wine. A > serious > > problem is that not all programs can work out of the box. Some games for > > instance need the windows version to be set to Windows 95 or it will > crash. > > Other games like Medal of Honour need their OpenGL extension string > trimmed > > to get it to work on cards which support a lot of OpenGL extensions. > There > > are dozens of more examples like that. > > The majority of Wine's options are settable via the registry and can be > given > app-specific overrides. So how about wineprefixcreate creates registry > entries for specific apps that are known to need special settings? > > Just need to be really really careful that an app needs the change, and > that > it's not due to a bug in Wine or something. Yep wineprefixcreate should handle this and I think in combination with winecfg. One issue that I see is that an executable name is not unique. In case of games if multiple ones are using 'game.exe' then there is a problem. For AppDefaults you can type the whole path but you don't know that in advance. I fear that for executable some sort of md5sum needs to be stored (there might be something like that already in the app in the form of a product code or so) for purposes like this. We should check how microsoft handles this. Anyway I think that support in the wine loader is needed. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Sept. 30, 2007

Re: winex11.drv: possible fix for thick border around utility window in DatePicker

by Dmitry Timoshkov

<a_villacis(a)palosanto.com> wrote: > It seems that, when presented with a combination of WS_POPUP and WS_BORDER > without any extended style, the window is supposed to be shown with a thin > border (a 1px border in Windows). I still have not found a window style that > makes a X window show a thin border, and the nearest thing in looks is no > border at all. Please comment on this patch, as I don't think it is exactly > sane. > > Changelog: > * Deactivate WS_BORDER when present with WS_POPUP > - else if (style & WS_BORDER) mwm_hints.decorations |= MWM_DECOR_BORDER; > + else if ((style & WS_BORDER) && !(style & WS_POPUP)) mwm_hints.decorations |= MWM_DECOR_BORDER; This looks like a bug in Metacity, I don't see why it adds "(disabled) decorations" when only asked for MWM_DECOR_BORDER. On the other hand we already check for WS_CHILD|WS_POPUP and don't add MWM_DECOR_BORDER if any of that styles present, so perhaps your change is in that direction, and should be made to also check for both WS_CHILD|WS_POPUP. Probably it's also worth to file a bug to metacity bugzilla. -- Dmitry.

Sept. 30, 2007

Re: New winetricks: 'volnum' command to work around bug 5351, new gecko

by Hans Leidekker

On Sunday 30 September 2007 04:53:56 Dan Kegel wrote: > Another month, another winetricks. This updates the gecko installed > by winetricks to 0.1.0, and adds a 'volnum' verb to let you run installers > that complain "Unable to find a volume for file extraction." And it > has a few other cleanups. Hold on a sec... All installers I have seen that require the special volume name also have a workaround in the form of a command line switch /x which allows you to specify a destination folder for extraction. Look at the msxml4 verb for an example. Attached patch fixes a 404 in the liberation verb. -Hans

Sept. 30, 2007

Re: Wine application compatibility

by Chris Robinson

On Saturday 29 September 2007 10:34:19 am Roderick Colenbrander wrote: > Hi, > > Every Wine release more and more programs start to work on Wine. A serious > problem is that not all programs can work out of the box. Some games for > instance need the windows version to be set to Windows 95 or it will crash. > Other games like Medal of Honour need their OpenGL extension string trimmed > to get it to work on cards which support a lot of OpenGL extensions. There > are dozens of more examples like that. The majority of Wine's options are settable via the registry and can be given app-specific overrides. So how about wineprefixcreate creates registry entries for specific apps that are known to need special settings? Just need to be really really careful that an app needs the change, and that it's not due to a bug in Wine or something.

Sept. 29, 2007

New winetricks: 'volnum' command to work around bug 5351, new gecko

by Dan Kegel

Another month, another winetricks. This updates the gecko installed by winetricks to 0.1.0, and adds a 'volnum' verb to let you run installers that complain "Unable to find a volume for file extraction." And it has a few other cleanups. As usual, it's at http://kegel.com/wine/winetricks - Dan revision 1.33 date: 2007/09/30 02:47:13; author: dank; state: Exp; lines: +18 -0 Added volnum verb to work around bug 5351 ---------------------------- revision 1.32 date: 2007/09/30 02:30:33; author: dank; state: Exp; lines: +15 -12 Minor janitorial cleanup ---------------------------- revision 1.31 date: 2007/09/30 02:26:40; author: dank; state: Exp; lines: +11 -9 Detlef Riekenberg reported that gecko was using old version. This fixes it. ---------------------------- revision 1.30 date: 2007/09/30 00:03:03; author: dank; state: Exp; lines: +14 -0 Sanity checking by Lei ---------------------------- revision 1.29 date: 2007/09/30 00:00:55; author: dank; state: Exp; lines: +1 -1 Fix typo introduced by last change ---------------------------- revision 1.28 date: 2007/09/29 23:21:33; author: dank; state: Exp; lines: +19 -38 Localized paths cleanup from Detlef Riekenberg -- Wine for Windows ISVs: http://kegel.com/wine/isv

Sept. 29, 2007

Re: The Spouse Test

by Jesse Allen

On 9/23/07, Dan Kegel <dank(a)kegel.com> wrote: > When will Wine be good enough for the average person to use? > One test is, "Is it good enough to let your spouse migrate to Linux > from Windows?". > My wife's must-have app list is roughly > > Microsoft Office '97 > Adobe Photoshop Elements 1 > Ulead PhotoImpact > Macromedia Dreamweaver 8 > Musicmatch Jukebox 8 > FamilyTreeMaker 2006 > > And you know what? All of those basically work > except for Photoshop Elements. They need some > cosmetic work, and a native DLL or two, and probably a few > obscure bugfixes, but I think that's it. > (I didn't test Office '97, since I expect she'll be using Crossover > for that, as Codeweavers tests that app pretty well.) > > It's possible that by this time next year Wine will pass this test for me. > - Dan > > > I suppose this past week Wine has passed the "poor student test" for me. I needed to make circuit diagrams and have a windows 95 program called circuit maker provided by the school. Well I had a backup of my git tree on my laptop from a few weeks ago, compiled it, ran wineprefixcreate, installed the program, and created the circuit diagram all without leaving the library! I've already used it again to simulate a circuit and do another report. Now if only I could get a better internet connection. Jesse

Sept. 29, 2007

Re: Broken patches since 0.9.45 (problem with missing binary files)

by Victor

On Saturday 29 September 2007 17:36:37 you wrote: > The patches are fine, but they are in git format, so you need to use > git-apply instead of patch to apply the binary changes properly. Thanks for your reply. I've fixed the script, now everything works without problems. Sorry for the "false alarm". -- With best regards, Victor Eremin (ErV2005(a)rambler.ru)

Sept. 29, 2007

Re: Wine application compatibility

by Rob

I understand there are many apps that need more sophisticated tweaking than the average wine user, even a contributor to the appdb, would be able to do. There are also quite a number of far less sophisticated tweaks, like needing to be run in win2k and not winXP for example, that are equally critical to getting application Y to run. Why not have them all in the same place? The open source model: I'll add what I know and can, you add what you know and can, and together hopefully all of us will be able to add enough that it's a complete list of tweaks. There's always the question of dealing with fools and malicious people, and I believe that's what you were getting at when you spoke of 'filtering' the repository. Wouldn't the wiki model should work for that? - you have to register to update, and you'll be banned if you hurt the project. It seems to me that there are enough contributors to appdb to support a system like this, do you agree? Rob Roderick Colenbrander wrote: >> This sounds like the kind of thing that the devs should work to provide >> the functionality for, but >> that the user base should actually maintain. For example, appdb could >> become a place where users >> could suggest, test, and finalize said tweaks for each application. There >> would then be a way for >> wine to use a small 'database' of that information which could be packed >> with each release or >> downloaded from the appdb site (both would seem the best way to go with >> that). The devs aren't >> responsible for maintaining the list of tweaks (that's a waste of their >> time), but the users can >> still benefit from it. >> >> Rob > > It could be maintained at lets say appdb but the problem is filtering on what should be in the database and what not. Just a setting to get a program running or a dll override isn't. It is for programs which really need fixups like the ones I described. Not everyone can maintain such a list. > > Roderick

Sept. 29, 2007

Re: Wine application compatibility

by Rob

This sounds like the kind of thing that the devs should work to provide the functionality for, but that the user base should actually maintain. For example, appdb could become a place where users could suggest, test, and finalize said tweaks for each application. There would then be a way for wine to use a small 'database' of that information which could be packed with each release or downloaded from the appdb site (both would seem the best way to go with that). The devs aren't responsible for maintaining the list of tweaks (that's a waste of their time), but the users can still benefit from it. Rob Roderick Colenbrander wrote: > Hi, > > Every Wine release more and more programs start to work on Wine. A serious problem is that not all programs can work out of the box. Some games for instance need the windows version to be set to Windows 95 or it will crash. Other games like Medal of Honour need their OpenGL extension string trimmed to get it to work on cards which support a lot of OpenGL extensions. There are dozens of more examples like that. > > Microsoft is having similar troubles and since Windows 2000 they provide appcompat stuff for windows (in WinXP/Vista it is a default feature). It basically works on a database which is used somehow at program startup and which then applies 'fixes' like 'setting the windows version', patching function calls and more. See for instance > http://technet.microsoft.com/en-us/library/bb457032.aspx for more info and pay attention to http://technet.microsoft.com/en-us/library/bb457032.apcpxp06_big(en-us,tech… which shows a part of the list and the scope of it. > > I think we have reached a point in Wine where we might need something similar :( Our compatibility seems to be bigger than XP/Vista so we might not need much. Perhaps we need to maintain some file which applies really needed fixups. It should be merged into the registry using wineprefixcreate and the database can be checked using winecfg. It would use normal AppDefaults. > > What do you guys think about such a thing? I don't like it at all but I fear it is really needed. If we would add such I'm not sure if we are allowed to dump microsoft their database, looking at it might be something differently. > > It might be a good topic for WineConf. > > Regards, > Roderick Colenbrander

Sept. 29, 2007

Re: Wine application compatibility

by Roderick Colenbrander

> This sounds like the kind of thing that the devs should work to provide > the functionality for, but > that the user base should actually maintain. For example, appdb could > become a place where users > could suggest, test, and finalize said tweaks for each application. There > would then be a way for > wine to use a small 'database' of that information which could be packed > with each release or > downloaded from the appdb site (both would seem the best way to go with > that). The devs aren't > responsible for maintaining the list of tweaks (that's a waste of their > time), but the users can > still benefit from it. > > Rob It could be maintained at lets say appdb but the problem is filtering on what should be in the database and what not. Just a setting to get a program running or a dll override isn't. It is for programs which really need fixups like the ones I described. Not everyone can maintain such a list. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Sept. 29, 2007

Wine application compatibility

by Roderick Colenbrander

Hi, Every Wine release more and more programs start to work on Wine. A serious problem is that not all programs can work out of the box. Some games for instance need the windows version to be set to Windows 95 or it will crash. Other games like Medal of Honour need their OpenGL extension string trimmed to get it to work on cards which support a lot of OpenGL extensions. There are dozens of more examples like that. Microsoft is having similar troubles and since Windows 2000 they provide appcompat stuff for windows (in WinXP/Vista it is a default feature). It basically works on a database which is used somehow at program startup and which then applies 'fixes' like 'setting the windows version', patching function calls and more. See for instance http://technet.microsoft.com/en-us/library/bb457032.aspx for more info and pay attention to http://technet.microsoft.com/en-us/library/bb457032.apcpxp06_big(en-us,tech… which shows a part of the list and the scope of it. I think we have reached a point in Wine where we might need something similar :( Our compatibility seems to be bigger than XP/Vista so we might not need much. Perhaps we need to maintain some file which applies really needed fixups. It should be merged into the registry using wineprefixcreate and the database can be checked using winecfg. It would use normal AppDefaults. What do you guys think about such a thing? I don't like it at all but I fear it is really needed. If we would add such I'm not sure if we are allowed to dump microsoft their database, looking at it might be something differently. It might be a good topic for WineConf. Regards, Roderick Colenbrander -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Sept. 29, 2007

Re: version resource for ole2nls.dll

by Dmitry Timoshkov

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > Ok, looks like i picked a bad example from the wine tree. > +#define WINE_FILEVERSION 2,1,3050,1 > #define WINE_FILEVERSION_STR "2.10.3050.1" Shouldn't it be 2,10,3050,1 ? Also, could you please also fix the place(s) which you took as an example? -- Dmitry.

Sept. 29, 2007

Re: Broken patches since 0.9.45 (problem with missing binary files)

by Alexandre Julliard

Victor <ErV2005(a)rambler.ru> writes: > Can someone fix this problem? (It looks like problem is related to binary > files) It would be great if both patches were fixed and re-uploaded. The patches are fine, but they are in git format, so you need to use git-apply instead of patch to apply the binary changes properly. -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2007

Broken patches since 0.9.45 (problem with missing binary files)

by Victor

Hello! It looks like last two patches - wine-0.9.45.diff.bz2 and wine-0.9.46-diff.bz2 are broken. It is not possible to compile wine-0.9.45 (if sources were created by patching 0.9.44 with wine-0.9.45.diff.bz2) due to missing notepad.ico :) : --- make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs/net' make[2]: Entering directory `/home/erv/distr/wine/wine-0.9.45/programs/notepad' ../../tools/makedep -C. -S../.. -T../.. -I../../include/msvcrt dialog.c main.c rsrc.rc notepad.ico: No such file or directory notepad.ico was first included from rsrc.rc:47 make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. -I../../include/msvcrt dialog.c main.c rsrc.rc notepad.ico: No such file or directory notepad.ico was first included from rsrc.rc:47 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs/notepad' make[1]: *** [notepad/__depend__] Error 2 make[1]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs' make: *** [programs/__depend__] Error 2 Compilation failed, aborting install. --- and it isn't possible to compile wine-0.9.46 (created by patching complete 0.9.45 sources with wine-0.9.46.diff.bz2) due to missing c1.bmp in cards.dll: --- make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls/capi2032' make[2]: Entering directory `/home/erv/distr/wine/wine-0.9.46/dlls/cards' ../../tools/makedep -C. -S../.. -T../.. cards.c cards.rc c1.bmp: No such file or directory c1.bmp was first included from cards.rc:23 make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. cards.c cards.rc c1.bmp: No such file or directory c1.bmp was first included from cards.rc:23 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls/cards' make[1]: *** [cards/__depend__] Error 2 make[1]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls' make: *** [dlls/__depend__] Error 2 Compilation failed, aborting install. --- And here is a script I've been using to unpack patches (it should be placed in dir containing wine-0.9.30.tar.bz2 and patches (0.9.31, 0.9.32, etc) in *.diff.bz2 format : --- #!/bin/sh echo unpacking wine BUILD=30 BASE=$BUILD WINE='wine-0.9' tar -xvvjf $WINE.$BUILD.tar.bz2 && cd $WINE BUILD=$(($BUILD+1)) cd "$WINE.$BASE" while [ -f ../$WINE.$BUILD.diff.bz2 ]; do echo $WINE.$BUILD bzcat ../$WINE.$BUILD.diff.bz2|patch -p1 && BUILD=$(($BUILD+1)) done cd .. mv $WINE.$BASE $WINE.$(($BUILD-1)) --- Can someone fix this problem? (It looks like problem is related to binary files) It would be great if both patches were fixed and re-uploaded. Thanks. -- Victor Eremin (ErV2005(a)rambler.ru)

Sept. 29, 2007

Solidworks Update

by Stephan Rose

I tested Solidworks with 0.9.46 today and fonts seem to be ok now. No more screwed up texts like in the previous versions. So that's a definite improvement. =) Everything else seems to have remained unchanged though. Stephan

Sept. 29, 2007

Re: Revert "mshtml: Return wine: URI for protocols handled by MSHTML."

by Vitaliy Margolen

Jacek Caban wrote: > Vitaliy Margolen wrote: >> I do not know what author wanted to archive here. But what he did >> archive is broken Wine and all other programs that use their own >> "protocol:". >> >> This reverts commit 718b771f2a57d0c762d24c6ef62f070eb3647e8a. >> >> mshtml: Revert commit that broke steam and most other apps. > > This patch fixed some apps that use pluggable protocols and reverting it > is a step backward. I've sent a correct fix. > > Thanks, > Jacek > Thanks indeed it does fix the problem. Sorry, it appears the bug 9516 didn't have the regression testing information. Vitlaiy.

Sept. 28, 2007

Re: Revert "mshtml: Return wine: URI for protocols handled by MSHTML."

by Jacek Caban

Vitaliy Margolen wrote: > I do not know what author wanted to archive here. But what he did > archive is broken Wine and all other programs that use their own > "protocol:". > > This reverts commit 718b771f2a57d0c762d24c6ef62f070eb3647e8a. > > mshtml: Revert commit that broke steam and most other apps. This patch fixed some apps that use pluggable protocols and reverting it is a step backward. I've sent a correct fix. Thanks, Jacek

Sept. 28, 2007

Re: DInput mouse - where to go from here?

by Kuba Ober

On Thursday 27 September 2007, Vitaliy Margolen wrote: > Stefan Dösinger wrote: > > 1) Multiple Mice. If there are 2 mouse devices, the X server manages them > > and combines them to one core pointer. These configurations are pretty > > common, for example on laptops with touchpad + usb mouse. > > This is true, each mouse will have it's own device. However I have never > seen a single person who used 2 or more mice while playing games <g> Almost every laptop with externally connected USB mouse will behave like that. Kuba

Sept. 28, 2007

Re: AntiAliasing for Source Based games

by Stefan Dösinger

Am Freitag, 28. September 2007 07:20:19 schrieb christine.youngson(a)clear.net.nz: > Hi everyone, > > I'm exceptionally new to posting messages on mailing lists (ie its my first > time) so please forgive me in advance if I've done something wrong! I found nothing to complain :-) > My question for the wine developers is, why is Anti Aliasing not supported > for Source based games? As Roderick mentioned AA is a property of the Pixel Format. Due to deeply rooted reasons Wine at startup. It has to choose one before the application can say what it wants, and later on it cannot be changed. Wine first tries a format with all features(except AA) enabled, and then uses less complex formats until it finds one that is supported. To support setting AA from games we'd have to be able to change the format. This is major work in wine's x11 driver, this problem exists since many years. However, there is an easy way to get FSAA support: The driver can override the AA setting requested by the game. If you have an nvidia card, you can configure that in nvidia-settings, on Antialiasing settings page. This way you get FSAA, but you cannot enable / disable it from the game.

Sept. 28, 2007

Re: AntiAliasing for Source Based games

by Roderick Colenbrander

> Hi, > > > I would consider learning C etc myself to try and get this functionality > (I > > learned Java as part of my degree) up and running, but sadly I probably > > don't have the skills to contribute. > > AA under linux is not app-dependant afaik. It's driver dependant, so > you'll > have to setup your graphics card driver to turn on AA for OpenGL based > progs, > prior to running the game under WINE. OpenGL offers AA itself using the multisample extension. The level of AA is a property of the pixelformat in use for opengl. Due to various reason the number of pixelformats is limited and for that reason games running on Wine don't show AA. This is the case for both OpenGL and Direct3D. Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Sept. 28, 2007

RE: iTunes 7.4.2 doesn't even install for me

by Rolf Kalbermatter

Juan Lang wrote: >> L"C:\\windows\\System32\\Drivers\\GEARAspiWDM.sys" (native) at >> 0x460000 trace:module:process_attach (L"GEARAspiWDM.sys",(nil)) - >> START trace:module:MODULE_InitDLL (0x460000 >> L"GEARAspiWDM.sys",PROCESS_ATTACH,(nil)) - CALL >> trace:seh:raise_exception code=c0000005 flags=0 addr=0x464010 >> trace:seh:raise_exception info[0]=00000001 trace:seh:raise_exception >> info[1]=00460038 trace:seh:raise_exception eax=0046137e ebx=7bc90dc8 >> ecx=0000001c edx=00460000 esi=7bc87f5b edi=00460038 > >That address (0x00460038) is suspect. It looks like part of a Unicode string. >Something about how this driver is loaded is buggy, I'm guessing ntoskrnl.exe >is a bit too stubby for it yet. I think this conclusion is a bit to simple. Considering the module base address of 0x460000 this address could be quite legitime. Rolf Kalbermatter

Sept. 28, 2007

Re: AntiAliasing for Source Based games

by Wojciech 'arab' Arabczyk

Hi, > I would consider learning C etc myself to try and get this functionality (I > learned Java as part of my degree) up and running, but sadly I probably > don't have the skills to contribute. AA under linux is not app-dependant afaik. It's driver dependant, so you'll have to setup your graphics card driver to turn on AA for OpenGL based progs, prior to running the game under WINE. Worked for me, should work for you. -- Best regards Wojciech Arabczyk

Sept. 28, 2007

Re: I need help, please

by Robert Shearman

David Outteridge wrote: > Thank you for the reply, Dan, a reply is appreciated. > > I must write that I am surprised by this response - your website seems > to be asking for help at all levels. I am not quite convinced that > months of work is needed (mainly because corelDRAW version 11 works); > but maybe you know something I do not - the main point of my posting, > of course. Largely, I was asking for policy information; i.e., *what* > to do, not *how* to do it, which I feel I can handle. > If you're having trouble installing CorelDraw, then add a bug to http://bugs.winehq.org attaching a +msi debug log, making sure that a bug doesn't already exist for the version and bug you're reporting. Developers may then put hints into the bug as to where to look for next. A good place to start out helping the Wine project by coding is by writing tests for untested APIs. There are also some todo lists on the website that may give you some pointers as to what to code on in order to start learning about the Wine codebase. -- Rob Shearman

Sept. 28, 2007

Re: I need help, please

by Carl-Daniel Hailfinger

Hi David, On 28.09.2007 17:28, David Outteridge wrote: > Thank you for the reply, Dan, a reply is appreciated. > > I must write that I am surprised by this response - your website seems > to be asking for help at all levels. I am not quite convinced that Yes, any help is appreciated and you can help as well. > months of work is needed (mainly because corelDRAW version 11 works); > but maybe you know something I do not - the main point of my posting, Dan knows more, but AFAIK the X3 version uses some interfaces which are not implemented yet. That's the problem with quite a few new applications, but in due time they will be supported. Besides that, having past versions of an application working fine under Wine unfortunately has nothing to say about newer versions of that app. Sometimes, application internals change so much that it takes literally a year or more to support a newer version. Look at MS Office for example. One more thing: It may or may not be easier to get CorelDRAW 12 to install and run first, perhaps some of the issues you have to fix there also help for the X3 version. > of course. Largely, I was asking for policy information; i.e., *what* > to do, not *how* to do it, which I feel I can handle. Looking at your first mail, I see you indeed dived into the code and accomplished something. My suggestion would be to post a separate mail (if possible, with a proposed hack/patch) with a descriptive subject for every issue you run into. Such mails are generally replied to more often (because of the descriptive subject) than mails with the subject line of this thread. Another hint: You wrote that you used comp.emulators.ms-windows.wine for questions, however that newsgroup is AFAIK a one-way gateway from mail to news, i.e. 98% of the members of that mailing list did NOT see your message. > Good Luck with the project. Thanks! Regards, Carl-Daniel

Sept. 28, 2007

Re: I need help, please

by Reece Dunn

On 28/09/2007, David Outteridge <dajo(a)frii.com> wrote: > Thank you for the reply, Dan, a reply is appreciated. > > I must write that I am surprised by this response - your website seems > to be asking for help at all levels. Help *is* needed at all levels. Wine needs testers to test their favorite applications and report bugs. Without the bug reports, the developers don't know (or will miss) regressions or features that are not supported in Wine yet. It is also a good idea to add an entry to the AppDB (and possibly to the equivalent one over at www.codeweavers.com for the CrossOver version of Wine). This helps the developers know where to focus their attention to get the best coverage. Note that this does not mean that because your application is not popular it will not be fixed. This is where people like you can come in and help improve the support for running Windows applications on Wine. > I am not quite convinced that > months of work is needed (mainly because corelDRAW version 11 works); > but maybe you know something I do not - the main point of my posting, > of course. In general, applications that run on Windows 98 or earlier should (in theory) run without problems. The more recent the version of Windows an application wants to use, the less likely it will run, or run well. Newer versions of an application will tend to take advantage of newer features in Windows and start requiring more recent versions, increasing the chances that it will run into areas that are not implemented, or partially implemented in Wine. For example, the latest version of Wine has added support for side-by-side manifests for installing different versions of a DLL with the same name. This was introduced in Windows XP and is required by newer applications. Also, GDIPlus - an extended drawing interface - was also introduced in XP and has only recently been partially supported in Wine. The effort to support iTunes 7 took several months to complete, even though earlier iTunes were working. So getting CorelDraw 13 to work is likely not to be an easy task. Once the program installs, there are likely to be regressions with CorelDraw itself. > Largely, I was asking for policy information; i.e., *what* > to do, not *how* to do it, which I feel I can handle. I would suggest raising bug reports for each issue that you encounter as this will help developers track the problems that CorelDraw 13 has on Wine. Also, try and help maintain the application on the Wine AppDB and CodeWeavers application support page. And keep testing! HTH, - Reece

Sept. 28, 2007

Re: I need help, please

by David Outteridge

Thank you for the reply, Dan, a reply is appreciated. I must write that I am surprised by this response - your website seems to be asking for help at all levels. I am not quite convinced that months of work is needed (mainly because corelDRAW version 11 works); but maybe you know something I do not - the main point of my posting, of course. Largely, I was asking for policy information; i.e., *what* to do, not *how* to do it, which I feel I can handle. Good Luck with the project. dajo

Sept. 28, 2007

Re: address space layout

by Alexandre Julliard

Tijl Coosemans <tijl(a)ulyssis.org> writes: > It appears that the only solution is to locate wine somewhere after > 0x80000000 instead of at 0x7bf00000 and to allow mmap to allocate > memory there. Then the data segment size limit can be set to 256Mb or > something instead of 32Mb. The problem is then that builtin dlls are > mmapped (by the runtime linker) well beyond 0x80000000. Now I'm > thinking, would it be possible to load dummy dlls somewhere in the > first 2Gb of address space? Through which API calls can a program > determine a dll is above 0x80000000 by the way? It can be any address located in the dll; normally it's the module handle, but it can also be functions or variables. Also there are copy protection tools that check that the dll code is really inside the module, so you can't create a dummy dll and put the real code somewhere else. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2007

Re: msvcrt: move error condition before memory allocation (found by Smatch) [1/3, resend]

by Alexandre Julliard

Lionel_Debroux <lionel_debroux(a)yahoo.fr> writes: > _wfullpath leaks some heap memory in an error paths. Found in Michael > Stefaniuc's list of Wine potential bugs detected by Smatch. > Fixed by moving the error treatment before the allocation, since the > error treatment doesn't fire up if there was a memory allocation (due to > size = MAX_PATH; assignment). > > Is there anything wrong with this patch ? Yes, you are using the size before checking if the buffer is NULL (in which case the size is meaningless), and as you said yourself the error treatment isn't used if there was an allocation, so there's no leak to fix here. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2007

Re: Wine gets exposed in Norway :)

by Tomas Zijdemans

> Please note that this is a secret website, so we Norwegians cannot send the > website address to the list. :) > > > Alexander N. Sørnes > I get the satire... Here: http://www.hardware.no/ :)

Sept. 28, 2007

AntiAliasing for Source Based games

by christine.youngson＠clear.net.nz

Hi everyone, I'm exceptionally new to posting messages on mailing lists (ie its my first time) so please forgive me in advance if I've done something wrong! My question for the wine developers is, why is Anti Aliasing not supported for Source based games? I play Day of Defeat Source everyday, and many wine gamers play steam based source engine games such as DoDs and Counterstrike Source, and its nearly at windows xp level fps wise, but the main nuisance for us is that there is no AA! AA greatly improves the look of games, and it seems that there is an emphasis on making the games look nice by adding functionality such as shaders and glsl, so in this respect, a basic feature of games such as AA should be considered to be made. Also Team Fortress Two is coming out fairly shortly and AA would be a nice feature to implement for when it comes out :) I would consider learning C etc myself to try and get this functionality (I learned Java as part of my degree) up and running, but sadly I probably don't have the skills to contribute. Anyways, keep up the excellent work wine developers, you guys do a tremendous job, but please consider adding this one feature, as it would mean a lot to myself and many many others who play steam based source games etc using wine on Linux! Take care!

Sept. 28, 2007

Re: version resource for ole2nls.dll

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > "Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > >> This patch fixes Bug 9747 >> >> ChangeLog >> --------- >> added version resource for ole2nls.dll > >> +#define WINE_FILEVERSION_STR "2.10.3050.1" >> +#define WINE_FILEDESCRIPTION_STR "Wine OLE dll" >> +#define WINE_FILENAME_STR "OLE2NLS.DLL" >> + >> +#include "wine/wine_common_ver.rc" > > Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? > That not creates a confusion but could lead to hard debuggable > problems with application which test only one of them. The above should be read as: That not only creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.

Sept. 27, 2007

Re: version resource for ole2nls.dll

by Dmitry Timoshkov

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > This patch fixes Bug 9747 > > ChangeLog > --------- > added version resource for ole2nls.dll > +#define WINE_FILEVERSION_STR "2.10.3050.1" > +#define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > +#define WINE_FILENAME_STR "OLE2NLS.DLL" > + > +#include "wine/wine_common_ver.rc" Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.

Sept. 27, 2007

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation

by Alexandre Julliard

Roy Shea <roy(a)cs.hmc.edu> writes: > As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that > is equivalent to the bits.idl I'm developing. Since my dll is not > acting as a proxy, at least as I understand proxy dlls (I'm still > digging through COM books), I thought it would be more accurate to not > include the "prx" in the name of my dll. Simply changing the name > from bits.dll to bitsprx2.dll is easy enough, but I worry that the > semantics between a regular dll and a proxy dll would cause confusion > or problems. The only way to avoid confusion and problems is for your dll to have the same name, and behave the same way, as the Windows one. -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2007

Re: iTunes 7.4.2 doesn't even install for me

by Juan Lang

Hi Paul, > I saw your bug 9765 but I don't even get that far. The install crashes for me > with something that appears to be connected to a driver: Actually, I see that crash too. I meant to log a bug for it, but never did. Would you mind? (snip) > L"C:\\windows\\System32\\Drivers\\GEARAspiWDM.sys" (native) at 0x460000 > trace:module:process_attach (L"GEARAspiWDM.sys",(nil)) - START > trace:module:MODULE_InitDLL (0x460000 L"GEARAspiWDM.sys",PROCESS_ATTACH,(nil)) - > CALL > trace:seh:raise_exception code=c0000005 flags=0 addr=0x464010 > trace:seh:raise_exception info[0]=00000001 > trace:seh:raise_exception info[1]=00460038 > trace:seh:raise_exception eax=0046137e ebx=7bc90dc8 ecx=0000001c edx=00460000 > esi=7bc87f5b edi=00460038 That address (0x00460038) is suspect. It looks like part of a Unicode string. Something about how this driver is loaded is buggy, I'm guessing ntoskrnl.exe is a bit too stubby for it yet. Nevertheless, iTunes starts for me after this crash, it just warns about the registry entries needed for CD/DVD drives being missing, and I suspect that's due to this driver not being registered correctly. I just ignore that warning. > As your so busy with iTunes these days, I thought I contact you directly. I don't mind, but I'm actually off it now. I've tried to stay up to date this week, but no guarantees now that I'm back in school. --Juan

Sept. 27, 2007

Re: Wine gets exposed in Norway :)

by Alexander Nicolaysen Sørnes

On Thursday 27 September 2007 19:58:29 Tomas Zijdemans wrote: > The most visited and respected technology related site in Norway (210 > 000 unique norwegian hits a week), is now launching a series of articles > where they will test 3 games thoroughly in wine each month! > > Today the first article tested Fahrenheit, Guild Wars: Nightfall and > Civilization IV: Warlords. The results where good and focused on what > users should do to make them work smoothly. > > Hope this is an encouragement for Stefan and all the others of you > working to get games working :) Please note that this is a secret website, so we Norwegians cannot send the website address to the list. :) Alexander N. Sørnes

Sept. 27, 2007

Wine gets exposed in Norway :)

by Tomas Zijdemans

The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)

Sept. 27, 2007

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation

by Roy Shea

Howdy, On Thu, Sep 27, 2007 at 02:55:40PM +0200, Stefan D?singer wrote: > Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard: > > Roy Shea <roy(a)cs.hmc.edu> writes: > > > Resubmission of a bare bones bits implementation. > > > > There is no bits.dll on any Windows version I've checked. Where does > > this dll come from? > It is an extra download, but requires a WGA check. Argh! My bad. I just finished looking into this a bit more and here is my current understanding. You can download "bits" from Microsoft, but I don't think you are going to get a bits.dll out of it. The dll that I'm working on is intended to stand in for the collection of dlls available at http://support.microsoft.com/?kbid=923845, although most Windows users should already have the dlls: Qmgr.dll -> Very old version of bits that appears to be heading towards deprecation. Bitsprx2.dll -> Base version of bits that I'm trying to implement for wine. Bitsprx3.dll -> Version 2.0 of bits adding features to the base version (gotta love the off by one numbering scheme!). Bitsprx4.dll -> Newest extensions to bits available on some systems. As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the "prx" in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems. My understanding of proxies is that they allow "cross-apartment access" to a COM object. Ideally, I'd like to first get in process support of bits (CLSCTX_INPROC_SERVER object instantiation), and then worry about support across apartments. I am new to both COM and Wine and I may be a bit off in my understanding of some of these points. I would love any advice on how to get my current code in shape for Wine. In particular, should I provide a full proxy version of bits and resubmit it as Bitsprx2.dll or should I introduce basic functionality first, perhaps through bits.dll or something else, and then jump in on the proxy code. Thanks for the advice! -Roy

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Chris Morgan

> >> > >> The right way is to use XInput, and work with the X.org guys to fix > >> what's necessary to make it work for our needs. > >> > > I don't see how will that solve (c,d,f,g)? Also how long should we wait on > > that? Year? 5 years? I looked at the current Xorg source and it still > > explicitly forbidding opening of the mouse and keyboard devices. Yet some > > one mentioned they would change that. > > > > I'm talking about solutions right now, so we can move on and fix other > > related issues, not sit and wait for some one to give us what we need. > > We can always send patches to the projects for the things we would like > to see improved support. That was the case for kernel, gnome, freetype, > binutils, cygwin, mingw, and many others. > > -- I'd suggest we see if we can get someone from X.org involved in the discussion. While this wouldn't result in a fix today it would certainly let us get cooperation which is likely to result in a better fix. We might have to wait half a year for the full fix to get out there but we can always provide a short term work around and see if we can't run-time detect the improved correct way of doing it. Chris

Sept. 27, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Juan Lang

Hi Konstantin, > I have one more question. To add realization of new function, I can add it in > struct WNetProvider? For example: > > typedef struct _WNetProvider (snip) > PF_NPGetResourceInformation getResourceInformation; //my added function > } WNetProvider, *PWNetProvider; > > It is correct? Yes, precisely correct. --Juan

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Stefan Dösinger

Am Donnerstag, 27. September 2007 17:23:42 schrieb Vitaliy Margolen: > Stefan Dösinger wrote: > > 1) Multiple Mice. If there are 2 mouse devices, the X server manages them > > and combines them to one core pointer. These configurations are pretty > > common, for example on laptops with touchpad + usb mouse. > > This is true, each mouse will have it's own device. However I have never > seen a single person who used 2 or more mice while playing games <g> I do That's the great thing about laptops, at least when playing Battlefield 1942. You can keep an aircraft controlled with one hand, but for serious fighting you need the real mouse. Imagine a LAN Party, running bf1942, some pizza next to you. With the thumb on the touchpad and the WASD keys, you can take off with a plane and steer to the battle, while the right hand is free to grab a glass or some pizza. Yes, it makes the keyboard and mouse oily and there's a risk to poor liquid over the laptop, but it works with the current dinput code :-) > Not true. That's what so great about evdev driver - it's unified. > Everything is handled by the kernel, and we get common interface to things > like axis movement and buttons. I have tested this with USB and PS/2 mouse > - works properly in each case. Should all mouse types create a event device node? Maybe I've done something wrong on my new laptop. On the old laptop, the touchpad had such a node, on the new one it doesn't.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Dmitry Timoshkov

"Vitaliy Margolen" <wine-devel(a)kievinfo.com> wrote: > Alexandre Julliard wrote: >> Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: >> >>> Anything else I missed? Are there are any better ways to solve these >>> problems? Any other ways at all? >> >> The right way is to use XInput, and work with the X.org guys to fix >> what's necessary to make it work for our needs. >> > I don't see how will that solve (c,d,f,g)? Also how long should we wait on > that? Year? 5 years? I looked at the current Xorg source and it still > explicitly forbidding opening of the mouse and keyboard devices. Yet some > one mentioned they would change that. > > I'm talking about solutions right now, so we can move on and fix other > related issues, not sit and wait for some one to give us what we need. We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others. -- Dmitry.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Anything else I missed? Are there are any better ways to solve these >> problems? Any other ways at all? > > The right way is to use XInput, and work with the X.org guys to fix > what's necessary to make it work for our needs. > I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that. I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need. Vitaliy.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Vitaliy Margolen

Stefan Dösinger wrote: > 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and > combines them to one core pointer. These configurations are pretty common, > for example on laptops with touchpad + usb mouse. This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games <g> > 2) Different devices: An USB mouse creates a /dev/input/eventX node, but other > devices, like my synaptics touchpad do not. In the worst case we need a > driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, > logitech, ... Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse - works properly in each case. Vitaliy

Sept. 27, 2007

Re: WineD3D surface management cleanup

by Mirek Slugeň

Sept. 27, 2007