On 5/25/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
This patch will dynamicly load the needed GL_ARB_multitexture functions, adds
the needed function prototypes and defines to wined3d_gl.h and gets rid of a
GL_VERSION compile check. The patch also removes a few lines of code in
drawp
All of these apply to the latest Git tree, and should come after my
last patch submission to wine-patches, but it shouldn't matter. I'm
just looking for a little more feedback on these before I submit.
This should lay the groundwork to begin implementing GLSL opcode
generation. I've hacked aroun
EA Durbin wrote:
If someone could help me work on this it would be much appreciated as
I'm kind of rusty in C, I'm a perl monger by trade and not very familiar
with wine's msi innerworkings.
Thanks for the detailed analysis. I don't have time to help you fix
this at the moment, but will ge
Alexandre Julliard wrote:
> Emmanuel Maillard <[EMAIL PROTECTED]> writes:
>
>>All callback used by CoreAudio/AudioUnit are call from a thread
>>created by CoreAudio.
>>Its why i can't use debug channels, critical section and call
>>DriverCallback directly ...
>
> Yes, you can't do much without a
Google has indeed been working on Picasa, and it's finally available for
download at
http://labs.google.com/
For the curious, here are a few tidbits about how it came to be.
When Google wanted to port Picasa to Linux, they faced a
problem: the Picasa team was busy working on new projects, and
h
Currently the MSI Installer is working backwards, In the file files.c it
reads the files from the msi package and iterates through them and queries
the Media table in order by LastSequence. The sort order for the media table
should be DiskId according to MSDN. Just changing the sort order wont w
>From trying to build this I also found that
1) @COREAUDIO@ isn't defined to '-framework CoreAudio'
anywhere in the build system.
2) The driver doesn't appear in the list of audio
drivers in winecfg
Right now when trying to play audio in winamp, it
crashes, though getting #2 cleaned up may fix thi
I just saw the May issue of Linux Journal and it has an article titled
"Running Sound Applications Under Wine". It's written by Dave
Phillips and it's pretty good. Things seemed to work about as well as
you'd expect, well, maybe even better than a lot of you would expect.
Programs installed ok,
Hi,
Alexander N. Sørnes wrote:
> Is there any reason why this patch was rejected? I am not used to
> sending AppDB patches, so please let me know if there is something wrong
> with it.
>
> This patch fixes some typos reported by Rich, and a few grammatical
> errors I found while fixing it.
>
>
>
Is there any reason why this patch was rejected? I am not used to
sending AppDB patches, so please let me know if there is something wrong
with it.
This patch fixes some typos reported by Rich, and a few grammatical
errors I found while fixing it.
Regards,
Alexander N. Sørnes
Index: testRes
Emmanuel Maillard <[EMAIL PROTECTED]> writes:
> All callback used by CoreAudio/AudioUnit are call from a thread
> created by CoreAudio.
> Its why i can't use debug channels, critical section and call
> DriverCallback directly ...
Yes, you can't do much without a valid thread. That's really a brok
I usually apply patches to the appdb code. I probably missed your
email due to the very high volume on wine-devel for wine patches
relative to appdb patches. Was did it have "AppDB" at the front of
the subject? Did you copy me on it?
Chris
On 5/25/06, EA Durbin <[EMAIL PROTECTED]> wrote:
I
Le 25 mai 06 à 20:27, Alexandre Julliard a écrit :
Emmanuel Maillard <[EMAIL PROTECTED]> writes:
Sadly no, i can't, Wine debug channels relays on NtCurrentTeb which
can't be call in AudioUnit IO thread, make it crash or worse.
But I can remove them all.
Is the audio library really calling o
Emmanuel Maillard <[EMAIL PROTECTED]> writes:
> Sadly no, i can't, Wine debug channels relays on NtCurrentTeb which
> can't be call in AudioUnit IO thread, make it crash or worse.
> But I can remove them all.
Is the audio library really calling our code in a thread that we
haven't created ourselv
Emmanuel Maillard <[EMAIL PROTECTED]> writes:
Authors:
Ken Thomases
Emmanuel Maillard
Changelog:
Initial Audio Driver for Mac OS X.
Could you please replace the fprintfs by the proper Wine debug macros?
Sadly no, i can't, Wine debug channels relays on NtCurrentTe
Jeff L <[EMAIL PROTECTED]> writes:
> +hr = ScriptBreak(pwcChars, cChars3, &psa2, &psla);
> +ok(hr == S_OK, "ScriptBreak Stub should return S_OK not %08x\n",
> (unsigned int) hr);
This can't possibly work, you are passing complete garbage to that
function. Have you really tested that on W
Is there any way to expedite the patch submission process. I submitted a
patch to wine-patches quite a while ago for the AppDB TestResulsts.php page
as outlined in bug 5155. How long does this take to implement?
Emmanuel Maillard <[EMAIL PROTECTED]> writes:
> Authors:
> Ken Thomases
> Emmanuel Maillard
>
> Changelog:
> Initial Audio Driver for Mac OS X.
Could you please replace the fprintfs by the proper Wine debug macros?
Also it would be nice if you could send only your own code; I
Am Mittwoch, den 24.05.2006, 19:51 +0200 schrieb Emmanuel Maillard:
> This patch is the initial Audio Driver for Mac OS X, quiet big
> (contain all winecoreaudio dir) tell me if you want i split this in
> separated patches.
The "Flatten DLL Directories" project
( http://wiki.winehq.org/Flatte
* On Thu, 25 May 2006, Saulius Krasuckas wrote:
> I'am running wine from a local src tree, so I had to compile this way:
>
> $ tools/winegcc/winegcc -Btools/winebuild/ -B/usr/bin/ -g sysfont.c -Ldlls
> -Llibs -Iinclude -mwindows
Sorry, -B/usr/bin is a leftover from my experiments and isn't neede
On Thu, May 25, 2006 at 04:49:04PM +1000, Troy Rollo wrote:
> The attached sample program demonstrates a bug in font handling that can lead
> to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32".
> Run the resulting a.out, and you will see the letter "C" in the top left
> c
* On Thu, 25 May 2006, Troy Rollo wrote:
> The attached sample program demonstrates a bug in font handling that can
> lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32
> -lcomdlg32".
I'am running wine from a local src tree, so I had to compile this way:
$ tools/winegcc/winegcc
22 matches
Mail list logo