March 2012 - Wine-Devel - list.winehq.org

Re: Got Application cross-compiled with msvc11 for ARM running

by André Hentschel

Am 08.03.2012 17:52, schrieb Michael Stefaniuc: > On 03/08/2012 05:40 PM, André Hentschel wrote: >> Hi, >> I cross-compiled a simple Application with the preview of MSVC 11 to ARM. >> After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. >> One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. >> Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. >> >> In short: >> The good news: The ABI is compatible (to armel gnueabi) >> The bad news: no fully win32 API on ARM > Bad news? Quite the contrary. Good use case for Wine on Windows. If we get that running, true. >> Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. > 1.5.1 or 1.4.1? I don't decide that :) Maybe both ;) -- Best Regards, André Hentschel

March 8, 2012

Re: Got Application cross-compiled with msvc11 for ARM running

by Michael Stefaniuc

On 03/08/2012 05:40 PM, André Hentschel wrote: > Hi, > I cross-compiled a simple Application with the preview of MSVC 11 to ARM. > After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. > One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. > Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. > > In short: > The good news: The ABI is compatible (to armel gnueabi) > The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. > Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? bye michael

March 8, 2012

Got Application cross-compiled with msvc11 for ARM running

by André Hentschel

Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. -- Best Regards, André Hentschel

March 8, 2012

Re: [PATCH 3/3] urlmon: Use CopyBindInfo in InternetBindInfo_GetBindInfo

by Jacek Caban

Hi Piotr, On 03/08/12 13:00, Piotr Caban wrote: > - > - *pbindinfo = This->bindinfo; > - > - if(pbindinfo->szExtraInfo || pbindinfo->szCustomVerb) > - FIXME("copy strings\n"); > - > - if(pbindinfo->stgmedData.pUnkForRelease) > - IUnknown_AddRef(pbindinfo->stgmedData.pUnkForRelease); > - > - if(pbindinfo->pUnk) > - IUnknown_AddRef(pbindinfo->pUnk); > - > - return S_OK; > + pbindinfo->cbSize = sizeof(BINDINFO); Isn't caller responsible for setting this? > + return CopyBindInfo(&This->bindinfo, pbindinfo); Jacek

March 8, 2012

Building the 1.6 Release Notes as things are written.

by Scott Ritchie

So, congrats everyone, 1.4 is out and I'm very happy about it :) I wanted to thank Alexandre for his release announcement, it was very through and informative. It also looked like a lot of work. This made me wonder if we could instead build up the announcement gradually with some sort of process. For instance, if every significant feature added to a development release were put onto a wiki page, then at any point in time we could point someone there to answer a general "what does 1.5 have over 1.4?" question. Come 1.6 release time, we could just copy and edit the page as the official announcement. Thoughts? -Scott Ritchie

March 8, 2012

Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.

by Jacek Caban

Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote: > I noticed we return in this case, without initializing this variable. > Visual inspection indicates we do not seem to access the variable in > this error case, but a) better safe than sorry, and b) GCC 4.8 currently > warns about it. > > Not sure URLPOLICY_DISALLOW is the best return value, open for better > alternatives. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek

March 8, 2012

Re: [RESEND] [PATCH] winepulse: Add pulseaudio driver, v9

by Stefan Dösinger

Hi Maarten, >From a technical point of view, two things popped out: 1) configure is autogenerated by Alexandre, so you shouldn't include it in your patch. configure.ac is enough. 2) The patch doesn't apply with git-am. I don't know how much of an issue this is for AJ, but I prefer git-am over git-apply and manually committing I barely know too much about sound, so I'm leaving the rest of the tech stuff up to Joerg and Eikum. >From a user point of view, I have a previous version of that driver in my tree, and great hopes that it fixes some issues on my gaming setup that uses Pulseaudio(due to a multiseat configuration), e.g. bug 28856. The alsa route may eventually fix those bugs too, but I'm hoping for that since more than a year. So good luck with your Pulse driver, and thanks for working on this flamewar- infested stuff. Cheers, Stefan Am Donnerstag, 8. März 2012, 01:22:58 schrieb Maarten Lankhorst: > Signed-off-by: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > --- > Resending now v1.4 is released for inclusion into 1.5, no changes from v9 > > V1: Original version > V2: > - Added basic session manager bullshit > - Fixed a bunch of test failures > - Add stubs for audio volumes, fixes to make capture work > V3: > - 20% cooler > - reworked clock handling to be much more accurate > - rewrite of all the interesting parts > - only tested rendering, capture untested > V4: > - Make mixer settings global to prevent > - Start of making capture working again > V5: > - Really break capture this time, TODO!! > - Fix most rendering tests except those related volume, rendering > should not only pass tests, but also be done in a correct way > - Cleaned up channel mapping > - Fix clock going 2x as fast > V6: > - Reliability fixes > - Align buffer size to a multiple of period size > - Remove session lock, I plan to use pulseaudio calls for volume, anyhow > V7: > - Implement shared mode capture correctly > - All non-IAudioStreamVolume related tests should pass for capture and > rendering > V8: > - Add DllMain to fix valgrind complaints > - Add real and fake volume control > - Passes all tests including the ones marked todo_wine > V9: > - Rework IAudioClient::Reset, flushing is only needed for render stream. > - Add stream validity checks to IAudioClock as well > - Fix copy pasted bug from winealsa in clone_format (As reported by > KittyCat) - Validate wBitsPerSample for float format (kcat) > - Make the pulse mapping const (kcat) > - Change mix format to float (kcat) > - Fix volume comments referring to alsa instead of Pulseaudio > - Split off pulseaudio spec to waveformat to a separate function > - Disabled audioclock interpolation for now, until I determine how to do it > properly. - Call SetEvent in render callback as last function, since it > gives up time slot (as reported by Joerg) - Reworked capture logic to > always capture, since that seems to be the case on windows, when stopped we > simply drop whole packets, but keep firing the event. - Rework the logic > behind GetMixFormat, and make capture and rendering formats and periods > separate again. This is needed for example if you have 5.1 playback 44100 > with 32kHz 2 channel capture (USB microphone). - Complete the > pa_channel_position -> dwChannelMask mapping > - Use MulDiv instead of pa_bytes_to_usec or pa_usec_to_bytes in a few > places. - Rendering buffers no longer have to be a multiple of period size. > > There are 2 places that still have those calls, but in worst case it will > make a 50 ns difference for the reported device periods, while the one in > AudioClock::GetPosition is disabled until it's determined how to handle > interpolation of IAudioClock::GetPosition, if that's still going to happen. > > I believe with this I addressed all issues and comments raised in V8, > and looking forward to any constructive feedback and test results of V9. > In particular, I'm interested in XAudio2 results with windows version > set to vista or higher, so that it uses mmdevapi directly > > winmm and dsound should be able to work unmodified, but you may want > to lower ds_snd_queue_max to 3 or 4 to decrease latency on dsound games. > It seems dsound doesn't respect mmdevapi in that regard or 2 periods > might have been possible. It would have been nice if it did. :(

March 8, 2012

Re: My Idea for GSOC

by Vitaliy Margolen

On 03/07/2012 01:07 PM, Daniel Oom wrote: > Hello, my name is Daniel Oom and I'm a computer science and > engineering student at Chalmers in Gothenburg, Sweden. Welcome to Wine! > Would, for example: fix Steam's in-game overlay feature be a good goal? Not really, as it's already working fine in most cases. You just need a "proper" version of gcc to compile Wine with. You can find few ideas on what to do on GSOC Wiki page: http://wiki.winehq.org/SummerOfCode Vitaliy.

March 8, 2012

My Idea for GSOC

by Daniel Oom

Hello, my name is Daniel Oom and I'm a computer science and engineering student at Chalmers in Gothenburg, Sweden. I'm in my second year and I would love to partake in GSOC. I know C, use Linux daily and don't like it when I have to reboot my computer to windows. I am very interested in game development and real time rendering, and have actually completed one simple game (written in Java/OpenGL). But I still have so much left to learn, and I believe I can learn a lot through working with wine in these areas. My idea, or rather how I would like to improve wine, is related to gaming. I've tried to run some games in wine and sometimes it works very well but more often than not there's bugs. The bad performance, misc bugs and general unresponsiveness of Steam is my greatest itch. Though as I'm not versed in wine's code base I don't know what would constitute as reasonable goals for GSOC. (I did do a bug report a long time ago, but back then I did not know a lot about programming). Would, for example: fix Steam's in-game overlay feature be a good goal? Some advice about where to take it from here would be greatly appreciated. // Daniel Oom

March 7, 2012

Re: Wine release 1.4

by Thomas Spear

I agree, based on all of the improvements, this is definitely the finest wine release to date. Huge accomplishment. Congrats to all! Thank you, Thomas Spear On Mar 7, 2012 10:38 AM, "Jeremy White" <jwhite(a)codeweavers.com> wrote: > On 3/7/12 10:21 AM, Alexandre Julliard wrote: > >> The Wine team is proud to announce that the stable release Wine 1.4 >> is now available. >> >> Let me be the first to say: Woohoo!!!! > > Cheers, > > Jeremy > > >

March 7, 2012