Re: My Idea for GSOC
Am Donnerstag, 8. März 2012, 23:32:16 schrieb Pau Garcia i Quiles: If he is adventurous, here is another idea: A wish a day 14: Wine-based Application Virtualization http://www.elpauer.org/?p05 Wine doesn't help you too much in this(except for the cross-platform part), and the idea isn't really suitable for gsoc imo. And no, Wine doesn't support USB devices(aside from some patches floating around), and you can't virtualize device drivers. Most drivers on Windows(and Linux) run inside the kernel. You can't simply boot up a second kernel instance to load the driver into. signature.asc Description: This is a digitally signed message part.
Re: advapi32: Assign a default value (clang)
On Fri, 2012-03-09 at 19:54 +1100, Alistair Leslie-Hughes wrote:
@@ -755,7 +755,7 @@ SC_HANDLE WINAPI OpenSCManagerA( LPCSTR lpMachineName,
LPCSTR lpDatabaseName,
SC_HANDLE WINAPI OpenSCManagerW( LPCWSTR lpMachineName, LPCWSTR
lpDatabaseName,
DWORD dwDesiredAccess )
{
-SC_HANDLE handle;
+SC_HANDLE handle = INVALID_HANDLE_VALUE;
These functions return NULL on failure.
Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
On 03/08/12 21:55, Gerald Pfeifer wrote: On Thu, 8 Mar 2012, Jacek Caban 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. 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? secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized] An alternative to silence this would be initializing policy to some default value. Would that be preferrable? It's clearly a false positive. If we return an error in confirm_safety_load, we'll never execute the line from warning. Since GCC 4.8 is in an early development stage, I don't think we should change the code to hide its buggy warnings. It would be much better to see it fixed on GCC side, so GCC bug report would be more appropriate at this point IMO. Cheers, Jacek
Re: Web based translation tool
Hi Aric, Latest entry on Planet Debian is about http://weblate.org/ which could be a good candidate according to its about page : Weblate is web based translation tool with tight Git integration. It features simple and clean user interface, propagation of translations across subprojects or automatic linking to source files. List of features includes: Easy web based translation Propagation of translations across sub-projects (for different branches) Tight git integration Usage of Django's admin interface Upload and automatic merging of po files Links to source files for context -- Nicolas Le Cam
ntdll: Do not execute callbacks past DeleteTimer(INVALID_HANDLE_VALUE).
Hi, callbacks are running in Wine even after DeleteTimerQueue(INVALID_HANDLE_VALUE). I've attached to bug #30071 tests that show the bug and fail in unpatched Wine. Regards, Jörg Höhle
Re: [PATCH 8/9] d3drm: Add refcount info to AddRed and Release traces.
On 3/9/2012 13:56, Christian Costa wrote:
diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c
index 879d8b0..42d722c 100644
--- a/dlls/d3drm/d3drm.c
+++ b/dlls/d3drm/d3drm.c
@@ -87,10 +87,11 @@ static HRESULT WINAPI
IDirect3DRMImpl_QueryInterface(IDirect3DRM* iface, REFIID
static ULONG WINAPI IDirect3DRMImpl_AddRef(IDirect3DRM* iface)
{
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): AddRef from %d\n, iface, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
static ULONG WINAPI IDirect3DRMImpl_Release(IDirect3DRM* iface)
@@ -98,7 +99,7 @@ static ULONG WINAPI IDirect3DRMImpl_Release(IDirect3DRM*
iface)
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
ULONG ref = InterlockedDecrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): ReleaseRef to %d\n, iface, This, ref);
if (!ref)
HeapFree(GetProcessHeap(), 0, This);
diff --git a/dlls/d3drm/device.c b/dlls/d3drm/device.c
index 559128e..6f9802a 100644
--- a/dlls/d3drm/device.c
+++ b/dlls/d3drm/device.c
@@ -93,10 +93,11 @@ static HRESULT WINAPI
IDirect3DRMDevice2Impl_QueryInterface(IDirect3DRMDevice2*
static ULONG WINAPI IDirect3DRMDevice2Impl_AddRef(IDirect3DRMDevice2* iface)
{
IDirect3DRMDeviceImpl *This = impl_from_IDirect3DRMDevice2(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p)\n, This);
+TRACE((%p): AddRef from %d\n, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
I personally don't see a reason to trace actual reference on release and
previous one on AddRef. I usually trace new value in both calls so you
don't need to keep in mind this +/- 1 offset when looking at logs.
Also you don't need extra words in trace message cause function name is
visible in traces already.
Re: [PATCH 8/9] d3drm: Add refcount info to AddRed and Release traces.
Le 09/03/2012 13:06, Nikolay Sivov a écrit :
On 3/9/2012 13:56, Christian Costa wrote:
diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c
index 879d8b0..42d722c 100644
--- a/dlls/d3drm/d3drm.c
+++ b/dlls/d3drm/d3drm.c
@@ -87,10 +87,11 @@ static HRESULT WINAPI
IDirect3DRMImpl_QueryInterface(IDirect3DRM* iface, REFIID
static ULONG WINAPI IDirect3DRMImpl_AddRef(IDirect3DRM* iface)
{
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): AddRef from %d\n, iface, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
static ULONG WINAPI IDirect3DRMImpl_Release(IDirect3DRM* iface)
@@ -98,7 +99,7 @@ static ULONG WINAPI
IDirect3DRMImpl_Release(IDirect3DRM* iface)
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
ULONG ref = InterlockedDecrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): ReleaseRef to %d\n, iface, This, ref);
if (!ref)
HeapFree(GetProcessHeap(), 0, This);
diff --git a/dlls/d3drm/device.c b/dlls/d3drm/device.c
index 559128e..6f9802a 100644
--- a/dlls/d3drm/device.c
+++ b/dlls/d3drm/device.c
@@ -93,10 +93,11 @@ static HRESULT WINAPI
IDirect3DRMDevice2Impl_QueryInterface(IDirect3DRMDevice2*
static ULONG WINAPI
IDirect3DRMDevice2Impl_AddRef(IDirect3DRMDevice2* iface)
{
IDirect3DRMDeviceImpl *This = impl_from_IDirect3DRMDevice2(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p)\n, This);
+TRACE((%p): AddRef from %d\n, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
I personally don't see a reason to trace actual reference on release
and previous one on AddRef. I usually trace new value in both calls so
you don't need to keep in mind this +/- 1 offset when looking at logs.
Also you don't need extra words in trace message cause function name
is visible in traces already.
Indeed that does not make sense but I've a always seen that. In addition
I took the message from another place.
I don't mind changing at all. I like (%p)-(): new ref = %d\n and I
will stick to it. That said that would be good to have some
recommendations so people can use follow them.
Re: [PATCH 8/9] d3drm: Add refcount info to AddRed and Release traces.
On 3/9/2012 14:46, Christian Costa wrote:
Le 09/03/2012 13:06, Nikolay Sivov a écrit :
On 3/9/2012 13:56, Christian Costa wrote:
diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c
index 879d8b0..42d722c 100644
--- a/dlls/d3drm/d3drm.c
+++ b/dlls/d3drm/d3drm.c
@@ -87,10 +87,11 @@ static HRESULT WINAPI
IDirect3DRMImpl_QueryInterface(IDirect3DRM* iface, REFIID
static ULONG WINAPI IDirect3DRMImpl_AddRef(IDirect3DRM* iface)
{
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): AddRef from %d\n, iface, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
static ULONG WINAPI IDirect3DRMImpl_Release(IDirect3DRM* iface)
@@ -98,7 +99,7 @@ static ULONG WINAPI
IDirect3DRMImpl_Release(IDirect3DRM* iface)
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
ULONG ref = InterlockedDecrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): ReleaseRef to %d\n, iface, This, ref);
if (!ref)
HeapFree(GetProcessHeap(), 0, This);
diff --git a/dlls/d3drm/device.c b/dlls/d3drm/device.c
index 559128e..6f9802a 100644
--- a/dlls/d3drm/device.c
+++ b/dlls/d3drm/device.c
@@ -93,10 +93,11 @@ static HRESULT WINAPI
IDirect3DRMDevice2Impl_QueryInterface(IDirect3DRMDevice2*
static ULONG WINAPI
IDirect3DRMDevice2Impl_AddRef(IDirect3DRMDevice2* iface)
{
IDirect3DRMDeviceImpl *This =
impl_from_IDirect3DRMDevice2(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p)\n, This);
+TRACE((%p): AddRef from %d\n, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
I personally don't see a reason to trace actual reference on release
and previous one on AddRef. I usually trace new value in both calls
so you don't need to keep in mind this +/- 1 offset when looking at
logs.
Also you don't need extra words in trace message cause function name
is visible in traces already.
Indeed that does not make sense but I've a always seen that. In
addition I took the message from another place.
I don't mind changing at all. I like (%p)-(): new ref = %d\n and I
will stick to it.
This is too verbose too, format like (%p)-(%d) is enough. You don't
usually look at refcount traces while debugging, but when you see it
traced value should be consistent so you don't need to think is it 'new
ref' or 'old ref'.
That said that would be good to have some recommendations so people
can use follow them.
True.
Re: [PATCH 8/9] d3drm: Add refcount info to AddRed and Release traces.
Le 09/03/2012 13:49, Nikolay Sivov a écrit :
On 3/9/2012 14:46, Christian Costa wrote:
Le 09/03/2012 13:06, Nikolay Sivov a écrit :
On 3/9/2012 13:56, Christian Costa wrote:
diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c
index 879d8b0..42d722c 100644
--- a/dlls/d3drm/d3drm.c
+++ b/dlls/d3drm/d3drm.c
@@ -87,10 +87,11 @@ static HRESULT WINAPI
IDirect3DRMImpl_QueryInterface(IDirect3DRM* iface, REFIID
static ULONG WINAPI IDirect3DRMImpl_AddRef(IDirect3DRM* iface)
{
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): AddRef from %d\n, iface, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
static ULONG WINAPI IDirect3DRMImpl_Release(IDirect3DRM* iface)
@@ -98,7 +99,7 @@ static ULONG WINAPI
IDirect3DRMImpl_Release(IDirect3DRM* iface)
IDirect3DRMImpl *This = impl_from_IDirect3DRM(iface);
ULONG ref = InterlockedDecrement(This-ref);
-TRACE((%p/%p)\n, iface, This);
+TRACE((%p/%p): ReleaseRef to %d\n, iface, This, ref);
if (!ref)
HeapFree(GetProcessHeap(), 0, This);
diff --git a/dlls/d3drm/device.c b/dlls/d3drm/device.c
index 559128e..6f9802a 100644
--- a/dlls/d3drm/device.c
+++ b/dlls/d3drm/device.c
@@ -93,10 +93,11 @@ static HRESULT WINAPI
IDirect3DRMDevice2Impl_QueryInterface(IDirect3DRMDevice2*
static ULONG WINAPI
IDirect3DRMDevice2Impl_AddRef(IDirect3DRMDevice2* iface)
{
IDirect3DRMDeviceImpl *This =
impl_from_IDirect3DRMDevice2(iface);
+ULONG ref = InterlockedIncrement(This-ref);
-TRACE((%p)\n, This);
+TRACE((%p): AddRef from %d\n, This, ref - 1);
-return InterlockedIncrement(This-ref);
+return ref;
}
I personally don't see a reason to trace actual reference on release
and previous one on AddRef. I usually trace new value in both calls
so you don't need to keep in mind this +/- 1 offset when looking at
logs.
Also you don't need extra words in trace message cause function name
is visible in traces already.
Indeed that does not make sense but I've a always seen that. In
addition I took the message from another place.
I don't mind changing at all. I like (%p)-(): new ref = %d\n and I
will stick to it.
This is too verbose too, format like (%p)-(%d) is enough. You don't
usually look at refcount traces while debugging, but when you see it
traced value should be consistent so you don't need to think is it
'new ref' or 'old ref'.
-(...) are for arguments and I would keep 'new' to avoid confusion.
Maybe I could remove 'ref' but hey I don't think it's so verbose, it
take one line anyway.
I never have problem with refcount traces. This is the first thing I
look at when I debug a crash. Using a dedicated channel for refcount
would be better to reduce verbosity IMO.
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 08/03/2012 21:23, Alexandre Julliard a écrit : Christian Costatitan.co...@gmail.com writes: This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c touch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 I updated my tests and just remember sizeof must no be used in traces. BTW what should it be avoided ? Christian
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 9 mars 2012 13:39, Christian Costa titan.co...@gmail.com a écrit : Le 08/03/2012 21:23, Alexandre Julliard a écrit : Christian Costatitan.co...@gmail.com writes: This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c touch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 I updated my tests and just remember sizeof must no be used in traces. BTW what should it be avoided ? Christian Because there's no C89/C90 portable way of printf'ing a size_t. -- Nicolas Le Cam
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 09/03/2012 14:08, Nicolas Le Cam a écrit : Le 9 mars 2012 13:39, Christian Costatitan.co...@gmail.com a écrit : Le 08/03/2012 21:23, Alexandre Julliard a écrit : Christian Costatitan.co...@gmail.comwrites: This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.ctouch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 I updated my tests and just remember sizeof must no be used in traces. BTW what should it be avoided ? Christian Because there's no C89/C90 portable way of printf'ing a size_t. Ok. Thanks. But that could be done using a variable, right ?
Re: [PATCH 2/5] msxml3/tests: Added XMLView QueryInterface tests
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17248 Your paranoid android. === WNT4WSSP6 (32 bit xmlview) === xmlview.c:43: Test failed: CoCreateInstance returned 80040154, expected S_OK xmlview: unhandled exception c005 at 00454203
Re: [PATCH 5/5] ddraw: Get rid of IDirectDrawImpl.
On 2012-03-09 13:29, Christian Costa wrote: Hi Henry, Maybe it's a bit late to ask this but what's the reasoning behind introducing the struct keyword ? Typedefs have their uses, but the way it's used here is just obfuscation. Pretty much all it does is hiding the fact that a type is a structure. Also, while this doesn't apply to this specific patch, something like const LPWSAPROTOCOL_INFOW doesn't do what you want, and e.g. CONST LPD3DXFRAME *frame in d3dx9anim.h can probably at least in part be blamed on the silly typedef. And why removing use of This ? It's a common practise in all wine code. Mostly personal preference since I'm touching the code anyway. I must say that I don't consider it a particularly useful convention though. Something like ddraw or surface is a much more descriptive variable name than This or This. Naming something This mostly just tells you that it's the first argument of the function, presumably for similarity to C++ this. In that sense I guess it's somewhat similar to naming your function arguments arg0, arg1, arg2, etc. Also, as far as I'm concerned, about the only places I want to see caps in code are macros and enum elements. Of course other people will have their own preferences in that regard, but looking at the git shortlog summary for the past few years, I don't expect that to be a significant issue. If anything, it makes the code more consistent with wined3d. Henri
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Le 9 mars 2012 14:22, Christian Costa titan.co...@gmail.com a écrit : Le 09/03/2012 14:08, Nicolas Le Cam a écrit : Le 9 mars 2012 13:39, Christian Costatitan.co...@gmail.com a écrit : Le 08/03/2012 21:23, Alexandre Julliard a écrit : Christian Costatitan.co...@gmail.com writes: This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c touch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 I updated my tests and just remember sizeof must no be used in traces. BTW what should it be avoided ? Christian Because there's no C89/C90 portable way of printf'ing a size_t. Ok. Thanks. But that could be done using a variable, right ? Not really, %llu format specifier is avoided too as it's not much portable. -- Nicolas Le Cam
Re: Got Application cross-compiled with msvc11 for ARM running
Am 09.03.2012 08:24, schrieb Stefan Dösinger: Am Donnerstag, 8. März 2012, 18:38:16 schrieb Vincent Povirk: Without opengl, we won't be able to run wined3d. Yeah, that's unfortunate. d3d9.dll is a big gap in the dll list we could fill. Depending on the 3D driver, we may be able to call into the vendor ICD if microsoft doesn't provide a opengl32.dll. André, can you check if gdi32 has wgl exports like wglCreateContext and wglMakeCurrent? sadly not...as expected -- Best Regards, André Hentschel
Re: Got Application cross-compiled with msvc11 for ARM running
On 9 March 2012 01:38, Vincent Povirk madewokh...@gmail.com wrote: Without opengl, we won't be able to run wined3d. It also makes it a bit harder for browsers to support WebGL, which seems to be one of the things that's currently considered shiny, terrible idea as it may be. I guess they'll port ANGLE to d3d11.
Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
On Thu, 8 Mar 2012, Jacek Caban 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. 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? secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized] An alternative to silence this would be initializing policy to some default value. Would that be preferrable? Gerald
What happens upon mmdevapi capture overrun on native?
Hi, Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9: - 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. Does anybody know what precisely happens upon overrun during capture? A. mmdevapi fills the whole buffer once. It keeps firing events and sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer. This is like mciwave's record from 0 to 5000 command. The client can read the oldest recorded samples. B. mmdevapi continuously overwrites the circular buffer. It keeps firing events and sets the DISCONTINUITY flag too. The client gets to see the newest recorded samples. It's like your TV recorder's time shift function that can only travel back by as much as the buffer holds. C. Other, e.g. mixing newest with older packets (current winealsa). In other words, what data does the dlls/mmdevapi/capture test see in: http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc6#L305 I think A makes sense but really I don't know. The tests show a position jump by one period worth of frames when reading the next packet after an overrun. That's not what I'd expect from behaviour A. But from behaviour B I'd expect a much larger position jump, as large as elapsed time. We really need somebody with a microphone and Vista/w2k8/w7 to tell us what happens. Does anybody know what DSound does in such a case? (not that it matters...) Thank you, Jörg Höhle
Re: Translating the Wiki to Portuguese
On Thu, Mar 8, 2012 at 18:32, Lucas Zawacki lfzawa...@gmail.com wrote: Hello guys, I'd like to help translate some chunks of the Wine wiki to Portuguese. What is the accepted method of translating the wiki pages? What pages do you recognize as being more important to be translated first? If any portuguese speakers want to help let's get in touch to organize ourselves and split the work. Note you may want to update the main website pages (http://source.winehq.org/git/website.git/) first (e.g. the home page download page).
Re: [PATCH 2/9] d3drm: Fix identation.
On Fri, Mar 9, 2012 at 11:55, Christian Costa titan.co...@gmail.com wrote: --- dlls/d3drm/meshbuilder.c | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/dlls/d3drm/meshbuilder.c b/dlls/d3drm/meshbuilder.c index 39df1c6..9ca7cea 100644 That patch has probably little chance of getting committed. Formatting-only patches are generally discarded right away. Frédéric
Re: Translating the Wiki to Portuguese
2012/3/9 Frédéric Delanoy frederic.dela...@gmail.com: On Thu, Mar 8, 2012 at 18:32, Lucas Zawacki lfzawa...@gmail.com wrote: Hello guys, I'd like to help translate some chunks of the Wine wiki to Portuguese. What is the accepted method of translating the wiki pages? What pages do you recognize as being more important to be translated first? If any portuguese speakers want to help let's get in touch to organize ourselves and split the work. Note you may want to update the main website pages (http://source.winehq.org/git/website.git/) first (e.g. the home page download page). More information on http://wiki.winehq.org/TranslateWineHQ
GSoC 2011 - introduction
Hi, My name is Józef Kucia. I'm a Masters student in Computer Science at Wrocław University of Technology in Poland. I would like to apply for Google Summer of Code this year. I have a good knowledge of C and OpenGL. I also have limited experience with Direct3D and win32 programming. With regard to the Wine project, I'm familiar with the project from user perspective. I used to run some applications in Wine on my Gentoo Linux box, mostly games to be exact. Unfortunately, I haven't made any previous contributions to the Wine project, except submitting two small patches recently. I have read your project ideas for GSoC, and I am primarily interested in projects related to Direct3D. Nevertheless, I'm open to other projects. I would appreciate any suggestions or comments. Thanks, Józef Kucia
Re: Translating the Wiki to Portuguese
This is a question for the portuguese speakers in the list. Is it preferable to create a 'pt-br' translation for the site/wiki or use the current 'pt' one (a la Wikipedia)?. I personally like the second option and will try to use the common subset of our languages, but if someone thinks this is a bad idea please raise your voice.
Re: What happens upon mmdevapi capture overrun on native?
Hey Joerg, Op 09-03-12 17:46, joerg-cyril.hoe...@t-systems.com schreef: Hi, Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9: - 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. Does anybody know what precisely happens upon overrun during capture? A. mmdevapi fills the whole buffer once. It keeps firing events and sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer. This is like mciwave's record from 0 to 5000 command. The client can read the oldest recorded samples. B. mmdevapi continuously overwrites the circular buffer. It keeps firing events and sets the DISCONTINUITY flag too. The client gets to see the newest recorded samples. It's like your TV recorder's time shift function that can only travel back by as much as the buffer holds. C. Other, e.g. mixing newest with older packets (current winealsa). In other words, what data does the dlls/mmdevapi/capture test see in: http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc6#L305 I think A makes sense but really I don't know. The tests show a position jump by one period worth of frames when reading the next packet after an overrun. That's not what I'd expect from behaviour A. But from behaviour B I'd expect a much larger position jump, as large as elapsed time. I suspect B, the position jump makes sense in that case, because if you compare it with rendering on underrun clock doesn't get increased, so it makes sense on capture clock doesn't increase as well, and the discontinuity simply signals that an underrun has occurred that's at least a period long. The exact clock time passed will not matter. mmdevapi doesn't measure that in shared mode. It's also the only way the discontinuity flag would make sense and for the tests to pass, otherwise you would have set it on the first newly captured buffer after you finished reading out all old data. ~Maarten
