Unless someone wants to donate an AM2/DDR2 motherboard to me, someone
is going to have to take over the packaging of Debian Stable, Testing
and Unstable packages.
So I've been working on bug 13891, but got sidetracked by what I thought
was a race condition as dlls/shell32/tests/shlexec.c was hanging.
Spent several hours tracing it to line 464 in dlls/ntdll/directory.c
if (stat( entry->mnt_dir, &st ) == -1) continue;
(read from /etc/mtab)
Turned o
On Thu, 2010-06-24 at 11:33 -0700, James Mckenzie wrote:
> Henri Verbeet >
> >On 24 June 2010 18:11, Misha Koshelev wrote:
> >> Ok thank you. Since we are in code freeze and I'd like to help wine,
> >> perhaps then I
> >>will just go down the list of 1.2 milestone bugs for now and see if I can
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=2910
Your paranoid android.
Am Donnerstag 24 Juni 2010 17:56:07 schrieb Henri Verbeet:
> If we really cared about those cases we could explicitly handle them,
> (e.g. by growing in smaller increments once we're over half the limit)
> but I don't think we do. There's also the (more likely) consideration
> that creating an inde
On Thu, Jun 24, 2010 at 11:39:49AM -0700, James Mckenzie wrote:
> Gert van den Berg wrote:
> >Like the D website says:
> >Who D is Not For
> >* Realistically, nobody is going to convert million line C or C++
> >programs into D. Since D does not compile unmodified C/C++ source
> >code, *D is no
On Tue, Jun 22, 2010 at 9:42 AM, Dan Kegel wrote:
> I'd love to have yagmark be more internationalized.
> I did try to use button codes rather than english
> strings in wisotool, but sometimes it wasn't possible, and
> sometimes I didn't try hard enough. Not sure if I
> tried at all in yagmark ye
Gert van den Berg wrote:
>Like the D website says:
>Who D is Not For
>* Realistically, nobody is going to convert million line C or C++
>programs into D. Since D does not compile unmodified C/C++ source
>code, *D is not for legacy apps*. (However, D supports legacy C API's
>very well. D can co
Henri Verbeet
>On 24 June 2010 18:11, Misha Koshelev wrote:
>> Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps
>> then I
>>will just go down the list of 1.2 milestone bugs for now and see if I can
>>help.
>>
>Yeah, milestone bugs should generally be ok, as well as a
On 24 June 2010 18:11, Misha Koshelev wrote:
>> http://source.winehq.org/patches/, you'll see 62909 is marked as
>> "Deferred", so resending in a slightly different form isn't going to
>> help much.
> Ah I see thank you. I take it this means deferred until post-code freeze
> (please correct me if
>
> On 24 June 2010 05:18, Misha Koshelev wrote:
> > Dan suggested tests ok during code freeze so blame Dan for my patches ;)
> Certainly will. wine-devel is an open mailing list, and posting is
> easy. You'll probably want to check with something like "git shortlog
> -s -n" if the advice you're
On 24 June 2010 17:40, Stefan Dösinger wrote:
> Thinking about it, is there a reason for growing the buffer in power of two
> sizes, and not simply set it to the size required for the draw call? E.g. if
> the app passes index data with a size somewhere between 2^31 and 2^32-1(which
> still stil
> +while(size < IndexCount * sizeof(WORD))
> +{
> +size <<= 1;
> +}
Thinking about it, is there a reason for growing the buffer in power of two
sizes, and not simply set it to the size required for the draw call? E.g. if
the app passes index data with a size s
On Wed, 23 Jun 2010, Dmitry Timoshkov wrote:
> Francois Gouget wrote:
>
> > James never meant that Wine would not use rc files at all. What he meant
> > is that rc files would lose their status as the autoritative source for
> > the resource strings and would be mostly generated from po files.
Hello Ken,
Ken Sharp wrote:
> From: Ken Sharp
> Date: Tue, 15 Jun 2010 09:42:05 +0100
> Subject: kernel32: Update Gaelic resource
the patch changes the file encoding to UTF-8 without changing the
"#pragma code_page" too. Though Alexandre already rejected codepage
changes to the NLS files during t
Ken Sharp wrote:
> diff --git a/dlls/kernel32/nls/gae.nls b/dlls/kernel32/nls/gae.nls
> index 6e19ff4..a005be3 100644
> --- a/dlls/kernel32/nls/gae.nls
> +++ b/dlls/kernel32/nls/gae.nls
Looks like you are using UTF-8 while the file is in code page 1252.
--
Dmitry.
On Thu, Jun 24, 2010 at 10:55, Francois Gouget wrote:
> OOP:
>
> A lot of the Windows API is exported through DLL entry points and these
> are not object oriented. Where the Windows API is object oriented is:
OOP in C is not impossible wither... It is harder than it could be,
but it is possible...
Am 24.06.2010 um 11:30 schrieb Mikko Rasa:
> On 24.06.2010 12:07, Stefan Dösinger wrote:
>>
>> Am 23.06.2010 um 21:57 schrieb Mikko Rasa:
>>> +if(!size)
>>> +{
>>> +ERR("UINT overflow while trying to grow indexbuffer to
>>> hold %u indices\n", IndexCount)
On 24 June 2010 05:18, Misha Koshelev wrote:
> +#if !defined(__cplusplus) || defined(CINTERFACE)
> +/*** IUnknown methods ***/
> +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b)
> +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p)
> +#define ID3DXMesh_
On 24 June 2010 05:18, Misha Koshelev wrote:
> Dan suggested tests ok during code freeze so blame Dan for my patches ;)
Certainly will. wine-devel is an open mailing list, and posting is
easy. You'll probably want to check with something like "git shortlog
-s -n" if the advice you're getting is ac
On 06/24/10 10:49, Paul Chitescu wrote:
Hi!
What would be the best way of testing MSVCRT.DLL considering that many
functions may or may be not present in the native version?
There are already such tests in msvcrt. Take a look on e.g.
dlls/msvcrt/tests/misc.c. It's working well on older systems.
Am 23.06.2010 um 21:57 schrieb Mikko Rasa:
> +if(!size)
> +{
> +ERR("UINT overflow while trying to grow indexbuffer to hold
> %u indices\n", IndexCount);
> +return D3DERR_TOOMANYPRIMITIVES;
> +}
> +}
You have to release t
2010/6/24 Paul Chitescu :
> Hi!
>
> What would be the best way of testing MSVCRT.DLL considering that many
> functions may or may be not present in the native version?
>
>> > /*
>> > + * getenv_s - not exported in native
On Wed, 23 Jun 2010, Christopher Selph wrote:
> Hi everyone, new here. I have been fooling around with the idea of porting
> WIne to the D programming language. What do you think would be the chances
> of sucess? D has the speed of C, but is a garbage collected language and
> OOP.
Garbage collect
Hi!
What would be the best way of testing MSVCRT.DLL considering that many
functions may or may be not present in the native version?
> > /*
> > + * getenv_s - not exported in native msvcrt
> > + */
> > +int CDECL get
25 matches
Mail list logo
