Here is a basic stand-alone test program, which I should probably learn
how to implement into the standard testing array.
On my test Windows 7 system with a single processor (4 cores), it outputs the
following:
Testing NtQuerySystemInformationSystemNumaHighestNodeNumber = 0x37, ...):
..
From 750f684d6c836f287d7ddb427f12b28da844736a Mon Sep 17 00:00:00 2001
From: Chris Moeller
Date: Mon, 29 Jul 2013 16:20:14 -0700
Subject: kernel32: Implement GetNumaHighestNodeNumber using correct
NtQuerySystemInformation API
---
dlls/kernel32/process.c | 25 ++---
1 file
From c0c3050e32d8d79596b6ec4dfc8a2a5b5ca76f8b Mon Sep 17 00:00:00 2001
From: Chris Moeller
Date: Mon, 29 Jul 2013 16:19:19 -0700
Subject: ntdll: Implement NtQuerySystemInformation class 0x37, used by
GetNumaHighestNodeNumber
---
dlls/ntdll/nt.c| 14 ++
include/winternl.h
This patch against HEAD does the following in two parts:
Part 1) Implements NtQuerySystemInformation class 0x37, which I have given the
name SystemNumaHighestNodeNumber, since that appears to be all it does. It
currently is limited to simulating a single node system, and returns the
correct err
guess without looking very
deeply into the CRT source code.
From a7ae257aed539fc72f0bc37c85030f8abc181389 Mon Sep 17 00:00:00 2001
From: Chris Moeller
Date: Sun, 28 Jul 2013 16:23:05 -0700
Subject: kernel32: Implemented basic NUMA functions to replace the stubs
---
dlls/kernel32/process.c |
On 10/24/2012 05:16 AM, Maarten Lankhorst wrote:
I'm not sure yet how dsound should be fixed on bigger periods, I believe using
IAudioClock for reporting position *might* be the correct answer, but it's not
properly test yet on behavior, so I chose for the simple solution of directly
reporting ne
On 10/20/2012 05:40 PM, James Eder wrote:
+/* Intel says we need a zeroed 16-byte aligned buffer */
+char buffer[512 + 16];
+XMM_SAVE_AREA32 *state = (XMM_SAVE_AREA32 *)(((ULONG_PTR)buffer + 15) &
~15);
+memset(buffer, 0, sizeof(buffer));
+
+__asm__ __volatile__( "fxsave %0"
ut I'm sure I've done something horribly wrong in terms of
doing it the preferred way.
Thanks,
Chris Teague
From 84445fb85a4a22588af798195fcefd7db31b17fd Mon Sep 17 00:00:00 2001
From: root
Date: Fri, 21 Sep 2012 23:24:43 +
Subject: Fixed LockWindowUpdate
---
dlls/user32/painting.c
On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote:
> @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc)
> /* Temporarily disable the context, so we can see that we can't
> retrieve functions now. */ wglMakeCurrent(hdc, NULL);
> func = wglGetProcAddress("glActiveTe
On Monday, June 18, 2012 11:18:45 AM Andrew Eikum wrote:
> Is there any guarantee that Pulse /will/ give us a sufficient buffer?
> From the API docs[1], it just "tries to assure" that we have the
> requested buffer size, which actually means nothing.
It "tries to assure that at least tlength bytes
On Monday, June 18, 2012 9:31:04 AM Andrew Eikum wrote:
> We chatted a little on IRC this weekend, but thanks again for the
> advice.
No problem. :)
> Mmdevapi sends it data to the lower systems in period-sized chunks,
> and the reported buffer fill level decreases in period-sized chunks.
> But t
On Friday, June 15, 2012 3:39:33 PM Andrew Eikum wrote:
> One thing to note is that PulseAudio has an absurdly high default
> latency (two seconds), and due to its poor API there's no (easy) way
> for us to control it.
The latency is likely caused by PulseAudio setting a much larger tlength (and
On Tuesday, March 27, 2012 8:35:49 PM Henri Verbeet wrote:
> - int pixelattrib = ~0;
> + int pixelattrib = GLX_DONT_CARE;
I want to say there's a reason we used ~0 instead of GLX_DONT_CARE, but it's
been too long that I can't remember. I think it was because GLX_DONT_CARE
didn't include all po
On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote:
> + * This is basically the same as the pa_threaded_mainloop implementation,
> + * but that cannot be used because it uses pthread_create directly
> + *
> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock
> + * pa_threaded_
On Friday, February 24, 2012 1:28:48 PM joerg-cyril.hoe...@t-systems.com
wrote:
>- https://bugs.freedesktop.org/show_bug.cgi?id=46296
> About the need to restart the PA server from time to time
>- https://bugs.freedesktop.org/show_bug.cgi?id=46297
> PA's huge buffering causes iss
On Wednesday, February 22, 2012 11:42:13 AM joerg-cyril.hoe...@t-systems.com
wrote:
> That's why I'll repeat once more and say that DSound's resampler should
> become that one.
>
> My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY
> etc.) tells me it's compatible with such
On Monday, February 13, 2012 10:31:06 PM Нискородов Серёжа wrote:
> Ok, I agree, many "junk devices", bad enumeration methods, okay. But
> why you are against a registry parameter? I'm a power user, I know
> WHAT I do, I want to see all ALSA devices, even "junk". Why I can't do
> that?
Mainly beca
On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
> Chris Robinson wrote:
> > It's not something normal users do, but for "power users" I don't see a
> > problem with asking them to tell Wine about it.
>
> I'm a power user, but for wha
On Monday, February 13, 2012 6:12:00 PM Нискородов Серёжа wrote:
> >> Here is another trouble with snd_ctl_open. Not all devices in alsa
> >> configuration files have a predefined ctl. Especially defined by user,
> >> for example I don't always define a ctls for all my devices in
> >> .asoundconf
>
On Monday, February 13, 2012 2:17:13 PM joerg-cyril.hoe...@t-systems.com
wrote:
> Chris Robinson wrote:
> >Plain mmdevapi can't do rate conversions
> You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
Interestingly, this flag seems to only have an effect for already-initializ
On Monday, February 13, 2012 10:07:45 AM Andrew Eikum wrote:
> On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
> > Hmm, actually it seems winealsa already does this enumerating. Except it
> > hardcodes the plughw: prefix for the device string, uses the card index
>
On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
> > Nope, it won't open in a rate other than 48000hz without plug:. But again,
> > that's fine for mmdevapi as it doesn't support rate conversion by default.
>
> Hmm... Ok. But how it works in Windows? Does you mean that
> applicat
On Friday, February 10, 2012 10:50:33 PM Нискородов Серёжа wrote:
> Not only sample type, but sample rate to. For example, dmix plugin
> have predefined samplerate for mixing, so if WINE send other
> samplerate to it without "plug:" wrapper, in best case you will get
> error message and no sound.
On Friday, February 10, 2012 5:09:05 PM Нискородов Серёжа wrote:
> > There's no $HOME/.asoundrc on any of my systems, yet I'd like to
> > use "plug:dmix" with Wine, e.g. on systems with PulseAudio installed.
> > I can use speaker-test -Dplug:dmix with no trouble.
> > Will your patch make that appea
On Friday, February 03, 2012 2:43:57 PM Dmitry Timoshkov wrote:
> Aric Stewart wrote:
> > -REGFILTER2 *prf2;
> > +static REGFILTER2 *prf2;
>
> What's the point of this change?
It returns a pointer to the pointer, so the variable needs to remain valid
after the function exits. The code d
On Friday, December 30, 2011 1:41:12 PM Jeff Cook wrote:
> Hello all
>
> I am curious about the patch on
> http://bugs.winehq.org/show_bug.cgi?id=18490 and why it's not in
> vanilla. http://bugs.winehq.org/show_bug.cgi?id=18490#c9 seems to be a
> pretty cogent explanation of the issue and the patc
On Saturday, December 24, 2011 9:20:38 PM Alexander E. Patrakov wrote:
> Andrew Eikum converted the buffer position calculation code from fixed
> point to floating point, because floating-point code is more readable.
> I agree with him.
FWIW, I'm not sure using floating point for the position inde
On Wednesday, October 26, 2011 12:35:28 PM Michael Stefaniuc wrote:
> Chris Robinson wrote:
> > imagine some C++ function overrides tripping up with the int/long
> > difference.
> If you use the Wine headers this should actually fix it as it brings the
> numeric constants in l
On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote:
> Hello Jacek!
>
> Jacek Caban wrote:
> > mingw-w64 project imports some of our headers, including most of d3d
> > headers. They would probably prefer to keep them with 'l' modifier since
> > that's the right thing to do. Given th
On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote:
> On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote:
> >A configuration option (in
> > winecfg/control panel) would be needed to set it into a different mode.
> > Windows has some
On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote:
> Would someone with a better knowledge of Wine and/or ALSA be able to
> assist me in tracking down the source of this bug?
Hi.
Part of the problem is the way Wine attempts to "detect" a default format from
ALSA. ALSA doesn't report
Hi.
On Tuesday, October 11, 2011 3:31:59 PM Andrew Eikum wrote:
> The specific drvcaps values and error code were tested against Windows
> 7.
How does this affect the primary buffer? Is it not allowed to be a hardware
buffer either?
On Monday, September 19, 2011 4:09:29 PM Francois Gouget wrote:
> I prefer this construct as using IsBadReadPtr() would introduce a race
> in is_valid(). Of course calling is_valid() is in itself racy anyway. So
> I don't mind switching over if that's preferred (the code would have
> fewer lines).
On Thursday, August 04, 2011 12:55:51 PM joerg-cyril.hoe...@t-systems.com
wrote:
> - Except for 48000x2x16 and 48000x2x8, all standard PCM formats I
> tested yield S_FALSE, i.e. they are rejected. That means that the
> native mixer accepts integer formats at its nominal rate (48000),
> but
On Saturday, June 18, 2011 8:32:31 PM Dan Kegel wrote:
> Matches native behavior. Makes at least one app happier; see bug 27532.
Just to toss in my comments, the "native" behavior referred to is the behavior
of Creative's DLLs, but Creative's DLLs aren't the only ones available for
Windows. Ope
On Monday, May 23, 2011 12:51:37 PM Daniel Scharrer wrote:
> return ((D3DVALUE [4][4])&_11)[r][c];
Something like this should work:
return ((D3DVALUE(*)[4])&_11)[r][c];
, i paid off all my debt
http://tulsamarketplace.com/redirect.php?to=aHR0cDovL3d3dy5jbmJjNy5jb20vP3BpZD03NTg2NjQ=
On Wednesday, May 11, 2011 6:40:42 AM joerg-cyril.hoe...@t-systems.com wrote:
> Several bugs were fixed by returning the success value that apps would get
> on native, instead of returning the value that would be consistent with
> the specification and implementation state in Wine, e.g. NOTSUPPORTE
On Friday, April 29, 2011 7:18:47 AM Marcus Meissner wrote:
> If they are not declared hidden, the -fPIC compile generates PLT
> relocations for those symbols, even if they are internal to the dll (the
> compiler does not know what to export during our build).
>
> With the hidden attribute these g
On Sunday, March 27, 2011 1:57:17 AM Stefan Dösinger wrote:
> BltOverride is a horrible mess, and I'm afraid the patch doesn't make it
> any better. A long time ago Roderick started a cleanup to give the blit
> selection routine a more structured approach, but he never finished the
> work. Unfortun
IDirect3DDevice9::StretchRect is used to stretch-blit between video memory
surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself
will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However,
BltOverride will not accelerate the blit if neither surface is a swapchai
On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote:
> This patch was made against the origin, so if you've applied my previous
> patch, remove that one before applying this one.
> This patch makes the error message use ERR_(winediag) instead of just
> ERR and is closer in style to the other
On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote:
> On 03/20/2011 05:14 AM, Pali Rohár wrote:
> > Can anybody review my patch?
>
> Not sure what you trying to do exactly. Wine already has wrapper that makes
> all wine binaries executable after they are being installed into system.
Wine
An updated attempt at the mmap override patch that I previously sent. This
version properly uses a signed type for the mmap wrapper (as off_t/off64_t are
signed types), fixes a few things with the munmap wrapper relating to
truncated and sliced file_views, and implements a mremap wrapper for Lin
(I only implemented it to satisfy a simple demo app), but perhaps it may be
a good starting point.
/***
* Copyright (C) 2008 by Chris Robinson *
On Sunday, December 12, 2010 2:19:42 pm Louis Lenders wrote:
> +#define USER_HZ_TO_TICKSPERSEC(x,y) (ULONGLONG)1000 * x / y
I'd recommend adding proper parenthesis, to avoid potential problems with
order-of-operations.
#define USER_HZ_TO_TICKSPERSEC(x,y) ((ULONGLONG)1000 * (x) / (y))
Th
On Tuesday, September 21, 2010 7:06:30 am Zachary Goldberg wrote:
> Hello,
>
> I found the following article/commit very interesting this morning.
> Has anybody else been looking at this and put thought into whether it
> will work with Wine?
IIRC, it's been discussed before, and it simply wouldn'
This is a patch that attempts to override mmap, mmap64, and munmap so that
host libs can used memory from the Wine heap instead of being restricted to
the address space Wine leaves unreserved. It is based on Albert Lee's patch
found here:
http://bugs.winehq.org/show_bug.cgi?id=13335#c170
It ha
On Monday, September 20, 2010 2:42:51 pm Tijl Coosemans wrote:
> On FreeBSD off_t is always 64 bit.
Even on 32-bit systems? I'll have to take that into account, then.
On Monday, September 20, 2010 2:20:00 pm Tijl Coosemans wrote:
> I've attached a patch that takes a different approach. I still need to
> test it more extensively, but is this patch acceptable in principle?
>
> It adds an mmap symbol to the loader thereby overriding the libc symbol.
I've actually
On Tuesday, September 14, 2010 6:56:36 am Henri Verbeet wrote:
> Come to think of it though, doesn't ALSA accept floating point values
> itself anyway?
Only if the device does. The dmix/default device usually can, but there's no
guarantees for the various hw:x,y or surround* devices.
On Tuesday, September 14, 2010 3:38:47 am Henri Verbeet wrote:
> Is that correct in the first place though? This will produce a
> non-uniform mapping for positive and negative values. IIRC the common
> way to do these kinds of mappings is "((x * (2^n - 1)) - 1) / 2",
> which would be "x * 127.5f -
On Monday, September 13, 2010 12:55:43 pm Owen Rudge wrote:
> +if (*v < -1.0f) d = -128;
> +if (*v < 0.0f) d = *v * 128.0f;
> +if (*v >= 0.0f) d = *v * 127.0f;
> +if (*v > 1.0f) d = 127;
The way these checks are written out can cause problems, particularly with th
On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote:
> +*(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 +
> 0.5;
Is it safe to call le32 on a float? Especially one that's going to be used
more? If the system is big-endian, the float/integer will need to be in big
On Saturday, September 04, 2010 11:09:03 pm Austin English wrote:
> -frames_per_period = snd_pcm_bytes_to_frames(wwi->pcm,
> wwi->dwPeriodSize);
> +snd_pcm_bytes_to_frames(wwi->pcm, wwi->dwPeriodSize);
The whole call can probably be removed if the result isn't used anywhere. The
function
On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote:
> These patches add support to DirectSound that allow the conversion of
> 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty
> 5) output their audio in this format, and media players such as
> foobar2000 have support f
On Wednesday, August 11, 2010 3:12:23 am David Adam wrote:
> Hello,
>
> some comments about this patch
> +if (hr != S_OK) return FALSE;
> +else return TRUE;
>
> could be simplified as
> return SUCCEEDED(hr);
SUCCEEDED encompasses more than just S_OK (S_FALSE, for instance; basically
any
On Tuesday, July 20, 2010 2:54:24 pm Luke Bratch wrote:
> The attached uses that experimental extension [1] to report the correct
> total memory for cards that support it, while sticking with the existing
> hard coded values and code layout for those that don't.
I think the extension should be che
On Tuesday, July 20, 2010 2:28:44 pm Louis Lenders wrote:
> +TRACE("iface %p, adapter %u, mode %p.\n", iface, adapter, mode);
> +TRACE("iface %p, adapter %u, mode %p, rotation %p\n", iface, adapter,
> mode, rotation);
This doesn't look right. You probably only need the second TRACE stateme
On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
> 'FIXME's that contain no variable
> information are completely redundant after their first report. After
> the first reminder, the additional reports are just noise. They add no
> additional information in terms of action required
On Friday, May 21, 2010 11:59:40 am Michael Stefaniuc wrote:
> mpg123_getformat() is a host native lib aka a unix lib thus expects a
> "unix long". A "unix long" translates to LONG_PTR in Wine. My patch is
> actually a no-op.
The lib is also available for Windows, and AFAIK there's no reason winem
Now to the list...
On Friday, May 21, 2010 9:32:17 am you wrote:
> Chris Robinson wrote:
> > On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote:
> >> @@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi,
> >>
> >>
On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote:
> @@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi,
>
> if (ret == MPG123_NEW_FORMAT)
> {
> -long rate;
> +LONG_PTR rate;
> int channels, enc;
> mpg12
On Sunday 04 April 2010 3:41:00 am Marcus Meissner wrote:
> Yes, but those INT21 calls are in Win16 protected mode, not DOS real mode.
>
> And VXD ... I doubt anything uses it.
Back in the Win95 era, I remember libnet having a DOS network driver that
hooked into winsock.vxd. It allowed a DOS app
On 4/3/2010 11:34 AM, Alexandre Julliard wrote:
> Stefan Dösinger writes:
>
>
>> Am 02.04.2010 um 02:08 schrieb chris ahrendt:
>>
>>
>>> Just my 2 phennings worth on this...
>>> Why reinvent the wheel... I would say instead of doing the emu
to worry about it...
chris
On Wednesday 31 March 2010 2:00:57 pm Maarten Lankhorst wrote:
> +local_contexts = palcIsExtensionPresent(NULL,
"ALC_EXTX_thread_local_context");
Missed a spot? Don't forget to use the correct function names for the
completed extension, too.
atus: executing Makefile commands
> cat: Make.tmp: No such file or directory
> config.status: error: could not create Makefile
> make: *** [Makefile] Error 1
>
> Compilation failed, aborting install.
Ideas?
Chris
FWIW, you can query ALC_DEFAULT_ALL_DEVICES_SPECIFIER (with ENUMERATE_ALL),
ALC_DEFAULT_DEVICE_SPECIFIER (standard playback), and
ALC_CAPTURE_DEVICE_SPECIFIER (record) to get the default device as seen by
OpenAL, instead of taking the first as the default.
Just make sure to query the default af
It may be a good idea to remove the experimental extensions from the file:
AL_EXT_buffer_sub_data
AL_EXT_sample_buffer_object
ALC_EXT_thread_local_context
until they're finalized. I'm hoping ALC_EXT_thread_local_context will be done
in time for OpenAL Soft 1.12, but there could still be changes
On Sunday 28 February 2010 11:23:30 pm Marcus Meissner wrote:
> A library should be ever built against one model and not change function
> ABI depending on a preprocessor define ... This will just break in funny
> ways.
>
> In libmpg123 1.10.0 it does not do evil hacks for me, it has #if 0 around
On Sunday 28 February 2010 1:13:44 pm Marcus Meissner wrote:
> Hi,
>
> Copy in the mpg123.h header from the library so we do not need it for
> building. (it is also LPGL)
>
> Dynamically link from libmpg123.so.0.
> (Chances are very good that ABI stays stable.)
>
> This allows me providing a MP3
orked just fine without the
directory...
chris
On Tuesday 19 January 2010 11:38:18 pm Stefan Dösinger wrote:
> Am 20.01.2010 um 01:08 schrieb Chris Robinson:
> > The comment says that it's using MinZ/MaxZ to suppress depth clipping,
> > which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be
> > enabled i
On Tuesday 19 January 2010 3:37:50 pm Henri Verbeet wrote:
> 2010/1/20 Chris Robinson :
> > I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in
> > state_clipping if you're going to bypass the depth range hack with it.
> > Currently it's only call
On Tuesday 19 January 2010 2:52:28 pm Henri Verbeet wrote:
> ARB_depth_clamp should give pretty much the desired behaviour by clamping
> instead of clipping depth values outside the depth range.
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in
state_clipping if you're going t
tools/widl/proxy.c 591 The scope of the variable first_func
can be reduced
tools/winebuild/import.c227 The scope of the variable i can be
reduced
tools/winebuild/parser.c913 The scope of the variable i can be
reduced
tools/winebuild/res32.c 281 The scope of the variable i can be
reduced
tools/winebuild/res32.c 600 The scope of the variable err can be
reduced
Chris
This doesn't seem correct to me. According to MSDN, sprintf_s checks for valid
formatting chars (in addition to the buffer and format arguments) and invokes
an invalid parameter handler if something bad turns up. It then returns -1
with errno set to EINVAL if execution is allowed to continue. Ad
On 12/29/2009 11:17 PM, Alasdair Sinclair wrote:
>
>return size;
ok will file a false positive... thanks
chris
Same problem here as well
Chris
have to move
the wine
window to the bottom of the screen. It looses focus (turns grey) but does not
go to the background...
Chris
sue so you might want to search the appdb mailing list as
well as the wine-devel list and contact the other interested parties.
Chris
On Sat, Dec 12, 2009 at 4:11 PM, Sean Hodges
wrote:
> Hey all,
>
> I'm hoping to write an application that interfaces with the AppDB
> database.
On Friday 04 December 2009 3:53:46 pm Stefan Dösinger wrote:
> Am 04.12.2009 um 18:51 schrieb Chris Robinson:
> > Though you'll still need a way to talk to the hardware. Using
> > ALSA/OSS/etc directly has proven problematic with not only the current
> > desig
On Friday 04 December 2009 7:50:59 am Stefan Dösinger wrote:
> Wrt OpenAL, I am opposed to using it for our sound system. I think its a
> good idea for the transition to Win7, as a first driver and probably later
> reference driver. But I think we need an exit strategy to get rid of
> OpenAL as
On Thursday 03 December 2009 3:57:49 pm Robert Reif wrote:
> I believe the approach you are taking moving openal into direct sound is
> not a good idea and is going to create a lot of regressions that can not
> be fixed with your current approach.
>
> Windows audio programmers know that they can g
Hi.
On Monday 30 November 2009 1:56:20 pm Maarten Lankhorst wrote:
> +if (This->playing)
> +{
> +pos2 = This->format->nSamplesPerSec / 100;
> +pos2 *= This->format->nBlockAlign;
> +pos2 += pos1;
> +if (!This->looping && pos2 > This->buf_size)
> +
I'm not sure it's very appropriate to add this yet, since the extension isn't
finalized. Until it's finalized, there could be changes that modify the API
calls (I don't expect changes, but it's best to err on the side of caution, I
think).
The alBufferDataStatic patch is fine, though.
Roderick Colenbrander wrote:
> On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt wrote:
>> Roderick Colenbrander wrote:
>>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote:
>>>> Ok going through and looking at the next failure in wine tests I found
>>>
Roderick Colenbrander wrote:
> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote:
>> Ok going through and looking at the next failure in wine tests I found this
>> one :
>>
>>
>> If you look at the code its:
>>
>>
>> 779 color = getPixel
ld normally read/write from
Thanks for any ideas,
Chris
result is implementation
specific.
so the test seems to be assigning the wrong values to the RGB Correct?
chris
Roderick Colenbrander wrote:
> On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger
> wrote:
>> Am 23.11.2009 um 21:00 schrieb chris ahrendt:
>>> The test fails with :
>>>
>>> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended
>>
g the above code the first one should return a S_OK
saying that it flushed the query code
Then the second call should return a S_FALSE because the query has nothing in
it.
Thoughts? Explinations??? Inpuut...
Chris
Alexandre Julliard wrote:
> chris ahrendt writes:
>
>> Alexandre Julliard wrote:
>>> chris ahrendt writes:
>>>
>>>> Well its been a few since I ran CPP Check and so I ran it today and got
>>>> the following:
>>>>
>>>&
Alexandre Julliard wrote:
> chris ahrendt writes:
>
>> Well its been a few since I ran CPP Check and so I ran it today and got the
>> following:
>>
>> New CPP Check Errors for the Wine Code:
>>
>> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c
/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized
variable: InfoBuffer
[/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error)
Resource leak: fd
[/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable:
page_size
Chris
[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1101]: (possible error)
Resource leak: stream3
[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible error)
Resource leak: stream4
[/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory
leak: mem
Chris
[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible
error) Resource leak: stream4
[/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error)
Memory leak: mem
[/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (error) Array
index out of bounds
Chris
]: (possible
error) Resource leak: fd
Chris
]: (error) Invalid number
of character ({). Can't process file.
I think the last is a bug in CPPCheck and will report it to them....
chris
1 - 100 of 812 matches
Mail list logo
