December 2005 - Wine-Devel - list.winehq.org

Re: WINE 0.9.3 and Photoshop 7 & CS

by Vitaliy Margolen

Saturday, December 10, 2005, 2:47:43 PM, Aleksey wrote: > Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop > 7. Photoshop gave me a hardware error. I thought, no problem, I'll > just reinstall it, same result. Then I reconfigured WINE using > winetools and tried again, same thing. Here is what I got in the > Terminal when running Photoshop 7: > fixme:actctx:QueryActCtxW stub! > fixme:font:WineEngRemoveFontResourceEx :stub > fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de2c,0x00000000), stub! > fixme:win:EnumDisplayDevicesW > (L"\\\\.\\DISPLAY1",0,0x7fa7de2c,0x00000000), stub! > fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e694, 0x7fa7e1ac, > 0x7fa7e6f4, 0x7fa7e704 ) stub > fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de34,0x00000000), stub! > fixme:win:EnumDisplayDevicesW > (L"\\\\.\\DISPLAY1",0,0x7fa7de34,0x00000000), stub! > fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e69c, 0x7fa7e1b4, > 0x7fa7e6fc, 0x7fa7e70c ) stub > err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be > called for simple PIDL's only! > fixme:font:WineEngRemoveFontResourceEx :stub > fixme:font:WineEngRemoveFontResourceEx :stub > Then I tried installing Photoshop CS, knowing that it worked fine with > 0.9.2. Photoshop CS told me that certain required files was missing, > but I forgot to get down the results from the Terminal. After that I > downgraded to WINE 0.9.2 and both versions of Photoshop work great. > A little side note: ImageReady 7 works great under 0.9.3, I did not > test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but > ImageReady CS crashes. Good info thanks. But I thing that at least a regression test is due here...

Dec. 10, 2005

WINE 0.9.3 and Photoshop 7 & CS

by Aleksey

Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop 7. Photoshop gave me a hardware error. I thought, no problem, I'll just reinstall it, same result. Then I reconfigured WINE using winetools and tried again, same thing. Here is what I got in the Terminal when running Photoshop 7: fixme:actctx:QueryActCtxW stub! fixme:font:WineEngRemoveFontResourceEx :stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de2c,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de2c,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e694, 0x7fa7e1ac, 0x7fa7e6f4, 0x7fa7e704 ) stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de34,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de34,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e69c, 0x7fa7e1b4, 0x7fa7e6fc, 0x7fa7e70c ) stub err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be called for simple PIDL's only! fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub Then I tried installing Photoshop CS, knowing that it worked fine with 0.9.2. Photoshop CS told me that certain required files was missing, but I forgot to get down the results from the Terminal. After that I downgraded to WINE 0.9.2 and both versions of Photoshop work great. A little side note: ImageReady 7 works great under 0.9.3, I did not test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but ImageReady CS crashes. God Bless. - Aleksey

Dec. 10, 2005

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Eric Pouech

Robert Reif wrote: > Eric Pouech wrote: > >>> We never "load" a driver more than once. Winecfg calls winmm >>> OpenDriver which will only ever load a single instance of the driver >>> into memory. Subsequent OpenDriver calls will reference the existing >>> in memory driver. Wine models the single instance device driver that >>> supports multiple physical devices. >> >> >> what you end up with is a situation where: >> - two calls to OpenDriver for the same driver will provide: >> + a separate HDRVR (one for each call) >> + the same driver ID at the driver level >> + an implementation at the driver level with a single data state >> shared across the two HDRVR instance > > > This is true and is also how windows works with the tests I have done > with a user installable driver. The reason this works is because I am > only accessing the static driver configuration (GetNumDevs and > GetDevCaps). I have no intention of actually using the drivers for > anything else because they are not designed for that. Here again, I'm not saying you *will* badly use the drivers (and your current code doesn't). But, the way you changed things can let someone do it (or a windows app), and we have no protection for that. > I am opening the > driver, not the individual devices (WaveIn, WaveOut, ...). I agree that > under normal circumstances, bypassing winmm and accessing the driver > directly is the wrong thing to do because winmm is responsible for > coordinating things, but in this case and only this case (accessing > static driver configuration) it is OK. > The real way to do this would be > to have each driver register itself with the PnP manager and then we > could interface with it. I am using winmm (OpenDriver) for loading and > configuring the drivers which is perfectly legal to do. Only using > LoadLibrary and xxxMessage to get the number of devices and their > capabilities is the thing that is really questionable. A PnP manager > would fix that in the long term. My concern here is that your changes require a driver to be opened (thru OpenDriver) twice (one time by winecfg, a second time at winmm startup). IMO, the target should be to implement the audio configuration in winecfg without requiring to open twice a driver. It's likely to boil down to let winmm do the core job. > I guess I have a terminology misunderstanding here and should probably > reread my driver documentation. I would like to see this class of > driver implemented so that only a single device shows up for a physical > device (multi channel cards being the exception). Each wave device > could be opened more than once. Each open would dynamically open a > connection to the mixing server. In this case with a single physical > sound card, waveOutGetNumDevs will always return 1 and a waveOutOpen > will always succeed (within mixer server limitations). This is how > windows works on versions that have kmixer (98SE up). yup. this is also the way to go for a unified wine audio driver by the way. A+ -- Eric Pouech

Dec. 10, 2005

Re: Polish translations

by Tony Lambregts

Biuro Fornet MK wrote: > Dear Sirs. > > I represent Polish company. We start currently a project - kind of > computer helpdesk, where we advice (because of lot of reasons) moving > to Linux to our customners. > > While they are in most cases very sceptic about this, your Wine makes > a great help for us. Unfortunately, the English language is still the > biggest barrier for Polish customers. > > Thats why we would like to contribute to Wine development and > spreading a "good hope" :) in the way we can afford right now. > > I would like to propose: > 1. full translation of your WWW page to Polish, and setting this > "localisation" at our www host.server. You can browse the source for the main wine site is here: http://cvs.winehq.org/cvsweb/lostwages/ It should be possible to translate this site and bugzilla as well, both have been built with translation in mind the AppDB is much harder and I do not know about the wiki. export CVSROOT=:pserver:cvs(a)cvs.winehq.org:/home/wine cvs login (password cvs) cvs checkout lostwages Mail patches to:wine-patches(a)winehq.org with the prefix [LOSTWAGES] so the website maintainer can easily see them. > 2. full translation - or help if anyone started, although i cant find > any note on your site - of Wine software: GUI/API/DOCS/help docs into > Polish. 2.1 I think you get more bang for you buck with this stuff. Translating the documentation (at least the users guide and FAQ) is a good idea. cvs -z3 -d:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/wine co -P docs When prompted for a password press the enter key. A subdirectory named docs will be created. Mail patches to:wine-patches(a)winehq.org with the prefix [WINEDOCS] so the maintainer of the documentation can easily see them. 2.2 Also keeping the resources files (*.rc), for winecfg at the very least, up to date would be very much apreciated by Polish users. There is also the README in the root of wine. export CVSROOT=:pserver:cvs(a)cvs.winehq.org:/home/wine cvs login (password cvs) cvs checkout wine. [snip stuff about customer support] I would start with translating the documentation and resource files before tackling the web site(s) but that is up to you. -- Tony Lambregts

Dec. 10, 2005

Problems with winetest ?

by Paul Vriens

Hi, I haven't seen a new release of winetest on http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ since the 1st of december. Anyone ? Paul.

Dec. 10, 2005

Re: GCC 4.0.1 / WINE bug?

by Evil

peter(a)piments.com wrote: > Anyone working on getting wine to work on gcc-4.xx? Not I. It's not really a showstopper for me since it only affects Dreamweaver and I can compile with 3.4 to get around it at the moment. I wouldn't be worried about it unless other apps have problems too. I'll retest when newer gcc (to determine if it's strictly a 4.01 bug) sometime down the road when I have more time, but it won't be anytime soon. -J

Dec. 10, 2005

Re: OpenGL regression

by Stefan Dösinger

Am Freitag, 9. Dezember 2005 15:25 schrieb Huw D M Davies: > My guess is Stefan's XServer is glx version 1.2 (Stefan glxinfo will > comfirm this). Correct

Dec. 10, 2005

feedback wanted from arts, esound and jack sound driver users.

by Robert Reif

Is anyone using the arts, esound or jack sound drivers for non trivial use? By non trivial, I mean more than one application or more than a single device. If so, I am interested in getting information on the software you are using and how it is using the drivers. Would redesigning these drivers to show up as a single device per physical device which allowed being opened more than once be a problem?

Dec. 10, 2005

Re: GCC 4.0.1 / WINE bug?

by Marcus Meissner

On Sat, Dec 10, 2005 at 11:43:38AM +0100, peter(a)piments.com wrote: > Anyone working on getting wine to work on gcc-4.xx? It works fine on gcc 4.0, gcc 4.1 and also current 4.2 development branch. Ciao, Marcus

Dec. 10, 2005

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Robert Reif

Eric Pouech wrote: >> We never "load" a driver more than once. Winecfg calls winmm >> OpenDriver which will only ever load a single instance of the driver >> into memory. Subsequent OpenDriver calls will reference the existing >> in memory driver. Wine models the single instance device driver that >> supports multiple physical devices. > > what you end up with is a situation where: > - two calls to OpenDriver for the same driver will provide: > + a separate HDRVR (one for each call) > + the same driver ID at the driver level > + an implementation at the driver level with a single data state > shared across the two HDRVR instance This is true and is also how windows works with the tests I have done with a user installable driver. The reason this works is because I am only accessing the static driver configuration (GetNumDevs and GetDevCaps). I have no intention of actually using the drivers for anything else because they are not designed for that. I am opening the driver, not the individual devices (WaveIn, WaveOut, ...). I agree that under normal circumstances, bypassing winmm and accessing the driver directly is the wrong thing to do because winmm is responsible for coordinating things, but in this case and only this case (accessing static driver configuration) it is OK. The real way to do this would be to have each driver register itself with the PnP manager and then we could interface with it. I am using winmm (OpenDriver) for loading and configuring the drivers which is perfectly legal to do. Only using LoadLibrary and xxxMessage to get the number of devices and their capabilities is the thing that is really questionable. A PnP manager would fix that in the long term. >> >> Jack and esound are fundamentally flawed because they create 10 >> virtual sound cards that all reference a single physical device. >> This doesn't take into account multiple devices. The proper way to >> implement this is to allow multiple opens of the same device (just >> like windows). That way two or more programs can open one card and >> other programs can open another card and none of the programs are >> aware or even care about the others. I have multiple sound cards and >> headsets in a single computer for music and VoIP and I need a way for >> individual programs to work with specific devices (just like in >> windows). > > we do agree here that jack & esound (like any interface with > integrated audio mixer) should be multiple instance drivers and not > single instance ones. > I guess I have a terminology misunderstanding here and should probably reread my driver documentation. I would like to see this class of driver implemented so that only a single device shows up for a physical device (multi channel cards being the exception). Each wave device could be opened more than once. Each open would dynamically open a connection to the mixing server. In this case with a single physical sound card, waveOutGetNumDevs will always return 1 and a waveOutOpen will always succeed (within mixer server limitations). This is how windows works on versions that have kmixer (98SE up).

Dec. 10, 2005