Re: How does --with-wine64 work?
On Tue, Dec 8, 2009 at 1:01 AM, Maarten Lankhorst
wrote:
> Austin English schreef:
>>
>> Vincent asked me to get add a --with-wine64 option to my build script.
>> I was testing around, and can't seem to get it to work:
>> $ mkdir - p $HOME/wine{32,64}
>> $ cd $HOME/wine64
>> $ ~/wine-git/configure --enable-win64
>> $ make -j4
>> $ cd $HOME/wine32
>> $ ~/wine-git/configure --with-wine64=~/wine64
>> ...
>>
>>>
>>> checking for the directory containing the Wine tools... configure: error:
>>> could not find Wine tools in ~/wine64/
>>>
>>
>> ~/wine-git/configure --with-wine64=~/wine64/tools/
>> ...
>> checking for the directory containing the Wine tools... configure:
>> error: could not find Wine tools in ~/wine64/tools/
>>
>> What am I missing? Perhaps it needs to be installed somewhere first?
>>
>
> Try --with-wine64=$HOME/wine64
> The ~ doesn't get expanded
I feel silly...I could have sworn I tried that. Thanks Maarten!
--
-Austin
Re: winhttp/tests: Fix test error when run as non-administrator
On 12/08/2009 12:58 AM, Juan Lang wrote: -ok(ret, "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError()); +ok(ret || GetLastError() == ERROR_ACCESS_DENIED, + "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError()); -set_default_proxy_reg_value( saved_proxy_settings, len, type ); +if (ret) +set_default_proxy_reg_value( saved_proxy_settings, len, type ); } Hi Juan, I'm not a big fan of this. In theory we can now mess up our implementation and return ERROR_ACCESS_DENIED without knowing that something is wrong as the tests will still succeed. I agree that ERROR_ACCESS_DENIED is a valid return value but I'd rather have some win_skip() or at least a skip() in there. win_skip() will work fine right now but as soon as we implement access rights to the registry (and multi-user) it should probably be a skip(). -- Cheers, Paul.
Re: How does --with-wine64 work?
Austin English schreef:
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
checking for the directory containing the Wine tools... configure: error: could
not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/
What am I missing? Perhaps it needs to be installed somewhere first?
Try --with-wine64=$HOME/wine64
The ~ doesn't get expanded
Re: Very long printernames and test failures
On 12/07/2009 11:38 PM, Detlef Riekenberg wrote: On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote: Some test failures are shown on boxes with long printernames, for example: http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_153/winspool.drv:info.html And indeed if I create a local printer with a very long name the cutoff is one bigger than what the test is currently doing. The attached patch fixes that. I cant find a reason, why Windows is using 2 character for the terminating zero. This looks like an Windows bug. I expect a different behavior on older Windows versions. The best test would probably to add a printer in the tests An addprinter-test with a medium sized name is in my tree, but it needs some fixes in our Implementation. I'm testing with AddPrinter in localspl, but the 16Bit separation got a higher priority. Any thoughts? Manual creating printers with the specific length (CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy, but I cant do that before the next weekend. I will add some printers with names of different length to my test boxes and see what the results are. -- Cheers, Paul.
Re: Wine sound discussion summary
Hi Reif, 2009/12/8 Robert Reif : > Francois Gouget wrote: >> >> Also, as far as I know, DirectSound works on top of all our backend >> drivers. >> >> > > It works through the WAVE API on most drivers which > requires software mixing and format conversions. Even > the direct sound drivers only implement a single > hardware buffer which means that even direct sound > goes through the software mixer and format conversions. GASP, that's not such a problem that you make it out to be. Hell, winealsa even emulates a ring buffer with read calls, see f27d88e16fe.. > If any direct sound driver implemented multiple buffers > of any format, there would be no software mixing done > in the direct sound dll. Everything would just pass through > the direct sound dll directly to the driver untouched. We > would also get multiple open support since it wouldn't > matter which application the buffers came from. The dsound timer would still tick and most of the time the app would still use the crappy remixer in dsound since games use DSBCAPS_LOCSOFTWARE these days.. Even more fundamentally, our winmm drivers are crap, full of literally copied versions of wineoss, just renamed and sedded, but never maintained. Spot the similar #if 0's... The wavein/out drivers will be thrown out after we can forward to WASAPI, since the midi code is still handled in winmm afaict, a few of them will continue to live for that purpose.. Can I please have some new discussion point instead of you trying to bring up the same over and over? I'm growing tired of having to repeat myself so much..
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Peter Kovacs wrote: > I think Austin is right, stopping Hacks would slow down development. > And we need people hacking. I'm not against hacks. I'm against dirty hacks, especially going into bugzilla! What's a dirty hack? Something that adds commented out code, comments out original code instead of removing / changing it, have loads of white-space changes all over the place. Touches (in any way) parts that have nothing to do with the actual problem. In short - something that person didn't even bothered to look over and clean up before making it public. If anyone still wants to maintain that sort of code - do it outside of Wine's bugzilla. There are loads of free git repositories where one can dump anything they pleased. Also I'm having issues with people coming to bugzilla and asking how to compile Wine, and other people trying to explain how to use patch. We have forum/mailing list/IRC/wiki for this sort of stuff. Bugzilla is for bug related information and discussions on how to fix it for example, not user noise. Please keep it that way. > There are some Ideas about splitting Hacks from patches. Easy - patches go to wine-patches. Hacks can stay in bugzilla/private GIT repos/wiki for long term stuff. Dirty hacks - should stay on PCs of their creators until cleaned. Vitaliy.
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 9:30 PM, Steven Edwards wrote: > This looks similar to the cross-compile build for mingw where you need > a checkout with the normal tools built for your host and then another > checkout for your target. You then run and point the target configure > at the host wine path to get the host tools. Doh I read that wrong. You had it right if it follows the same structure as the mingw port. No idea, I'll try a build here in a bit -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 7:44 PM, Austin English wrote: >> checking for the directory containing the Wine tools... configure: error: >> could not find Wine tools in ~/wine64/ > ~/wine-git/configure --with-wine64=~/wine64/tools/ > ... > checking for the directory containing the Wine tools... configure: > error: could not find Wine tools in ~/wine64/tools/ > > What am I missing? Perhaps it needs to be installed somewhere first? This looks similar to the cross-compile build for mingw where you need a checkout with the normal tools built for your host and then another checkout for your target. You then run and point the target configure at the host wine path to get the host tools. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
2009/12/8 Peter Kovacs : > I think Austin is right, stopping Hacks would slow down development. > And we need people hacking. Bugzilla is not the right place for hacks. There is a wine-hacks repository (naturally, completely unsupported by WineHQ). If a hack developer wants the hack to be considered seriously, wine-patches is the place to send it. > There are some Ideas about splitting Hacks from patches. I think this maybe > an aproach > to solve this. Lets see: -- snip -- > Thinking on it, it may be better put into a maintained Wikki with different > Sections to go on. Wiki has been suggested for AppDB before. It's not a solution there and it's certainly not an appropriate bug tracker. A wiki replacing bugzilla would need a *lot* more man-power from the developers/maintainers to make sure the bug pages remain relevant to the bug. It would also require all the admins to have in-depth knowledge of all facets of the bugs they are maintaining. For something like this Xinput/mouse issue, that basically means someone who's working on the Xi2 driver. For the DIB engine, it's virtually impossible. > Closed Discussions can be deleted. This does not account for regressions. > If some real approach is found all Info can be back posted into Bugzilla by > some "Officer". > With that a solution is accepted and likely to enter the main tree when ready. > The Idea seems to be quite flexible, but maybe it won't be structured enough. > Which means > more work for Maintainers (I would install community maintainers :( *sight* > Maybe that Idea > is not good enough, what do you think? The problem here is that community maintainers are much less likely to understand the bugs than the devleopers. For AppDB, it's ideal, as maintainers are people who run the apps and know what to expect. For Bugzilla (or any other bug tracker), only developers can be truly effective maintainers - and not just any developers, but devlopers who have or are working on related components.
Re: Wine sound discussion summary
Francois Gouget wrote: Also, as far as I know, DirectSound works on top of all our backend drivers. It works through the WAVE API on most drivers which requires software mixing and format conversions. Even the direct sound drivers only implement a single hardware buffer which means that even direct sound goes through the software mixer and format conversions. If any direct sound driver implemented multiple buffers of any format, there would be no software mixing done in the direct sound dll. Everything would just pass through the direct sound dll directly to the driver untouched. We would also get multiple open support since it wouldn't matter which application the buffers came from. OpenAL and pulseaudio probably have the capabilities to implement a direct sound driver that supports multiple opens and mixing of multiple streams of different formats which would bypass the software mixing and format conversion path in the current direct sound dll implementation but I guess we will never know. Unfortunately OSS and alsa don't except under very limited conditions (if the drivers implemented it which they don't).
Re: Wine sound discussion summary
On Mon, 7 Dec 2009, Robert Reif wrote: [...] > Can we drop all current audio drivers now that don't have midi? > Any driver that doesn't implement the complete winmm API and > direct sound shouldn't be in the current tree anyway. I don't see why drivers that don't support MIDI should be dropped. Lack of MIDI support does not hamper games, media players and email arrival notifiers. So a driver without MIDI support is still useful for a good 90% of the applications out there. As for not implementing the 'complete winmm API' I'm not sure what you mean. Also, as far as I know, DirectSound works on top of all our backend drivers. -- Francois Gouget http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Hi again, Vitaliy this are great news. I will see if I can read a bit more about XI2. :-D Keep going. You will crack that Bug. Ill try to help if i can steal Time from somewhere. But Honestly I am no Hacker. So don't expect to much of me. I am happy if I can solve the hacks vs. patch problem :P As I see in the reaction this is a Problem that does exist in other Bugs too. (Surprise! ;) ) I think Austin is right, stopping Hacks would slow down development. And we need people hacking. But we also need clear, and on topic Bugzilla or winewill clutter to much. (My believe) It is at least hard for me to pick the interesting Posts in Bugzilla. Or even the Interesting Bugs. Don't know but I see a lots of App based Bug reports. They get collected it one real Bug report. Which is sometimes just the first one that got reported. Hard to search for someone not tracking Bugs. (Aside Most ppl dont look enough I bet ;) ) There are some Ideas about splitting Hacks from patches. I think this maybe an aproach to solve this. Lets see: Looking at the Mouse "escape" Bug. We have 290 Post. Haven't count but going after my feeling at least half of the post belongs more in a Forum then in a Bug tracker. It makes technical Facts realy Hard to follow. I think Bugzilla is really not suitable for Hacker Approach. Bugzilla thinks more in terms where people actually know what they doing. And in case of wine even its best developer are shouting in the dark sometimes I bet. If you look at the Bugzilla post, you'll find: - Tech info - Approach Ideas - Discussions - Affected Infos - Instructions for installing and Bugfixing - A lot of Hacks / patches This is hell of different information unstructured in Bugzilla. Thinking on it, it may be better put into a maintained Wikki with different Sections to go on. There could be a menu which links people to the basic Instructions. It can hold the Hacks. It can serve as Link Collection and Info. And most Important of all it can be overhauled. Closed Discussions can be deleted. If some real approach is found all Info can be back posted into Bugzilla by some "Officer". With that a solution is accepted and likely to enter the main tree when ready. The Idea seems to be quite flexible, but maybe it won't be structured enough. Which means more work for Maintainers (I would install community maintainers :( *sight* Maybe that Idea is not good enough, what do you think? Hmm at least in vision it would give a workflow. Any more Ideas on this? And what should we do with the people on the Bug. Some saying the same within the bug itself. 8 Posts today. Shall I collect them and bring them here? Maybe more Brains come up with more approaches. I hesitate to do so: To much cooks corrupt the porridge. :) Regards Peter > On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen > wrote: >> Peter Kovacs wrote: >>> Now Vitaliy Margolen actively stopped the >>> maintenance of this workarounds (in the bug called dirty hacks.), by >>> marking the patches obsolete and changing title. >> Yes, tried to, of course I can't stop anyone from hacking and posting their >> work, even on the same bug. All I can do is ask not to. > > Then where do you propose people put that work? > >> I did this because all of those workarounds (with exception of few) done by >> people, who don't understand the entire scope of the problem. They've >> touched (and broke) parts of DInput that have nothing to do with the >> problem. I've already seen several invalid bug reports that were caused by >> some of this hacks. > > This has happened with other bugs/patches too, e.g., the DIB > engine/the msi hack for photoshop/etc. > >>> Is it right to have no Dirty Hack solution which just works? >> Then those hacks called proper patches. But they have to work for >> everything. A "Dirty Hack" is something that avoids a problem for one set of >> apps and totally breaks things for everything else. > > Considering the main ones use a environmental variable to enable the > hack, the risk of that is greatly reduced. > > I'm not saying these aren't hacks. By all means, they are. But users > need/want a solution, so let them have it. Perhaps I'm a bit biased > though, since the last game I played (Borderlands) needed this hack, > so I've also been affected ;-). > > -- > -Austin
How does --with-wine64 work?
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
> checking for the directory containing the Wine tools... configure: error:
> could not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/
What am I missing? Perhaps it needs to be installed somewhere first?
--
-Austin
Re: Wine sound discussion summary
Maarten Lankhorst wrote: The lack of an accelerated dsound interface isn't that big, just means I wish accelerated direct sound had been a big issue. Both OSS and alsa theoretically could support it under very limited circumstances but there was no guarantee that it could be supported under all circumstances. With full direct sound hardware acceleration in the low level driver, all software mixing would be bypassed in the current direct sound implementation. Direct sound would just forward calls from the application to the driver. That's where the direct in direct sound originally came from in the old days.
Re: winetest + pbuffer + nvidia 190.18 drivers = X crash
On Sun, Nov 29, 2009 at 11:37 PM, Austin English wrote: > On Sun, Nov 29, 2009 at 5:45 AM, Henri Verbeet wrote: >> 2009/11/20 Austin English : >>> Been happening for a few days...not sure what triggered it, but when >>> coming back from work I see my login screen, which explains the lack >>> of 64-bit tests/appinstall results. I don't know if any of the D3D >>> guys could take a look, but I'd appreciate it... >>> >> What does your Xorg log look like? > > Doesn't seem to want to crash now...strange. I'll keep an eye on it > and if it happens again I'll get the log. Updated to 195.22 drivers, and it reappeared. Though it may have been disabled glsl that did it. I tried running those configs again, but no crash, so perhaps a race? Backtrace: 0: /usr/bin/X(xorg_backtrace+0x26) [0x4f00c6] 1: /usr/bin/X(xf86SigHandler+0x41) [0x4852c1] 2: /lib/libc.so.6 [0x7f349cbb4530] 3: /usr/bin/X [0x4b674a] 4: /usr/bin/X [0x4b6b37] 5: /usr/bin/X [0x49f17f] 6: /usr/bin/X [0x49f355] 7: /usr/bin/X(RRCrtcSet+0x162) [0x51d092] 8: /usr/bin/X(ProcRRSetScreenConfig+0x508) [0x522a88] 9: /usr/bin/X(Dispatch+0x394) [0x44e174] 10: /usr/bin/X(main+0x3b5) [0x434085] 11: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f349cb9fabd] 12: /usr/bin/X [0x433509] Saw signal 11. Server aborting. I've installed xserver-xorg-core-dbg, so if it crashes again, should have a better log. -- -Austin Xorg.0.log.old Description: application/trash
Re: Wine sound discussion summary
Hello, 2009/12/8 Robert Reif : ... > Can we drop all current audio drivers now that don't have midi? > Any driver that doesn't implement the complete winmm API and > direct sound shouldn't be in the current tree anyway. I wish, but aj wouldn't even let me delete winenas.drv that has been obviously broken for many years, even after I pointed out it even failed 'play test sound' in winecfg after you set it up. I guess it has to wait until after wine7audio hits. The lack of an accelerated dsound interface isn't that big, just means 1 more copy of the primary buffer kept around, wine dsound should handle it correctly, tested on windows some time back too. Our dsound won't run on windows though, mingw gets horribly confused by directsoundcrea...@24 and directsoundcre...@24, and no matter what I tried, either dynamic linking or static linking would fail (or both..) Cheers, Maaten.
Re: Wine sound discussion summary
Francois Gouget wrote: On Sun, 6 Dec 2009, Stefan Dösinger wrote: [...] So you mean keeping the existing infrastructure around just for midi and have something entirely different for the rest of the audio features? That might nt be too bad in that we could still drop all the current current winmm audio backends that don't support Midi. At first glance: wineaudioio, wineesd, winejack, and winenas. So we'd just keep the Midi portion of winealsa, winecoreaudio and wineoss. Can we drop all current audio drivers now that don't have midi? Any driver that doesn't implement the complete winmm API and direct sound shouldn't be in the current tree anyway.
Re: Very long printernames and test failures
On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote: > Some test failures are shown on boxes with long printernames, for example: > > http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html > http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_153/winspool.drv:info.html > > And indeed if I create a local printer with a very long name the cutoff > is one bigger than what the test is currently doing. > > The attached patch fixes that. I cant find a reason, why Windows is using 2 character for the terminating zero. This looks like an Windows bug. I expect a different behavior on older Windows versions. > The best test would probably to add a printer in the tests An addprinter-test with a medium sized name is in my tree, but it needs some fixes in our Implementation. I'm testing with AddPrinter in localspl, but the 16Bit separation got a higher priority. > Any thoughts? Manual creating printers with the specific length (CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy, but I cant do that before the next weekend. -- By by ... Detlef
Re: Wine sound discussion summary
On Mon, Dec 7, 2009 at 11:00 PM, Ken Thomases wrote: > On Dec 6, 2009, at 10:08 AM, Stefan Dösinger wrote: > >> Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander: >>> This audio engine is quite similar to >>> pulseaudio and it offers functionality like per stream volume which >>> normal APIs like oss/alsa/openal don't offer, so these APIs would map >>> better to a sound server than to a standard library. >> I am wondering: Does CoreAudio on OSX offer similar features? Or do we need >> a sound server there as well if we want to support them? > > I'm not particularly familiar with any audio API other than Core Audio, so > I'm not sure how comparable the feature sets are, but per-stream volume and > such are available. > > Core Audio is not particularly close to the hardware. I think it's roughly > similar to a sound server type of architecture. There's no problem with > multiple apps producing audio, or anything like that. It's pretty > "virtual"/abstracted. > > > On Dec 7, 2009, at 5:15 AM, Roderick Colenbrander wrote: > >> I have no idea to what degree other implemenations of OpenAL will pick up >> these changes and >> what the quality of the (closed) OSX branch is. > > What makes you say the OS X branch is closed? > > svn://connect.creativelabs.com/OpenAL/trunk/OpenAL-MacOSX > > Apple has links at http://www.opensource.apple.com/ to the OpenAL that ships > with each version of Mac OS X, although Creative seems to have reorganized > their site and Apple's links are dead. Still, the above SVN URL should be > current. > > -Ken > The svn indeed contains their current code. Although it seems to be from 2006 and it looks like it had no recent activity. What worries me is that this is really a different OpenAL implementation (it is all c++ and shares no code with the other libs). I'm worried about the future of OpenAL on OSX though. Roderick
Re: Wine sound discussion summary
On Dec 6, 2009, at 10:08 AM, Stefan Dösinger wrote: > Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander: >> This audio engine is quite similar to >> pulseaudio and it offers functionality like per stream volume which >> normal APIs like oss/alsa/openal don't offer, so these APIs would map >> better to a sound server than to a standard library. > I am wondering: Does CoreAudio on OSX offer similar features? Or do we need a > sound server there as well if we want to support them? I'm not particularly familiar with any audio API other than Core Audio, so I'm not sure how comparable the feature sets are, but per-stream volume and such are available. Core Audio is not particularly close to the hardware. I think it's roughly similar to a sound server type of architecture. There's no problem with multiple apps producing audio, or anything like that. It's pretty "virtual"/abstracted. On Dec 7, 2009, at 5:15 AM, Roderick Colenbrander wrote: > I have no idea to what degree other implemenations of OpenAL will pick up > these changes and > what the quality of the (closed) OSX branch is. What makes you say the OS X branch is closed? svn://connect.creativelabs.com/OpenAL/trunk/OpenAL-MacOSX Apple has links at http://www.opensource.apple.com/ to the OpenAL that ships with each version of Mac OS X, although Creative seems to have reorganized their site and Apple's links are dead. Still, the above SVN URL should be current. -Ken
Re: 2/2 WGL: move some traces to winediag
On Mon, Dec 7, 2009 at 10:17 PM, Henri Verbeet wrote: > 2009/12/7 Roderick Colenbrander : >> Use this version instead. The last version contained some updates to >> the wined3d winediag patch. >> > Sending this to winediag does mean it won't show up in +wgl traces > anymore. Do we want that? > I have been thinking hard on where it belongs. If we say +winediag should give us 'sufficient' info about a Wine setup and potential problems then it belongs here. Such info would also belong in a +wgl log or later on similar info in the respective debug channels of other places like direct3d, dsound and so on. Perhaps there should be a special way to have some messages in BOTH channels? I think it would be better to drop the patch in its current form. Roderick
Re: 2/2 WGL: move some traces to winediag
2009/12/7 Roderick Colenbrander : > Use this version instead. The last version contained some updates to > the wined3d winediag patch. > Sending this to winediag does mean it won't show up in +wgl traces anymore. Do we want that?
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen wrote: > Peter Kovacs wrote: >> Now Vitaliy Margolen actively stopped the >> maintenance of this workarounds (in the bug called dirty hacks.), by >> marking the patches obsolete and changing title. > Yes, tried to, of course I can't stop anyone from hacking and posting their > work, even on the same bug. All I can do is ask not to. Then where do you propose people put that work? > I did this because all of those workarounds (with exception of few) done by > people, who don't understand the entire scope of the problem. They've > touched (and broke) parts of DInput that have nothing to do with the > problem. I've already seen several invalid bug reports that were caused by > some of this hacks. This has happened with other bugs/patches too, e.g., the DIB engine/the msi hack for photoshop/etc. >> Is it right to have no Dirty Hack solution which just works? > Then those hacks called proper patches. But they have to work for > everything. A "Dirty Hack" is something that avoids a problem for one set of > apps and totally breaks things for everything else. Considering the main ones use a environmental variable to enable the hack, the risk of that is greatly reduced. I'm not saying these aren't hacks. By all means, they are. But users need/want a solution, so let them have it. Perhaps I'm a bit biased though, since the last game I played (Borderlands) needed this hack, so I've also been affected ;-). -- -Austin
Re: Please Review - Revised OS X Application Bundle patch
On Mon, Dec 7, 2009 at 12:46 PM, Mike Kronenberg wrote: > This can be easily done, I've integrated lately similar functionality in > WineBottler. > If You already have the png only the sipping part of this little script is > needed. > > createIconsFromExe.sh Oh sure, we can do it now, but like I just said to Joerg, just because we can do it now does not mean that Alexandre will let us do it now. Winemenubuilder really needs to be cleaned up and abstracted as we go along in this process. 1. Generic App Bundle Support (my patch does this) 2. Pretty Icon support (next on the list) 3. Associations At each step along the way, Alexandre is going to want it to at least be cleanly separated so it can be re-factored. Just look at how I had to hook in to the main winemenubuilder file and bail out on unsupported features. It's intimately tied to xdg which is good for the Linux side but sucks for us, and what if tomorrow someone invents something better on Linux for menus or associations? It really needs to be abstracted the right way. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Please Review - Revised OS X Application Bundle patch
On 07.12.2009, at 18:08,
wrote:
> .png are created today in ~/.local/share/icons/ by Wine on Mac and
> Linux. (It used to be .xpm in the past and configure must detect
> libpng). Note that .png is mere *output* from Wine because that's
> what FreeDesktop wants as input (and .xpm).
> Judging from the .icns size, this looks like a non-compressed format.
> There should be enough code in Wine or MacOS to turn the installer
> submitted raw icon data into whatever Mac's icon resource fork requires.
> windowscodecs need not be beinvolved IMHO (I mean it should need
> nothing that was not already present in 0.9.x).
This can be easily done, I've integrated lately similar functionality in
WineBottler.
If You already have the png only the sipping part of this little script is
needed.
createIconsFromExe.sh
#!/usr/bin/env bash
PATH_TO_EXECUTABLE=$(echo "$PATH_TO_EXECUTABLE" | sed s'/\\/\//g')
MAINICON=$(echo $(wrestool -l --type=group_icon "$PATH_TO_EXECUTABLE") | awk
'{print $2}' | sed 's/--name=//')
MAINICON=$(echo $MAINICON | sed s/\'//g)
rm /tmp/MAINICON.ico &> /dev/null
wrestool -x --type=group_icon --output=/tmp/MAINICON.ico --name=$MAINICON
"$PATH_TO_EXECUTABLE" &> /dev/null
sips -s format icns /tmp/MAINICON.ico --out "$PATH_TO_ICON" &> /dev/null
rm /tmp/MAINICON.ico &> /dev/null
Mike
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 1/6] mshtml: Forward IHTMLFrameElement::get_dispid and invoke to its content window
Jacek Caban wrote: Hi Andrew, This idea looks bad. What are you trying to fix? Test case attached. When using 'document.frames.someFrame.someVariable', Wine currently fails looking up 'someVariable' as FrameElement doesn't have a get_dispid function. This patch forwards the lookup to someFrame's content window, which holds someVariable. Andrew frame_member.tar.bz2 Description: application/bzip
Please Review - Revised OS X Application Bundle patch
Hi, >I still am not sure I understand the problem. Using start /unix should >not be required I'm sorry for the confusion. Forget everything about start /unix. I don't use it and mentioned it because there are some posts in the forum where somebody is fighting with it and the app's current directory on MacOS. What I meant is that my script does cd /to/the/dir found in a .desktop's Path= line (then uses wine app.exe like you). I found nothing like this in your patch. >Can you provide me with an example app so I can check out the >behaviour? IIRC The Alien Nations behaves differently whether you start in the apps root directory or from within the bin/ subdir where the .exe lies. IIRC some movies would not play, or load/save not work. >Sorry if it sounded offensive. It's creative hackery Here's the 100% no-hackery version: a) Run sips -i img.extension on whatever image you want (.png or not). b) Create the .command shell script with an editor. c) Using Cmd-I (Information), make it executable and copy&paste an icon image onto the tiny icon in the top left. Caveat, the icon may not be updated immediately in the Finder's view. >PNG could be made to work TODAY in some cases but not others and OS X >prefers *.icns. .png are created today in ~/.local/share/icons/ by Wine on Mac and Linux. (It used to be .xpm in the past and configure must detect libpng). Note that .png is mere *output* from Wine because that's what FreeDesktop wants as input (and .xpm). Judging from the .icns size, this looks like a non-compressed format. There should be enough code in Wine or MacOS to turn the installer submitted raw icon data into whatever Mac's icon resource fork requires. windowscodecs need not be beinvolved IMHO (I mean it should need nothing that was not already present in 0.9.x). Regards, Jörg Höhle
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
On Mon, Dec 7, 2009 at 15:41, Vitaliy Margolen wrote: > Peter Kovacs wrote: >> So how can we get a proper Fix or point people towards proper fixes? > Make Wine use Xi2 (I'm already working on it). Hopefully will have something > available before holidays. Thank you very much for your work. It has been a long time coming. With the advent of XI2 we can finally see some progress! -- Remco
Re: Wine sound discussion summary
Stefan Dösinger wrote: > A related topic: How do Joysticks connected to the gameport work(which is the > same hardware connector as MIDI). I think that a joystick already takes an > entirely different path in the Linux kernel and it doesn't get anywhere near a sound system, so we don't have to bother about it. Is that correct? Well, if you're interested... no, the gameport is *not* the same hardware connector as MIDI. A MIDI cable has a 5-pin circular DIN connector. A game port has a 15-pin D-sub connector. They're not the same thing. However, some of the pins of the original 15-pin game port were redundant. Early soundcard manufacturers decided that they could repurpose those pins, and let MIDI users use a breakout cable (from the soundcard's "custom" 15-pin connector to a standard 15-pin gameport connector and two 5-pin MIDI connectors). It was cheap, and a full-size MIDI connector probably wouldn't fit on a regular soundcard without using breakout cables anyway. And not many needed it. When gameports were provided by soundcards, then usually, the joystick interface was provided by the soundcard's drivers - although it could be in a different kernel module. After all, the joystick and the MIDI was driven by separate pieces of hardware, they just got "multiplexed" onto the same 15-pin connector through appropriate circuitry, with the assumption that the breakout cable would separate the signals again. By the time this stuff got integrated into motherboards, the multiplexed 15-pin gameport had become a standard. Yet still, two separate functional units drive the two separate sets of pins on the game port, so the kernel does see two separate hardware interfaces, controlled by separate pieces of software. So while I'm not sure you've gotten the facts completely straight, it's correct that you don't have to worry about it. And I suspect you will need ALSA to do real MIDI... I guess it's like in Windows, where wave APIs are redesigned, but if you want to do MIDI, you still need to use the exact same multimedia interface as in Windows 3.x. Just as in Linux, you can do wave with OpenAL and pulse, but for MIDI, you still need to use OSS/ALSA. I don't necessarily consider that a problem, actually. (If you play MIDI through ALSA and route it into a softsynth like timidity, then timidity could still be routed into pulseaudio, etc...)
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Peter Kovacs wrote: > Now Vitaliy Margolen actively stopped the > maintenance of this workarounds (in the bug called dirty hacks.), by > marking the patches obsolete and changing title. Yes, tried to, of course I can't stop anyone from hacking and posting their work, even on the same bug. All I can do is ask not to. I did this because all of those workarounds (with exception of few) done by people, who don't understand the entire scope of the problem. They've touched (and broke) parts of DInput that have nothing to do with the problem. I've already seen several invalid bug reports that were caused by some of this hacks. > Just stopping people to write hacks, dirty or not > will stop people reaching in more and more patches. This sole incident > wont have an effect on hole development but most bugs I followed started > with a dirty hack. And this is definitely giving the wrong impression on > wine. All of those hacks going the wrong direction. They are not solving a problem with exception of 1-2 patches which proposed solutions rejected by Alexandre. > 1) I Xorg may implement the Problem or may not. Maybe they are even not > aware(? - Haven't took a look) The Bug-tracking in wine does not contain > a Link to the Bug-tracking in Xorg. Yes they do, it's called XI2. > 2) I am betting wine - Dev has no one working on the Bug actively. You probably right. However there were some preliminary patches for initial version(s) of Xi2. Now since it's been official part of Xorg 7.5 work can continue. > So how can we get a proper Fix or point people towards proper fixes? Make Wine use Xi2 (I'm already working on it). Hopefully will have something available before holidays. > Is it right to have no Dirty Hack solution which just works? Then those hacks called proper patches. But they have to work for everything. A "Dirty Hack" is something that avoids a problem for one set of apps and totally breaks things for everything else. Vitaliy.
Re: dxgi:device tests crash on X64_64
On 12/07/2009 02:45 PM, Henri Verbeet wrote: How does the attached patch work? Both don't crash on my Win7-64 VMware box and no problems on my Win7-32 VMware box either. -- Cheers, Paul.
Re: dxgi:device tests crash on X64_64
How does the attached patch work?
diff --git a/dlls/d3d10/d3d10_main.c b/dlls/d3d10/d3d10_main.c
index 10bf533..65ce1e0 100644
--- a/dlls/d3d10/d3d10_main.c
+++ b/dlls/d3d10/d3d10_main.c
@@ -124,7 +124,7 @@ HRESULT WINAPI D3D10CreateDevice(IDXGIAdapter *adapter,
D3D10_DRIVER_TYPE driver
}
}
-hr = D3D10CoreCreateDevice(factory, adapter, flags, 0, device);
+hr = D3D10CoreCreateDevice(factory, adapter, flags, NULL, device);
IDXGIAdapter_Release(adapter);
IDXGIFactory_Release(factory);
if (FAILED(hr))
diff --git a/dlls/d3d10/d3d10_private.h b/dlls/d3d10/d3d10_private.h
index f077115..5bf59b1 100644
--- a/dlls/d3d10/d3d10_private.h
+++ b/dlls/d3d10/d3d10_private.h
@@ -179,6 +179,6 @@ HRESULT d3d10_effect_parse(struct d3d10_effect *This, const
void *data, SIZE_T d
/* D3D10Core */
HRESULT WINAPI D3D10CoreCreateDevice(IDXGIFactory *factory, IDXGIAdapter
*adapter,
-UINT flags, DWORD unknown0, ID3D10Device **device);
+UINT flags, void *unknown0, ID3D10Device **device);
#endif /* __WINE_D3D10_PRIVATE_H */
diff --git a/dlls/d3d10core/d3d10core.spec b/dlls/d3d10core/d3d10core.spec
index 9bf25b5..6569888 100644
--- a/dlls/d3d10core/d3d10core.spec
+++ b/dlls/d3d10core/d3d10core.spec
@@ -1,2 +1,2 @@
-@ stdcall D3D10CoreCreateDevice(ptr ptr long long ptr)
+@ stdcall D3D10CoreCreateDevice(ptr ptr long ptr ptr)
@ stdcall D3D10CoreRegisterLayers()
diff --git a/dlls/d3d10core/d3d10core_main.c b/dlls/d3d10core/d3d10core_main.c
index 4151dd0..7315f0e 100644
--- a/dlls/d3d10core/d3d10core_main.c
+++ b/dlls/d3d10core/d3d10core_main.c
@@ -102,13 +102,13 @@ HRESULT WINAPI D3D10CoreRegisterLayers(void)
}
HRESULT WINAPI D3D10CoreCreateDevice(IDXGIFactory *factory, IDXGIAdapter
*adapter,
-UINT flags, DWORD unknown0, ID3D10Device **device)
+UINT flags, void *unknown0, ID3D10Device **device)
{
IUnknown *dxgi_device;
HMODULE d3d10core;
HRESULT hr;
-TRACE("factory %p, adapter %p, flags %#x, unknown0 %#x, device %p\n",
+TRACE("factory %p, adapter %p, flags %#x, unknown0 %p, device %p\n",
factory, adapter, flags, unknown0, device);
d3d10core = GetModuleHandleA("d3d10core.dll");
diff --git a/dlls/d3d10core/d3d10core_private.h
b/dlls/d3d10core/d3d10core_private.h
index 35d5ed3..cc3029f 100644
--- a/dlls/d3d10core/d3d10core_private.h
+++ b/dlls/d3d10core/d3d10core_private.h
@@ -257,7 +257,7 @@ struct dxgi_device_layer
};
HRESULT WINAPI DXGID3D10CreateDevice(HMODULE d3d10core, IDXGIFactory *factory,
IDXGIAdapter *adapter,
-UINT flags, DWORD unknown0, void **device);
+UINT flags, void *unknown0, void **device);
HRESULT WINAPI DXGID3D10RegisterLayers(const struct dxgi_device_layer *layers,
UINT layer_count);
#endif /* __WINE_D3D10CORE_PRIVATE_H */
diff --git a/dlls/d3d10core/tests/device.c b/dlls/d3d10core/tests/device.c
index fb166ec..122a154 100644
--- a/dlls/d3d10core/tests/device.c
+++ b/dlls/d3d10core/tests/device.c
@@ -22,7 +22,7 @@
#include "wine/test.h"
HRESULT WINAPI D3D10CoreCreateDevice(IDXGIFactory *factory, IDXGIAdapter
*adapter,
-UINT flags, DWORD unknown0, ID3D10Device **device);
+UINT flags, void *unknown0, ID3D10Device **device);
static ID3D10Device *create_device(void)
{
@@ -38,7 +38,7 @@ static ID3D10Device *create_device(void)
ok(SUCCEEDED(hr), "EnumAdapters failed, hr %#x\n", hr);
if (FAILED(hr)) goto cleanup;
-hr = D3D10CoreCreateDevice(factory, adapter, 0, 0, &device);
+hr = D3D10CoreCreateDevice(factory, adapter, 0, NULL, &device);
if (FAILED(hr))
{
HMODULE d3d10ref;
@@ -59,7 +59,7 @@ static ID3D10Device *create_device(void)
ok(SUCCEEDED(hr), "CreateSoftwareAdapter failed, hr %#x\n", hr);
if (FAILED(hr)) goto cleanup;
-hr = D3D10CoreCreateDevice(factory, adapter, 0, 0, &device);
+hr = D3D10CoreCreateDevice(factory, adapter, 0, NULL, &device);
ok(SUCCEEDED(hr), "Failed to create a REF device, hr %#x\n", hr);
if (FAILED(hr)) goto cleanup;
}
diff --git a/dlls/dxgi/dxgi.spec b/dlls/dxgi/dxgi.spec
index d7f8aba..853d8e2 100644
--- a/dlls/dxgi/dxgi.spec
+++ b/dlls/dxgi/dxgi.spec
@@ -1,3 +1,3 @@
@ stdcall CreateDXGIFactory(ptr ptr)
-@ stdcall DXGID3D10CreateDevice(ptr ptr ptr long long ptr)
+@ stdcall DXGID3D10CreateDevice(ptr ptr ptr long ptr ptr)
@ stdcall DXGID3D10RegisterLayers(ptr long)
diff --git a/dlls/dxgi/dxgi_main.c b/dlls/dxgi/dxgi_main.c
index 489f986..ab3ed0e 100644
--- a/dlls/dxgi/dxgi_main.c
+++ b/dlls/dxgi/dxgi_main.c
@@ -224,7 +224,7 @@ static HRESULT register_d3d10core_layers(HMODULE d3d10core)
}
HRESULT WINAPI DXGID3D10CreateDevice(HMODULE d3d10core, IDXGIFactory *factory,
IDXGIAdapter *adapter,
-UINT flags, DWORD unknown0, void **device)
+UINT flags, void *unknown0, void **device)
{
struct layer_get_size_args get_size_args;
struct dxgi_device *dxgi_device;
@@ -233,7 +233,7 @@ HRESULT WINAPI DXGID3D10
Re: Wine sound discussion summary
Reece Dunn wrote: > 2009/12/7 Francois Gouget >> On Sun, 6 Dec 2009, Reece Dunn wrote: >> [...] >>> If Wine is going to go down the Windows 7 audio route, why not >>> redirect everything to pulseaudio? >> Is PulseAudio supported on Mac OS X, FreeBSD and Solaris? >> If not then we'd need an alternative for these platforms. > > http://www.pulseaudio.org/wiki/AboutPulseAudio#SupportedOperatingSystems: > * Linux (any modern distribution) > * Solaris > * FreeBSD > * NetBSD > * Native Win32 (no cygwin) ROFL. A stone age version of PA was ported half-a^Hhearted to the other OSes just to have a tick in the "portability checkbox". Doesn't mean current versions work there or are actively developed. bye michael
Re: Wine sound discussion summary
On Sun, 6 Dec 2009, Stefan Dösinger wrote:
[...]
> So you mean keeping the existing infrastructure around just for midi
> and have something entirely different for the rest of the audio
> features?
That might nt be too bad in that we could still drop all the current
current winmm audio backends that don't support Midi. At first glance:
wineaudioio, wineesd, winejack, and winenas. So we'd just keep the Midi
portion of winealsa, winecoreaudio and wineoss.
--
Francois Gouget http://fgouget.free.fr/
$live{free} || die "";
Re: dxgi:device tests crash on X64_64
2009/12/7 Paul Vriens : > If you don't mind creating that patch, be my guest. Do you have a real > Windows 64-bit box for testing? > Ok, I'll write something. I don't have any Win64 boxes at the moment, real or virtual :-\ > I don't see a crash for D3D10CoreCreateDevice() but if it's stack corruption > it could be hard to trigger at will, I guess? > Yeah.
Re: dxgi:device tests crash on X64_64
On 12/07/2009 01:51 PM, Henri Verbeet wrote: 2009/12/7 Paul Vriens: The attached does the trick. Is that what you meant? Close enough, I meant "void *arg5", but it comes down to the same thing. Note that if you're going to send a patch for this you'll need to change the prototypes and spec in dxgi and d3d10core as well. I can do that as well if you want though. Does D3D10CoreCreateDevice() have If you don't mind creating that patch, be my guest. Do you have a real Windows 64-bit box for testing? I don't see a crash for D3D10CoreCreateDevice() but if it's stack corruption it could be hard to trigger at will, I guess? -- Cheers, Paul.
Re: Wine sound discussion summary
On Mon, 7 Dec 2009, Reece Dunn wrote: [...] > > Is PulseAudio supported on Mac OS X, FreeBSD and Solaris? > > If not then we'd need an alternative for these platforms. > > http://www.pulseaudio.org/wiki/AboutPulseAudio#SupportedOperatingSystems: > * Linux (any modern distribution) > * Solaris > * FreeBSD > * NetBSD > * Native Win32 (no cygwin) Actually I did not find any libpulse or libopenal library on my Solaris 10u5 or Solaris 10 Companion DVDs. So they are both non-standard on this platform, meaning that unless Wine ships with them, then users of these platforms would have no sound. Concerning FreeBSD 7.0, neither are available as a package but both are available as a port. So FreeBSD users are unlikely to have them preinstalled but at least they have a reasonably easy and _standard_ way of installing them. -- Francois Gouget http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: dxgi:device tests crash on X64_64
2009/12/7 Paul Vriens : > The attached does the trick. Is that what you meant? > Close enough, I meant "void *arg5", but it comes down to the same thing. Note that if you're going to send a patch for this you'll need to change the prototypes and spec in dxgi and d3d10core as well. I can do that as well if you want though. Does D3D10CoreCreateDevice() have the same issue? I think the "unknown0" parameter to D3D10CoreCreateDevice() is the same thing.
Re: dxgi:device tests crash on X64_64
On 12/07/2009 12:14 PM, Henri Verbeet wrote:
2009/12/7 Paul Vriens:
When I add the following (first thing):
BOOL is_wow64;
IsWow64Process( GetCurrentProcess(),&is_wow64 );
the tests crashes at DXGID3D10CreateDevice() in create_device().
I added that IsWow64Process() just to see if I was indeed running the 64bit
version of the test.
Any idea what's going on?
It's a bit hard to say without debug information like a backtrace and
register information, but maybe the prototype for
DXGID3D10CreateDevice() is wrong and the stack gets corrupted. An easy
thing to try would be changing the type of "arg5" from DWORD to a
pointer. I'd expect similar problems with D3D10CoreCreateDevice().
The attached does the trick. Is that what you meant?
--
Cheers,
Paul.
diff --git a/dlls/dxgi/tests/device.c b/dlls/dxgi/tests/device.c
index 32e87e6..41e872e 100644
--- a/dlls/dxgi/tests/device.c
+++ b/dlls/dxgi/tests/device.c
@@ -22,7 +22,7 @@
#include "wine/test.h"
HRESULT WINAPI DXGID3D10CreateDevice(HMODULE d3d10core, IDXGIFactory *factory,
-IDXGIAdapter *adapter, UINT flags, DWORD arg5, void **device);
+IDXGIAdapter *adapter, UINT flags, DWORD_PTR arg5, void **device);
static IDXGIDevice *create_device(HMODULE d3d10core)
{
wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Hi there, I want to bring this Issue up in Development Mailinglist. This proplem is about a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I think this Bug is at the moment an Epic Fail of Open Source Development. (And needs to be solved so we get a accepted Fix somewhere someday) The Bug is Deadlocked. The Problem is in this Bug roughly spoken that in some games the Mouse movement is captured and not the real position. Now X only returns the real position. This Bug is a dependance of X (If I got it right). Since this Bug appeared people worked around this Bug by improving dirty hacks (by calculating mouse movement using weird? code), and maintaining them. And when Possible to make them switchable. Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title. The Bug exist since 2009 - 12 - 06. And has a long thread. I understand the move of Margolen here. For that you need to look at the Bug history (clicky: http://bugs.winehq.org/show_bug.cgi?id=6971). And I dont put blame on his move. But for this Bug wine needs another political solution. Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine. What I want to say, Margolens move might be technical right, but is political pretty lame. Atm I don't see any ability that the bug will be proper fixed. 1) I Xorg may implement the Problem or may not. Maybe they are even not aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg. 2) I am betting wine - Dev has no one working on the Bug actively. So how can we get a proper Fix or point people towards proper fixes? Is it right to have no Dirty Hack solution which just works? Do you think by stopping Hacks you will encourage development in what (you) think is the right solution? Where is the Xorg Link for this Problem since it is a problem interesting wine but maybe not Xorg? Before anyone asks, I don't have the Time to solve this Bug. Nor I do believe does any one of the "dirty" hackers. Or they had done it Proper by now. Thanks Listening, hope you got the Problem I want to address. I am not on the list since I develop nothing for wine. I would it appreciate it a lot, if I could stay with the discussion by keeping my email address in CC Regards Peter
Re: [PATCH 1/6] mshtml: Forward IHTMLFrameElement::get_dispid and invoke to its content window
Hi Andrew, This idea looks bad. What are you trying to fix? Jacek
Re: Wine sound discussion summary
2009/12/7 Francois Gouget > > On Sun, 6 Dec 2009, Reece Dunn wrote: > [...] > > If Wine is going to go down the Windows 7 audio route, why not > > redirect everything to pulseaudio? > > Is PulseAudio supported on Mac OS X, FreeBSD and Solaris? > If not then we'd need an alternative for these platforms. http://www.pulseaudio.org/wiki/AboutPulseAudio#SupportedOperatingSystems: * Linux (any modern distribution) * Solaris * FreeBSD * NetBSD * Native Win32 (no cygwin) They do have Mac support in progress (see the mailing list -- "pa_fdsem racy?"), but there are some issues at the moment. > That's also something that worries me a bit about OpenAL. It's meant to > be portable but I wonder how well it's supported and integrated with > each of these platforms. Note that this worry is in part caused by > ignorance, that is I don't know that it's widely used and works well on > all these platforms. Stefan said that there were some issues with the OpenAL support on Mac, and that there are some bugs on that platform (as well as bugs in the Linux driver). However, there are bugs and issues whichever API is chosen (alsa, oss, pulseaudio, openal, ...). The way I see it, each choice has its own advantages: alsa/oss/coreaudio -- midi support; direct access to audio driver jack -- low-latency performance needed for wavert interfaces openal -- 3d sound effects (dsound 3d); flexible backend pulseaudio -- user-space audio mixing and application-based volume configuration; flexible backend - Reece
Re: Wine sound discussion summary
On Mon, Dec 7, 2009 at 11:53 AM, Francois Gouget wrote: > On Sun, 6 Dec 2009, Reece Dunn wrote: > [...] >> If Wine is going to go down the Windows 7 audio route, why not >> redirect everything to pulseaudio? > > Is PulseAudio supported on Mac OS X, FreeBSD and Solaris? > If not then we'd need an alternative for these platforms. PulseAudio is around on FreeBSD and Solaris but not on OSX. > That's also something that worries me a bit about OpenAL. It's meant to > be portable but I wonder how well it's supported and integrated with > each of these platforms. Note that this worry is in part caused by > ignorance, that is I don't know that it's widely used and works well on > all these platforms. > OpenAL was designed by Loki and Creative as a cross-platform API. Since the fall of Loki Creative has continued it and also Apple has added it to OSX. The original opensource implementation which was used in Linux games didn't receive any (or else little) updates from Creative. In the end Chris has cleaned up the last Windows version of OpenAL and maintains it as 'OpenAL soft'. Officially Creative leads OpenAL but they don't seem to disclose specifications of improvements and extensions they have added. They don't seem to bother keeping all implementations in sync. Chris has added a lot of improvements to OpenAL soft and has defined new extensions. I have no idea to what degree other implemenations of OpenAL will pick up these changes and what the quality of the (closed) OSX branch is. It would be good if OpenAL became a real cross-platform standard again (for instance coordinated by Khronos who maintain OpenGL and other standards). Roderick
Re: dxgi:device tests crash on X64_64
2009/12/7 Paul Vriens : > When I add the following (first thing): > > BOOL is_wow64; > > IsWow64Process( GetCurrentProcess(), &is_wow64 ); > > the tests crashes at DXGID3D10CreateDevice() in create_device(). > > I added that IsWow64Process() just to see if I was indeed running the 64bit > version of the test. > > Any idea what's going on? > It's a bit hard to say without debug information like a backtrace and register information, but maybe the prototype for DXGID3D10CreateDevice() is wrong and the stack gets corrupted. An easy thing to try would be changing the type of "arg5" from DWORD to a pointer. I'd expect similar problems with D3D10CoreCreateDevice().
dxgi:device tests crash on X64_64
Hi Henri, I'm trying to fix at least the crashes on X64_64 for this test. The tests are done on a Windows 7 64bit VMware guest. The strange thing is that when I crosscompile the tests as is (64bit of course) the tests don't crash. When I add the following (first thing): BOOL is_wow64; IsWow64Process( GetCurrentProcess(), &is_wow64 ); the tests crashes at DXGID3D10CreateDevice() in create_device(). I added that IsWow64Process() just to see if I was indeed running the 64bit version of the test. Any idea what's going on? -- Cheers, Paul.
Re: Wine sound discussion summary
On Sun, 6 Dec 2009, Reece Dunn wrote: [...] > If Wine is going to go down the Windows 7 audio route, why not > redirect everything to pulseaudio? Is PulseAudio supported on Mac OS X, FreeBSD and Solaris? If not then we'd need an alternative for these platforms. That's also something that worries me a bit about OpenAL. It's meant to be portable but I wonder how well it's supported and integrated with each of these platforms. Note that this worry is in part caused by ignorance, that is I don't know that it's widely used and works well on all these platforms. -- Francois Gouget http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
