Joris Huizer wrote:
Looking at git commit dcb3e52e2dfd0d6e494164932fb2b684d463a005, it seems,
passing a NULL size pointer to GetUserNameEx[AW] is likely to crash.
You may want to test whether Windows versions crash on it, and check for it if
needed.
HTH, Joris
There is also another one (menti
2009/4/9 Michael Stefaniuc :
> NACK.
>
> remi.assai...@free.fr wrote:
>>
>> I'm submitting the PulseAudio patch from Arthur Talyor.
>
> Guys, stop doing that as it doesn't increases the chance of the patch being
> accepted; quite the contrary.
>
>> As most distros have PulseAudio by default Wine sh
On Wed, Apr 8, 2009 at 6:08 PM, Koro wrote:
> Isn't that why WINE has the Z: drive that maps to / anyway?
>
Wine has Z: so that in its default state all Unix paths can map to a
Windows path. However, Wine cannot rely on Z: to always map to /. A
Wine without Z: is a perfectly valid configuration (
Oleh R. Nykyforchyn wrote:
I also use wine in somewhat weird way. E.g. I use WinEdt editor under wine to
edit TeX files, and it can launch Linux executables like latex, xdvi, dvips and
so on.
WinEdt takes native Unix paths when it opens files and then passes them to Linux
executables. I cannot
Rémi Assailly wrote:
[resent]
Let's see.
This feature has been confirmed by popular vote at
http://bugs.winehq.org/show_bug.cgi?id=10495
They should stop voting for a redundant feature.
Nobody submitted to wine-patches before, I prefer let Alexandre choose
what he wants to do with it.
*Sigh*
Am Mittwoch, 8. April 2009 17:12:01 schrieb Vincent Povirk:
> This should fix bug 15789.
> And he tells me that he's too busy to send the change in, and I should do
> it if I want it to happen soon.
Well, the main reason is that I don't have the games in question to test the
patch myself.
The sa
Am Mittwoch, 8. April 2009 16:16:06 schrieb John Whitlock:
> For my curiosity, why can't we use /proc for card detection?
Because it isn't portable. Wine runs not only on Linux, but also on Solaris,
Mac OS X, *BSD, ...
On Mon, Apr 6, 2009 at 1:05 PM, AllenDavidNiven
wrote:
> who can i pay to make this on the wine that i have
> is $100 ok ?
>
That's generous of you, but also humorous. I can't remember the last
estimate we had of how much work it would take, but it's on the order
of tens of thousands of dollars.
[resent]
Let's see.
If distros include this driver, they >> This feature has been
confirmed by popular vote at
http://bugs.winehq.org/show_bug.cgi?id=10495
They should stop voting for a redundant feature.
Nobody submitted to wine-patches before, I prefer let Alexandre chose
what he wants
Let's see.
If distros include this driver, they
>> This feature has been confirmed by popular vote at
>> http://bugs.winehq.org/show_bug.cgi?id=10495
>They should stop voting for a redundant feature.
Nobody submitted to wine-patches before, I prefer let Alexandre chose what he
wants to do wi
For my curiosity, why can't we use /proc for card detection?
If the right thing to do is create a device string database, then it seem
the registry override patch is the way to go. This way, the bug is
addressed today and users can move on. In the future, when the device
string database is in pl
Hi!
[I'm not subscribed, I hope I got the forged in-reply-to header right]
Ben Klein wrote:
> This is what I meant about magic translation. It *shouldn't* work, but
> I'm aware that it does. DOS/Windows uses backslash as the delimiter
> when reporting and storing paths. Is the behaviour of magic
Looking at git commit dcb3e52e2dfd0d6e494164932fb2b684d463a005, it seems,
passing a NULL size pointer to GetUserNameEx[AW] is likely to crash.
You may want to test whether Windows versions crash on it, and check for it if
needed.
HTH, Joris
I resent because the first feedback was "one patch per email".
The first patch is from another developer. I want to make sure he gets
credit for the work, and the only way I can see doing that is to cleanly
separate his patch from mine. Since I started my work from there, it's the
first patch.
A
who can i pay to make this on the wine that i have
is $100 ok ?
Erich Hoover wrote:
Progress on this issue is being tracked in the bug:
http://bugs.winehq.org/show_bug.cgi?id=9649
There is a patch for an old version of Wine that will sync slowly:
http://www.winehq.org/pipermail/wine-patches/20
[resent]
Let's see.
This feature has been confirmed by popular vote at
http://bugs.winehq.org/show_bug.cgi?id=10495
They should stop voting for a redundant feature.
Nobody submitted to wine-patches before, I prefer let Alexandre choose
what he wants to do with it.
If they want to have it the
2009/4/8 Oleh R. Nykyforchyn :
> On Wed, 8 Apr 2009 09:46:26 -0600
> Erich Hoover wrote:
>
>> On Wed, Apr 8, 2009 at 9:07 AM, Luke Benstead wrote:
>>
>> > ...
>> >
>> > This is probably a really dumb question... but why does wine support
>> > UNIX paths? What is the circumstance where a Windows a
On Wed, 8 Apr 2009 09:46:26 -0600
Erich Hoover wrote:
> On Wed, Apr 8, 2009 at 9:07 AM, Luke Benstead wrote:
>
> > ...
> >
> > This is probably a really dumb question... but why does wine support
> > UNIX paths? What is the circumstance where a Windows application will
> > be trying to access a
NACK.
remi.assai...@free.fr wrote:
I'm submitting the PulseAudio patch from Arthur Talyor.
Guys, stop doing that as it doesn't increases the chance of the patch
being accepted; quite the contrary.
As most distros have PulseAudio by default Wine should provide upstream
support.
No, not reall
remi.assai...@free.fr wrote:
Hi all,
I'm submitting the PulseAudio patch from Arthur Talyor.
As most distros have PulseAudio by default Wine should provide
upstream support.
Both Fedora and Mandriva have included this work and it is reported to
work very well.
I used latest patch from http:/
On Wed, Apr 08, 2009 at 09:16:17PM +0200, remi.assai...@free.fr wrote:
> Hi all,
>
> I'm submitting the PulseAudio patch from Arthur Talyor.
> As most distros have PulseAudio by default Wine should provide upstream
> support.
> Both Fedora and Mandriva have included this work and it is reporte
Luke Benstead writes:
> That sounds like a far better way of doing it. Perhaps though, if that
> method was implemented, passing a program path directly into wine
> (wine ~/foo.exe) would be a special case (without a \\?\ prefix). From
> a users point of view that's what I'd expect, as you haven'
2009/4/8 Alexandre Julliard :
> Luke Benstead writes:
>
>> This is probably a really dumb question... but why does wine support
>> UNIX paths? What is the circumstance where a Windows application will
>> be trying to access a native file or directory? The only example I can
>> think of is that an
Luke Benstead writes:
> This is probably a really dumb question... but why does wine support
> UNIX paths? What is the circumstance where a Windows application will
> be trying to access a native file or directory? The only example I can
> think of is that an app has specifically been written to
On Wed, Apr 8, 2009 at 9:07 AM, Luke Benstead wrote:
> ...
>
> This is probably a really dumb question... but why does wine support
> UNIX paths? What is the circumstance where a Windows application will
> be trying to access a native file or directory? The only example I can
> think of is that a
Andreas Rosenberg wrote:
Thanks for your hints, Paul.
I added some tests for the Ansi variant of the function
and fixed the problem you mentioned.
I also think that your addition of _GetAccountNameFromTokenW is holding the
committing of this patch back, especially because you don't seem to use
Thanks for your hints, Paul.
I added some tests for the Ansi variant of the function
and fixed the problem you mentioned.
>I also think that your addition of _GetAccountNameFromTokenW is holding the
>committing of this patch back, especially because you don't seem to use
that
>function.
I also a
On Wed, Apr 8, 2009 at 10:07 AM, Luke Benstead wrote:
> This is probably a really dumb question... but why does wine support
> UNIX paths? What is the circumstance where a Windows application will
> be trying to access a native file or directory? The only example I can
> think of is that an app ha
2009/4/8 Peter Rosin :
> Hi!
>
> [I just subscribed, I hope I got the forged in-reply-to header right]
>
> Ben Klein wrote:
>> > This is what I meant about magic translation. It *shouldn't* work, but
>> > I'm aware that it does. DOS/Windows uses backslash as the delimiter
>> > when reporting and st
2009/4/8 Warren Dumortier :
> 2009/4/8 Ben Klein :
>> 2009/4/8 Kai Blin :
>>> Hi,
>>>
He was very helpful in saying "iPod" without saying what generation it is.
>>>
>>> He said ipod touch, and none of those work in amarok.
>>
>> Ah, missed that :P
>>
>>
>>
>
> I dont want to whine, but can thi
2009/4/8 Ben Klein :
> 2009/4/8 Kai Blin :
>> Hi,
>>
>>> He was very helpful in saying "iPod" without saying what generation it is.
>>
>> He said ipod touch, and none of those work in amarok.
>
> Ah, missed that :P
>
>
>
I dont want to whine, but can this please be fixed? As Linux user it
is very
Guy Albertelli writes:
> BOOL found = FALSE;
>
> +buffer = VirtualAlloc( NULL, buflen, MEM_COMMIT|MEM_RESERVE,
> PAGE_READWRITE );
HeapAlloc is preferable.
> +/* test the result of opening a volume id (no trailing \) */
> +/* this should work. It provides access t
Hi!
[I just subscribed, I hope I got the forged in-reply-to header right]
Ben Klein wrote:
> > This is what I meant about magic translation. It *shouldn't* work, but
> > I'm aware that it does. DOS/Windows uses backslash as the delimiter
> > when reporting and storing paths. Is the behaviour of m
wrote:
+#define compare_fourcc(fcc1, fcc2) (((fcc1)^(fcc2))&~0x20202020L)
You ignore case even for mixed cased fourcc codes, but test only
2 cases: all lower/upper case codes, please test that cases too.
--
Dmitry.
> "Alexander" == Alexander Morozov writes:
>> trying to use the supplied or the mingw (cross) compiled libusb0.sys
>> from sourceforge with the USB enabled tree from
>> http://git.etersoft.ru/people/lav/packages/wine.git
>>
>> loading libusb0.sys fails:
Alexander> Dr
Rein Klazes writes:
> On Wed, 08 Apr 2009 11:39:08 +0200, you wrote:
>
>>Rein Klazes writes:
>>
>>> @@ -203,9 +203,9 @@ void WINAPI _fpMath( CONTEXT *context )
>>> context->Eax &= ~0x; /* set AX to 0 */
>>> break;
>>>
>>> -case 11: /* just returns the installed flag
> trying to use the supplied or the mingw (cross) compiled libusb0.sys from
> sourceforge with the USB enabled tree from
> http://git.etersoft.ru/people/lav/packages/wine.git
>
> loading libusb0.sys fails:
Drivers built with WinDDK is not page-aligned and
(nt->OptionalHeader.SectionAlignment <=
On Wed, 08 Apr 2009 11:39:08 +0200, you wrote:
>Rein Klazes writes:
>
>> @@ -203,9 +203,9 @@ void WINAPI _fpMath( CONTEXT *context )
>> context->Eax &= ~0x; /* set AX to 0 */
>> break;
>>
>> -case 11: /* just returns the installed flag in DX:AX */
>> +case 11: /*
Rein Klazes writes:
> @@ -203,9 +203,9 @@ void WINAPI _fpMath( CONTEXT *context )
> context->Eax &= ~0x; /* set AX to 0 */
> break;
>
> -case 11: /* just returns the installed flag in DX:AX */
> +case 11: /* returns in ax whether a 8087 coprocessor is present, say
Kai Blin wrote:
This version is based on the Vista PSDK and
places the definition in in6addr.h.
Is there any reason you're putting this into an extra header? The PSDK I have
around keeps this in ws2ipdef.h
My Vista PSDK breaks into the extra header. It does the same for the
IPV4 addr
Am Mittwoch, den 08.04.2009, 09:11 +0100 schrieb Chris Howe:
> I don't know the fate of the switchar API, it's been long gone for many years
> now."
>
> At what level this translation takes place - whether it's something in the
> command interpreter or further down into the API - I don't know.
Th
2009/4/8 Ben Klein
>
> This is what I meant about magic translation. It *shouldn't* work, but
> I'm aware that it does. DOS/Windows uses backslash as the delimiter
> when reporting and storing paths. Is the behaviour of magic
> translation from foreslash to backslash documented (by Microsoft)
> an
Hi John,
First of all this are basically two changes in one patch. Keep the vendor
one separated from the device string. Second the opengl renderer string
shouldn't be directly returned. In short d3d apps can query the pci id and
opengl doesn't expose it (we aren't allowed to use /proc for card de
43 matches
Mail list logo
