Maarten Lankhorst a écrit :
Jonathan Schleifer schreef:
Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
Wine could build fine without c++, not sure why everything has to
link against the c++ library as it will probably only be needed in
winegcc. Also these compiling flags seem kind of a
What's the status of this patch?
http://article.gmane.org/gmane.comp.emulators.wine.devel/40343/match=harddiskvolume1
_
Mortgage refinance is Hot. *Terms. Get a 5.375%* fix rate. Check savings
https://www2.nextag.com/goto.jsp?produ
Hi,
I have a patch which fixes the performance problems introduced with
c0782603d09807c6ca506948bb4a814a73430184 . I am sure that the patch is
correct, but I have the bad feeling that it brings up a few other bugs, so I
send it to wine-devel for testing first.
It only reallocates surfaces when
Maarten wrote:
I cannot test this as I don't have icc
It's a free download for noncommercial use; see
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/277618.htm
- Dan
Jonathan Schleifer schreef:
> Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
>
>> Wine could build fine without c++, not sure why everything has to
>> link against the c++ library as it will probably only be needed in
>> winegcc. Also these compiling flags seem kind of agressive.
>>
>
> As I
Am Saturday 21 April 2007 20:13 schrieb Paul Vriens:
>Hi Stefan
>
>the results:
>
>registry.c:576:test_query_value_ex: type set to: 0x0022fe78
>registry.c:1163: Test failed: Expected ERROR_SUCCESS, got 6
>registry: 293 tests executed (0 marked as todo, 1 failure), 0 skipped.
>
>That's because you'r
Am Samstag 21 April 2007 18:44 schrieb Michał W.:
> Please consider incorporating the patch I submit, which improves
> handling of MIDI System Exclusive messages
> in alsa driver. It should be applied to dlls/winealsa.drv/midi.c file.
>
> The patch resolves the following bug:
> http://bugs.winehq.o
Jonathan Schleifer schreef:
> Hi!
>
> This patch makes it possible to build an run wine with the Intel
> compiler.
>
> Here are the environment variables I used to build:
>
> export CFLAGS="-O3 -xP -msse3 -parallel"
> export CXX="icc"
> export CXXFLAGS="-O3 -xP -msse3 -parallel"
> export LDFLAGS="-
Hi!
This patch makes it possible to build an run wine with the Intel
compiler.
Here are the environment variables I used to build:
export CC="icc"
export CFLAGS="-O3 -xP -msse3 -parallel"
export CXX="icc"
export CXXFLAGS="-O3 -xP -msse3 -parallel"
export LDFLAGS="-lguide -lsvml -lstdc++ -paralle
Stefan Leichter wrote:
Am Thursday 19 April 2007 12:14 schrieb Alexandre Julliard:
Stefan Leichter <[EMAIL PROTECTED]> writes:
+/* Recursively delete all the subkeys */
+for (i = 0; i < dwKeyCount && !ret; i++) {
+dwSize = dwMaxSubkeyLen;
+
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> AFAIK you get the DRVM_EXIT message only when winmm is unloading.
>> Alternatively you could do it in response to the DRV_CLOSE message which
>> winmm
>> sends just before it tries to unload the driver.
>>
>> That said I don't see how your cod
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> ok that makes sense. Definitely something wrong in dsound.
>>
>> But I still think that ALSA_DestroyRingMessage should signal any message left
>> in the queue. Imo it just calls for trouble to expect that messages always
>> are added in the rig
Peter Beutner schreef:
> ok that makes sense. Definitely something wrong in dsound.
>
> But I still think that ALSA_DestroyRingMessage should signal any message left
> in the queue. Imo it just calls for trouble to expect that messages always
> are added in the right order.
DestroyRingMessage is ca
Peter Beutner schreef:
> AFAIK you get the DRVM_EXIT message only when winmm is unloading.
> Alternatively you could do it in response to the DRV_CLOSE message which winmm
> sends just before it tries to unload the driver.
>
> That said I don't see how your code in ALSA_MixerExit() could deadlock.
Maarten Lankhorst schrieb:
> Peter Beutner schreef:
>> But this only works if DSOUND_Stop and DSOUND_Release are called from
>> different threads, right?
> It is during shutdown, DSOUND has an internal timer/thread called the
> mixer, it calls DSOUND_Stop because we signalled it to stop playbacking
Maarten Lankhorst schrieb:
> After trying to implement the alsa mixer I came across a problem: If
> winmm is unloading, a deadlock could occur if during unloading it's
> waiting for another thread.
>
> In winmm itself this isn't much of a problem: there aren't any threads.
>
> However, the driver
Peter Beutner schreef:
> But this only works if DSOUND_Stop and DSOUND_Release are called from
> different threads, right?
It is during shutdown, DSOUND has an internal timer/thread called the
mixer, it calls DSOUND_Stop because we signalled it to stop playbacking,
then the program calls idirectsou
Maarten Lankhorst schrieb:
> This fixes an interesting deadlock with the alsa driver:
>
> DSOUND_Stop is called, message is added to thread queue.
> DSOUND_Release is called, message is added to thread queue.
>
> Both are fast messages, so second is added before first.
But this only works if DSO
This patch allows configure.ac to generate a configure script which will
properly find some network functions that require Solaris to include -lsocket
on.
The first AC_CHECK_FUNCS tests connect, and if it's not found in "libc", then
the existing code just adds -lsocket to the list of libraries.
On Saturday 21 April 2007 00:20, Yuval Fledel wrote:
> ntsecpkg.h specifies the interface with Authentication Security
> Support Providers.
This is a quick glance over your file, comparing with the implementation I had
lying around on my box.
> The first 50 lines were imported from w32api. The r
> I've just found another bug in the patch:
> >+ /* Convert to OEM, then output */
> >+ convertedChars = WideCharToMultiByte(GetConsoleOutputCP(), 0,
> >output_bufW,
> >+ len, output_bufA, MAX_WRITECONSOLE_SIZE,
> >+ "?", &usedDefaultChar
No, from this point of view the patch is correct.
>> +/*
>=
>> + * Output a formatted unicode string. Ideally this will go to the console
>> + * and hence required WriteConsoleW to output it, however if file i/o is
>> + * re
Kai Blin schreef:
> I'm not really surprised. That's the reason why gethostbyname is deprecated,
> if I read MSDN correctly. Anyhow, it looks like Windows doesn't return
> 127.0.0.1 unless it doesn't have any other IP address to return. Programs
> can't count on which NIC's IP that will be, tho
James Hawkins wrote:
On 4/20/07, Jeff L <[EMAIL PROTECTED]> wrote:
James Hawkins wrote:
>>
>> Is there a reason why we should not just create a Desktop directory?
>> Seems neater than cluttering up the home.
>>
> I sure wouldn't want some app creating a Desktop directory in my home
> folder if i
On Friday 20 April 2007 17:59, Alexander Nicolaysen Sørnes wrote:
> > > (I suspect that the app developer is misguided, because binding
> > > to just one interface doesn't work well if you have multiple
> > > interfaces, but that's neither here nor there.)
> >
> > Well, actually the developer of th
25 matches
Mail list logo
