Re: Rethinking WineConf
On January 10, 2012 at 11:00 PM Marcus Meissner wrote: > - Perhaps a shrinking audience is unavoidable. > > This is a bit of a fact that some projects I have been in found hard to >cope with... That after > the interest peak it might go down. > And if you are looking for a reason, one is that interest in the Windows platform itself is waning. Maybe if Wine picked up the Metro glove, interest in Wine as a whole could be rekindled. //Jakob
Re: mscoree: Implement DllGetClassObject
You can't just use a static class factory for all the classes. There's no need for GetIDispatchForObject when we already have GetIUnknownForObject (and all you use is QueryInterface). +res = RegGetValueA( key, NULL, "Class", RRF_RT_REG_SZ, NULL, classname, &dwBufLen); We should probably use a W function here and convert to utf8, rather than assume that's the default encoding.
Re: What other conferences do Wine people attend?
Hi, Akademy (KDE) Desktop Summit (KDE + Gnome, although we have tried to get XFCE, Enlightenment, etc on) FOSDEM (a bit of everything, huge) DebConf (Debian) Libre Software World Conference (a bit of everything, big) Collocating may be a good idea. Collocating in one of the biggest may not necessarily be a good idea. For instance, FOSDEM is so big if you organize WineConf in Brussels, how would you manage 200 people suddenly showing at WineConf's room (which can probably only admit 50-60 people because the usual audience is 35 people) ? Akademy has accepted other conferences in the past, such as a the Text Layout Summit in 2007. TLS was very small (about 20 people), and collocating into Akademy had direct results in KOffice: we realized we needed to improve typography a lot. It took a few years, but currently we do have great fonts in our office suite (now called Calligra). (This makes me remember in the KDE 1.x we had something callled Aktivate which used wine to be able to use ActiveX controls with KDE applications; I'm getting old) On Tue, Jan 10, 2012 at 11:55 PM, Dan Kegel wrote: > In the wineconf thread, the question came up: > What other conferences people do wine developers/users attend, if any? > > If you send me the names of the conference(s) you attended in the last > two years, > I'll summarize for the list. > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Rethinking WineConf
On Tue, Jan 10, 2012 at 8:34 PM, Damjan Jovanovic wrote: > What about Mono? .NET applications that use P/Invoke won't ever work outside > Windows without Wine, so they kind of need us, and many native applications > now also use .NET, so we kind of need them. Unlike with Samba, the licenses > are compatible, and a combined/attached conference might attract some of > their developers to help us out. >From what I recall, the Mono people don't really intend to support those apps; they're more into supporting people who are writing new apps from scratch. - Dan
Re: Rethinking WineConf
On Wed, Jan 11, 2012 at 12:00 AM, Marcus Meissner wrote: > > > - Attaching to other conferences? > > We do not really share much with other projects (please do not bring up > Samba: we don't), > What about Mono? .NET applications that use P/Invoke won't ever work outside Windows without Wine, so they kind of need us, and many native applications now also use .NET, so we kind of need them. Unlike with Samba, the licenses are compatible, and a combined/attached conference might attract some of their developers to help us out.
Re: [2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)
On 01/10/2012 10:51 AM, Lucas Zawacki wrote:
2012/1/10 Vitaliy Margolen:
On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote:
From: Lucas Fialho Zawacki
+static BOOL _write_private_profile_intW(const char *format, WCHAR*
section, WCHAR* key, int value, WCHAR* file)
I don't think this is such a good idea to mix ASCII and WCHAR parameters.
Even if this is for convenience in my "private" code? I use this a
great deal through the code.
Always converting static text from ASCII to Unicode during run-time is not a
good thing. Yes it sucks that we have to define all Unicode strings as
arrays. But such as life.
Why do you think it should be there in the first place?
Windows keeps it there, you can check it by running any application
using SetActionMap. But I suppose no application depends on it being
there specifically.
Just because Windows does something is not good enough of an excuse to do
the same. AJ said that on many occasions... Here it seems really suspicious
that any user can create files inside a program install directory structure.
And those files not even executables or libraries... If anything these files
belongs under user's profile local data files directory.
Yes, you're right. There were other mistakes as well. Is this version better?
...
while (1)
{
/* Test if it's the first time */
if (buffer == NULL)
buffer = HeapAlloc(GetProcessHeap(), 0, size*sizeof(WCHAR));
else
buffer = HeapReAlloc(GetProcessHeap(), 0, buffer,
size*sizeof(WCHAR));
Nope, you clobber original value of "buffer" and what you had before is
lost. So in case it fails you leaking old buffer.
However I really don't like this function, and how it's used. If all you
need is to format some strings, then you should provide your own buffer for
such a function and let it grow it if needed to. Then you save time by not
allocating / freeing same buffer multiple times.
Would you please drop leading underscore from all of your function names?
Ok. I can stop doing this from this patch onwards if you think this
convention is bad.
In *NIX world only system functions deserve leading underscore...
- Vitaliy
Re: What other conferences do Wine people attend?
Every year I attend to FISL here in my home town of Porto Alegre (Brazil), it's one of the biggest events in Latin America but I reckon most of wine devs are far north. I didn't want to hijack the other thread, so I'll just throw an idea here. It's been some time now that I've wanted to organize a local meeting of wine users (and potential users) to have some kind of install fest, bug hunting and talks about wine and maybe FOSS in general to go along with it. I hope that we can end the event with people happier with their non-Windows OSes and more educated about things like wine, appdb, bug reporting and such. What do you think? Has anybody tried something similar? Any advice?
Re: [Wine] Rethinking WineConf
Jeremy White wrote: > the Wine conference has been a mostly annual affair since 2002 ... > It's been in Minnesota about every 3rd year, and is otherwise > 'normally' somewhere in Europe. > > How could Wineconf be different? If you've never been, what would > encourage you to come? One thing that would encourage me to come would be holding it in Portland, Oregon. Even Seattle or San Francisco is too far away.
Re: What other conferences do Wine people attend?
On Tue, Jan 10, 2012 at 2:55 PM, Dan Kegel wrote: > In the wineconf thread, the question came up: > What other conferences people do wine developers/users attend, if any? > > If you send me the names of the conference(s) you attended in the last > two years, > I'll summarize for the list. I've seen DanK at SCALE on numerous occasions. Did I mention it's a nice 70F / 21C in LA today?
Re: Rethinking WineConf
On Tue, Jan 10, 2012 at 5:44 PM, Alex Bradbury wrote: > Another angle on this might be making some changes to WineConf, but > also making a concerted effort to make sure Wine is well represented > at events many developers and users already attend such as FOSDEM and > OSCON. In that regard, let me say: this year I am coorganizing the CrossDesktop DevRoom at FOSDEM and I am truly disappointed we have not received a single talk proposal about Wine, even though I sent the call for talks and a reminder to this list. With my open source developer hat on, an introductory talk on Wine development would be very appealing to me. Also, a talk (or maybe more than one) for third-party ISVs which want to make sure their applications work with Wine would also be nice. At work we seriously considered Wine for a big product which uses embedded virtualization that could probably be replaced with Wine, but we didn't really have a clue where to get started or what we could achieve in 1 year if we put a few people to hack on Wine. Expectations were so unclear management was not in the mood to throw a few thousands to hire CodeWeavers or any Wine hacker in Europe for a preliminary study. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
What other conferences do Wine people attend?
In the wineconf thread, the question came up: What other conferences people do wine developers/users attend, if any? If you send me the names of the conference(s) you attended in the last two years, I'll summarize for the list.
Re: Rethinking WineConf
On Tue, Jan 10, 2012 at 11:00 PM, Marcus Meissner wrote: > > The workshop elements we introduced in the last years are however more the > direction to go. > So something of a workshop is my best bet at keeping interest. > > > Question is whether we can find workshop style things besides "fixing the > testsuite" that attract > all developers? I think that will be hard. I think that a workshop 'How to start coding for wine' workshop would do good. That might attract programmers that really want to help out, but as you probably all know, the learning curve for wine is pretty steep. Matijn
Re: Rethinking WineConf
On Mon, Jan 09, 2012 at 12:31:11PM -0600, Jeremy White wrote: > Hi All, > > This past Wine conference, while great fun as always, was not as well > attended as Wine conferences in the past. > > So I would like to stir up trouble by suggesting we rethink WineConf. > > For those that have not attended, the Wine conference has been a mostly > annual affair since 2002. It is open to all, but is advertised as being > aimed at Wine developers. About 35 people attend each year. It's been > in Minnesota about every 3rd year, and is otherwise 'normally' somewhere > in Europe. > > I see the primary goal as creating human bonds between otherwise > anonymous people (aka going to the pub). It's a bonus if it also spurs > resolution to tricky issues, or motivates people to get more done. > > So I'd like to ask folks to brain storm with me. > > How could Wineconf be different? If you've never been, what would > encourage you to come? > > If you've been to a technical conference recently that you thought was > well done, what did they do well? Anything we could emulate? > > Any other ideas, or suggestions? - Users ... as this was brought up Reality check: Wine users will not travel 100s of kms to a standalone conference. This would make sense only if we attach wineconf to another general conference - Attaching to other conferences? We do not really share much with other projects (please do not bring up Samba: we don't), but perhaps attaching to general conferences... General conferences like FOSDEM (where other projects run Developer Rooms)... or LinuxCon with their specific tracks. This might be workable... but I do not think it will bring more people. - Changing the style... A talk / discussion only wineconf is not really flying anymore... we don't have that much talks. The workshop elements we introduced in the last years are however more the direction to go. So something of a workshop is my best bet at keeping interest. Question is whether we can find workshop style things besides "fixing the testsuite" that attract all developers? I think that will be hard. - Perhaps a shrinking audience is unavoidable. This is a bit of a fact that some projects I have been in found hard to cope with... That after the interest peak it might go down. Ciao, Marcus
Re: RFH: Applications that call stuff from DllMain
On Tue, Jan 10, 2012 at 09:10:15PM +0100, Henri Verbeet wrote: > On 10 January 2012 20:55, Andrew Eikum wrote: > > So it appears we should be able to launch threads in DllMain() without > > deadlocking. > > > > Thoughts, anyone? > > > That should be easy enough to test. Is the issue just launching a > thread though, or actually waiting for it to start? You're right. I jumped to the conclusion that they were using that thread to complete the GetNumDevs() call. If I explicitly spawn a thread and wait for it in dmtest.dll, it deadlocks on Windows as well. So that's the wrong answer.
Re: RFH: Applications that call stuff from DllMain
On 10 January 2012 20:55, Andrew Eikum wrote: > So it appears we should be able to launch threads in DllMain() without > deadlocking. > > Thoughts, anyone? > That should be easy enough to test. Is the issue just launching a thread though, or actually waiting for it to start?
Re: RFH: Applications that call stuff from DllMain
On Wed, Jan 11, 2012 at 01:03:56AM +0800, Dmitry Timoshkov wrote:
> Andrew Eikum wrote:
>
> > So, I'm asking for insights. Should I try hard to avoid launching
> > threads unless absolutely necessary? Is this a known deficiency in the
> > loader, and I should do nothing? Is there some other way to work
> > around this?
>
> As usually first thing to do is to write some tests and investigate what
> Windows does/how it copes with such cases.
Some more testing just confirms that we should be able to launch
threads from within a client DllMain(). I wrote a test DLL, compiled
in MSVC++ 2010, which basically does (pseudocode, obviously):
DllMain(){
winmm = LoadLibrary("WinMM.dll");
wOGND = GetProcAddress(winmm, "waveOutGetNumDevs");
printf("%u\n", wOGND());
}
I then load that DLL from a (severely hacked) dsound_crosstest.exe,
which does not link against dsound or winmm.
Printing the result from waveOutGetNumDevs() shows that it works (it
returns 2, which is correct). Monitoring the thread count via Task
Manager before and after the call shows that waveOutGetNumDevs()
launches a thread, like I mentioned in the first email.
Running that dsound test in Wine to load dmtest.dll deadlocks waiting
for the loader CS, just like the bugs linked in the first email.
So it appears we should be able to launch threads in DllMain() without
deadlocking.
Thoughts, anyone?
Andrew
Re: winmm: GetCurrentPadding is superfluous while recording.
joerg-cyril.hoe...@t-systems.com writes:
> Hi,
>
> now winmm recording does not depend on chunking by mmdevapi.
>
> +if(packet > 0)
> +WARN("losing %u frames\n", packet);
> That part is interesting. Another approach would have been to check whether
> all of GetData could be stuffed into winmm buffers and use ReleaseBuffer(0)
> if not
> (much more complicated in the presence of several buffers).
>
> As long as winmm supplies enough buffers in advance, that doesn't matter.
>
> With that in place, the "Fix AudioCaptureClient protocol" patches can be
> applied on
> the winmm side. I have not checked the dsound code.
>
> I'm sorry winmm:ACMPullData was broken by my former notification patch. I'll
> have to fix that.
> ACMPullData is also not very robust (return; after GetBuffer will prevent any
> subsequent GetBuffer
> with OUT_OF_ORDER).
It doesn't work here:
../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so
mci.c && touch mci.ok
[...]
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
err:winmm:WID_PullData GetBuffer failed: 88890007
etc. forever
--
Alexandre Julliard
julli...@winehq.org
Re: [2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)
2012/1/10 Vitaliy Margolen :
> On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote:
>>
>> From: Lucas Fialho Zawacki
>>
>> +static BOOL _write_private_profile_intW(const char *format, WCHAR*
>> section, WCHAR* key, int value, WCHAR* file)
>
> I don't think this is such a good idea to mix ASCII and WCHAR parameters.
Even if this is for convenience in my "private" code? I use this a
great deal through the code.
>> + static WCHAR path[] = {
>> +
>> '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\',
>> + 'D','i','r','e','c','t','X','\\',
>> + 'D','i','r','e','c','t','I','n','p','u','t','\\',
>> + 'U','s','e','r',' ','M','a','p','s','\0'};
>
> Why do you think it should be there in the first place?
Windows keeps it there, you can check it by running any application
using SetActionMap. But I suppose no application depends on it being
there specifically.
> You can't do this. It seems to be you have not tested it with initial buffer
> too small. You have to do va_start & va_end every time you pass "args" to
> another function.
Yes, you're right. There were other mistakes as well. Is this version better?
...
while (1)
{
/* Test if it's the first time */
if (buffer == NULL)
buffer = HeapAlloc(GetProcessHeap(), 0, size*sizeof(WCHAR));
else
buffer = HeapReAlloc(GetProcessHeap(), 0, buffer,
size*sizeof(WCHAR));
if (buffer == NULL)
break;
va_start(args, format);
n = vsnprintfW(buffer, size, formatW, args);
va_end(args);
if (n == -1)
size *= 2;
else if (n >= size)
size = n + 1;
else
break;
}
HeapFree(GetProcessHeap(), 0, formatW);
return buffer;
I tested it for smaller buffer values. If that's alright I can send a
patch to winemenubuilder.c too because the heap_printf there should
suffer from the same bug.
> Would you please drop leading underscore from all of your function names?
Ok. I can stop doing this from this patch onwards if you think this
convention is bad.
Re: [PATCH] wineoss.drv: Fix IAudioRenderClient::{Get,Release}Buffer protocol
On Tue, Jan 10, 2012 at 04:57:58PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Andrew Eikum wrote:
> >I think the GetPosition and GetCurrentPadding failures are caused by
> >using GETOSPACE instead of GETODELAY in GetPosition().
> Please write that patch too. It needs good testing to get the
> start/stop/underrun corner cases right.
>
I've attached it here, but see caveats below...
> render.c:1227: Test failed: GetCurrentPadding returned 512, should be 0
> No idea, please check.
>
This is because of the workaround for an OSS bug. If there's less than
a full fragment of data in the OSS buffer, it will report some
unreliable value between 0 and fragment_size (inclusive), even in
underrun condition. Consider the conflicting scenarios:
Get/ReleaseBuffer(`size' less than fragment_size frames)
GetCurrentPadding() must return exactly `size'
vs
Get/ReleaseBuffer(`size' greater than fragment_size frames)
Start()
...Underrun
GetCurrentPadding() must return 0
In both cases, GETOSPACE returns something between 0 and fragment_size
in the GCP() call. It's hard to work around this bug... I'm trying to
come up with something now, possibly detecting and special-casing
underrun.
> render.c:1228: Test failed: Position 142756 at end vs. 143268 submitted frames
> In shared mode, the end position must be the sum of released frames.
> In exclusive mode, I've seen some cards return a little less.
>
And here we have a somewhat similar problem:
Get/ReleaseBuffer(`size' = a lot of frames)
Start()
GetPosition() must return `size' - delay
vs
Get/ReleaseBuffer(`size' = a lot of frames)
Start()
...Underrun
GetPosition() must return `size'
Again, we have to detect "almost empty" vs. "empty" with broken OSS.
Anyways, I'm working on it.
Andrew
>From 23214b8d506f8592aa4bc39ca9ce5ca66ac44162 Mon Sep 17 00:00:00 2001
From: Andrew Eikum
Date: Tue, 10 Jan 2012 10:32:54 -0600
Subject: wineoss.drv: Use GETODELAY instead of GETOSPACE to determine device
position
To: wine-patches
Reply-To: wine-devel ,Andrew Eikum
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1.7.8.3"
This is a multi-part message in MIME format.
--1.7.8.3
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
dlls/wineoss.drv/mmdevdrv.c | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
--1.7.8.3
Content-Type: text/x-patch; name="0003-wineoss.drv-Use-GETODELAY-instead-of-GETOSPACE-to-de.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="0003-wineoss.drv-Use-GETODELAY-instead-of-GETOSPACE-to-de.patch"
diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c
index aaa94ee..88de2a3 100644
--- a/dlls/wineoss.drv/mmdevdrv.c
+++ b/dlls/wineoss.drv/mmdevdrv.c
@@ -2038,8 +2038,6 @@ static HRESULT WINAPI AudioClock_GetPosition(IAudioClock *iface, UINT64 *pos,
UINT64 *qpctime)
{
ACImpl *This = impl_from_IAudioClock(iface);
-UINT32 pad;
-HRESULT hr;
TRACE("(%p)->(%p, %p)\n", This, pos, qpctime);
@@ -2048,17 +2046,33 @@ static HRESULT WINAPI AudioClock_GetPosition(IAudioClock *iface, UINT64 *pos,
EnterCriticalSection(&This->lock);
-hr = IAudioClient_GetCurrentPadding(&This->IAudioClient_iface, &pad);
-if(FAILED(hr)){
-LeaveCriticalSection(&This->lock);
-return hr;
+if(This->dataflow == eRender){
+int delay;
+if(ioctl(This->fd, SNDCTL_DSP_GETODELAY, &delay) < 0)
+delay = 0;
+else
+delay /= This->fmt->nBlockAlign;
+if(This->held_frames + delay >= This->written_frames)
+*pos = 0;
+else
+*pos = This->written_frames - This->held_frames - delay;
+}else if(This->dataflow == eCapture){
+audio_buf_info bi;
+UINT32 held;
+
+if(ioctl(This->fd, SNDCTL_DSP_GETISPACE, &bi) < 0){
+TRACE("GETISPACE failed: %d (%s)\n", errno, strerror(errno));
+held = 0;
+}else{
+if(bi.bytes <= bi.fragsize)
+held = 0;
+else
+held = bi.bytes / This->fmt->nBlockAlign;
+}
+
+*pos = This->written_frames + held;
}
-if(This->dataflow == eRender)
-*pos = This->written_frames - pad;
-else if(This->dataflow == eCapture)
-*pos = This->written_frames + pad;
-
LeaveCriticalSection(&This->lock);
if(qpctime){
--1.7.8.3--
Re: [2/2] msvcrt: Forward strftime() to wcsftime(). Take 2.
Dmitry Timoshkov writes:
> +len = MultiByteToWideChar( CP_ACP, 0, format, -1, NULL, 0 );
> +if ((fmt = MSVCRT_malloc( len * sizeof(MSVCRT_wchar_t) )))
> +{
> +MultiByteToWideChar( CP_ACP, 0, format, -1, fmt, len );
> +
> +if ((len = MSVCRT_wcsftime( s, max, fmt, mstm )))
> +{
> +len = WideCharToMultiByte( CP_ACP, 0, s, len, str, max, NULL,
> NULL );
> +if (len < max) str[len] = 0;
> +}
The overflow handling still looks suspicious. It probably needs some
more test cases.
--
Alexandre Julliard
julli...@winehq.org
Re: Rethinking WineConf
On 9 January 2012 18:31, Jeremy White wrote: > So I'd like to ask folks to brain storm with me. > > How could Wineconf be different? If you've never been, what would > encourage you to come? Another angle on this might be making some changes to WineConf, but also making a concerted effort to make sure Wine is well represented at events many developers and users already attend such as FOSDEM and OSCON. Alex
Re: Rethinking WineConf
Users coming to Wineconf will likely want to hear about Wine's development; what improvements they can expect, the progress on their favourite apps, etc. I suspect a great deal of users will also want to share their ideas on what they feel is important in further developments. J. Leclanche On Tue, Jan 10, 2012 at 3:23 PM, Jeremy White wrote: > > Posted: Tue Jan 10, 2012 6:07 amPost subject: > > If you really want users to come, I suggest you change the second > sentence on http://wiki.winehq.org/WineConf. Right now it sends a very > clear message that users are not the least bit welcome. > > /me winces. I wrote that text; and I never intended it to make anyone > feel unwelcome. The thinking when I wrote it was to give fair warning > that the topics would be primarily developer oriented. > > I've amended that text. > > So then let's imagine that users now feel welcome, and they come in > droves. Aside from going to the pub, what would make for a good > conference? > > Cheers, > > Jeremy > > >
Re: RFH: Applications that call stuff from DllMain
Andrew Eikum wrote: > So, I'm asking for insights. Should I try hard to avoid launching > threads unless absolutely necessary? Is this a known deficiency in the > loader, and I should do nothing? Is there some other way to work > around this? As usually first thing to do is to write some tests and investigate what Windows does/how it copes with such cases. -- Dmitry.
[PATCH] wineoss.drv: Fix IAudioRenderClient::{Get,Release}Buffer protocol
Andrew Eikum wrote: >I think the GetPosition and GetCurrentPadding failures are caused by >using GETOSPACE instead of GETODELAY in GetPosition(). Please write that patch too. It needs good testing to get the start/stop/underrun corner cases right. My hope is that Wine-1.4.0 will have 3 drivers of comparable if not equal quality. What I plan is to submit my render patch with almost all GetPosition tests lifted behind if(winetest_debug>1): render.c:1062: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. This one perhaps should move as well, although it indicates a problem. render.c:1166: Test failed: Position should have been further along... render.c:1227: Test failed: GetCurrentPadding returned 512, should be 0 No idea, please check. render.c:1228: Test failed: Position 142756 at end vs. 143268 submitted frames In shared mode, the end position must be the sum of released frames. In exclusive mode, I've seen some cards return a little less. Your RenderClient patch looks good. Regards, Jörg Höhle
RFH: Applications that call stuff from DllMain
This mail is about bugs 28042[1] and 28677[2]. In short, what I'm trying to deal with is buggy applications that make calls to DSound and WinMM from within DllMain(), causing deadlocks. On almost any entry into DSound or WinMM's wave functions, the modules launch a thread to communicate with MMDevAPI. We create a new thread for two reasons. First, to CoInitialize() the thread, which we shouldn't do on a user thread. Second, the MMDevAPI docs say that the device objects should be created and destroyed from the same thread[3], which we can't guarantee if we create them on a user thread (I think dsound currently violates this, actually). Wine holds the loader critical section during calls to DllMain(). However, launching a new thread requires using the loader, and so we hit a deadlock. This is the problem reported by these bugs. While we might be able to perform some of these functions without launching a new thread, I'm not sure that that's a general solution, since we will have to launch a thread at some point. Analysis on Windows 7 shows that DirectSoundEnumerate() does not launch any additional threads, but mixerGetNumDevs() actually does launch a thread, yet the application still launches successfully. So, I'm asking for insights. Should I try hard to avoid launching threads unless absolutely necessary? Is this a known deficiency in the loader, and I should do nothing? Is there some other way to work around this? Thanks, Andrew [1] http://bugs.winehq.org/show_bug.cgi?id=28042 [2] http://bugs.winehq.org/show_bug.cgi?id=28677 [3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=VS.85%29.aspx
Re: Rethinking WineConf
> Posted: Tue Jan 10, 2012 6:07 amPost subject: > If you really want users to come, I suggest you change the second sentence on > http://wiki.winehq.org/WineConf. Right now it sends a very clear message that > users are not the least bit welcome. /me winces. I wrote that text; and I never intended it to make anyone feel unwelcome. The thinking when I wrote it was to give fair warning that the topics would be primarily developer oriented. I've amended that text. So then let's imagine that users now feel welcome, and they come in droves. Aside from going to the pub, what would make for a good conference? Cheers, Jeremy
MacOS recording audio - chunking 4096 frames
Hi, looking at mmdevapi/tests/capture logs, I found 2 issues 1. the 5 buffers initially sent are all returned with 0 bytes So I added a loop to return empty buffers to the audio input queue, such that GetBuffer returns data when GetCurrentPadding shows it. But why were these buffers returned at all? Why initially submit the buffers if they are always returned empty? 2. Using a ~500ms mmdevapi duration, Wine gave MacOS CoreAudio 5 buffers of ~4399 frames each. However, MacOS solely returned 4096 frames. Is anybody aware of such chunking? I'd like to know about such chunking, because IMHO the correct way to handle it would be to advertise mmdevapi's a matching default recording period -- obviously not 10ms. I believe the current mmdevapi code did not expect that behaviour and therefore does not manage to fill as much frames as GetBufferSize would allow into a buffer. I haven't checked smaller buffers. I'd like to avoid bombarding CoreAudio with 10ms buffer requests of 480 frames each just because native mmdevapi advertises a 10ms period. Thank you for your help, Jörg Höhle
Re: jscript: Fixed continue inside for..in statement
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=16361 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: gdi32: GetGlyphIndices doesn't substitute glyph.
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=16359 Your paranoid android. === WNT4WSSP6 (32 bit font) === Timeout
