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"
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];
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 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.
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
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
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 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.
On Thursday 24 September 2009 11:54:33 am Aric Stewart wrote:
> +@ stdcall ShellHookProc(long long long)
...
> +LRESULT CALLBACK ShellHookProc(DWORD a, DWORD b, DWORD c)
Doesn't CALLBACK signify cdecl, not stdcall?
On Tuesday 22 September 2009 7:53:08 am Ben Klein wrote:
> Worth trying my sample code on non-GCC compilers then:
With all optimizations off (if I had non-GCC compilers, I'd try them).
But still, I'm not really saying this is a problem (especially since the
FIELD_OFFSET macro does this, and is u
On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
> It actually does not dereference anything.
Does the C standard specify that taking the address of a struct member being
dereferenced doesn't actually cause a dereference, instead just offsetting?
Doing foo-> is identical to (*foo)
I have a different patch that will fix this, that also fixes a problem with
error states.
On Thursday 10 September 2009 9:43:02 am Juan Lang wrote:
> +/* Define to 1 if you have the `sched_getaffinity' function. */
> +#undef HAVE_SCHED_GETAFFINITY
> +
...
> +#ifdef HAVE_SCHED_GET_AFFINITY
> +#define __USE_GNU
> +#include
> +#endif
Looks like a typo there.
On Tuesday 01 September 2009 1:59:54 am Henri Verbeet wrote:
> I suppose 32-bit reads are atomic on x86, provided the variable is
> aligned correctly, but shouldn't access to CurrentCtx technically be
> synchronized?
Probably, but I'm not sure it would be beneficial. If the thread can be
interrup
On Wednesday 26 August 2009 9:27:42 pm Vitaliy Margolen wrote:
> Tested few games that had issues with native OpenAL from Creative (both
> windows dll and thunked old Linux version): STALKER SoC, STALKER CS,
> Psychonauts. So far so good! Great job.
>
> Thanks Chris, greatly appreciate your work on
On Tuesday 25 August 2009 6:40:30 am Stefan Dösinger wrote:
> I'll give it a try with my games. The old thunk from a while ago already
> worked very will with those games.
>
> OpenAL seems to have an extension system like opengl. If there is a
> function that returns an extension string we'll want
On Wednesday 19 August 2009 2:26:37 pm Matteo Bruni wrote:
> What about using more popular libraries as libmad, lame or maybe
> gstreamer to decode mp3 files? I believe someone previously said that
> gstreamer is also available on Mac.
libmad is GPL, and IIRC lame uses libmpg123 or libmad for deco
On Thursday 13 August 2009 12:03:02 pm Reece Dunn wrote:
> But there is a reason for using our own version -- the HeapAlloc/Free
> and Wine tracing changes that Aric mentioned in the initial email. So
> for that reason, it won't be practical to dynamically link.
Needing to change malloc->HeapAlloc
On Thursday 13 August 2009 11:23:45 am Juan Lang wrote:
> Developer resources are a much bigger constraint.
All the more reason to use the existing libmpg123 instead of trying to
maintain our own version, IMO.
On Wednesday 12 August 2009 1:10:15 pm Aric Stewart wrote:
> I have a few questions. Right now I have the smallest subset of files
> from libmpg123 that are needed to compile and work in the wine framework
> (mostly) unmodified. I have replaced all the malloc/free calls with
> HeapAlloc/HeapFr
On Wednesday 15 July 2009 2:40:08 am Adam Strzelecki wrote:
> You can run X11 app on Windows as well, as there're several X11
> servers. But none would appreciate that ;) And none would say you
> don't have to use WinAPI to program Windows.
Actually, I know quite a few that would say you don't nee
It may still be important to do this, if glGetError is ever used directly to
check for errors. Errors that are normally caught by checkGLError would then
be left for a later call to glGetError to pick up.
On Tuesday 14 July 2009 7:26:39 am Adam Strzelecki wrote:
> Look, anyway Obj-C is supposed to be used in Wine only for Mac
> support, and not for anything else. Any developer that knows how to
> program Mac knows Obj-C so there's nothing wrong with constraint that
> only developers that know Obj-C
On Thursday 09 July 2009 1:46:59 am Rolf Kalbermatter wrote:
> Adam Strzelecki [mailto:o...@java.pl]
>
> > Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is
> > NextStep based objective oriented GUI & OS. And Obj-C is a
> > basement of both NextStep and OSX. So if you want to write
> > OS
On Friday 19 June 2009 10:21:33 am Alexandre Julliard wrote:
> Steven Edwards writes:
> > I don't think this change is right. It is a very common convention to
> > use mingw32 as a generic convention for 32bit x86. It seems the best
> > practice would be if mingw32 is passed then to assume a sensi
On Tuesday 16 June 2009 8:44:36 pm Stefan Dösinger wrote:
> There is such a DLL around - search the wine-devel and wine patches
> archives from it. Alexandre said he'd accept such a openal->openal
> thunk(but not an openal winmm driver). The problem why it is not included
> yet is that the latest s
On Tuesday 16 June 2009 3:33:12 am Arthur Taylor wrote:
> I can't imagine stopping pulseaudio just so I can listen
> to music through foobar2000, as that would stop all my voice chats,
> notification sounds, and other native audio, etc.
There is no need to use PulseAudio if the issue you have is y
On Sunday 07 June 2009 2:05:41 pm Frank Richter wrote:
> On what graphics cards is that extension supported?
> DF16 is supported since the R300. It appears that float depth formats
> are much younger, so it seems unlikely DF16 is actually a float format
> internally.
Just to note, there is a much
On Wednesday 29 April 2009 1:58:53 am Massimo Del Fedele wrote:
> That's why I've chosen the "new approach". As a new driver it can't
> break anything, so it could (but I guess it won't) be introduced as
> an "alternative" display driver in parallel to winex11.
A problem with it being a separate d
On Monday 06 April 2009 6:58:31 pm Vincent Povirk wrote:
> On Mon, Apr 6, 2009 at 8:53 PM, Chris Robinson wrote:
> > Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
>
> On a real windows system, it won't.
It won't by default, but can't a user create it?
On Monday 06 April 2009 6:39:47 pm Vincent Povirk wrote:
> Even if you check for a Windows path first, that will still break the
> python tests (they check for /bin/sh and expect it to not exist).
Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
> That might be fine for mount points and mountable devices, but how
> could you accurately determine the filesystem type for an arbitrary
> directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME -> /home/), resolve all symlinks, then see which
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
> Isn't that more-or-less what I suggested?
>
> The biggest problem would be detecting what filesystem a given
> directory is on (noting that wine's "drives" are not even mounted
> partitions). Expert parsing of /etc/mtab would indicate it on Linu
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
> My suggestion is a drop-down box in the "Advanced" tab of "Drives" to
> control filesystem type (separate from disk type, as is suggested in
> Comment #7 on 17938). It shouldn't be important for floppies or even
> CD-ROMs, but the options could
On Monday 23 March 2009 5:10:54 am Henri Verbeet wrote:
> I'm not sure how much we should care about the ABI as long as the API
> is reasonably stable, but my impression was that FFmpeg has stabilized
> quite a bit in recent years.
It was actually just about a month or so ago where a project I was
I wouldn't recommend this patch as being very safe. Having dealt with ffmpeg,
my experience has been that it's ABI is not stable (the .so version number
increments often, forcing recompilations). And when trying to update to new
lib versions, things sometimes mysteriously break.
Ultimately, FFm
On Wednesday 25 February 2009 9:22:29 am Vincent Povirk wrote:
> This discussion has been assuming that .exe files are somehow special
> because they are programs
Actually, I'm saying just the opposite. They are *not* special because they
are programs, and should honor the executable bit just lik
1 - 100 of 252 matches
Mail list logo
