Happy New Year to everyone! May office 2010 run in 2011 :)
On Sat, Jan 1, 2011 at 1:43 PM, Dan Kegel wrote:
> May all your tests be green, and all your patches pass peer review :-)
>
>
>
--
Wine is not a conclusion but a process...
May all your tests be green, and all your patches pass peer review :-)
On 12/31/10 6:19 PM, Dan Kegel wrote:
'set' is not a good way to check the environment, since it also shows
shell variables that are not yet exported.
The portable way to check the environment is 'env'.
True. Let me check this.
correction:
env | grep LIBRARY
James McKenzie
On 12/31/2010 08:41 AM, Nowres wrote:
> Hello,
>
> here's a basic support for Arabic language in user32.dll
> work in progress in other programs to complete support for this language.
>
> Nowres Rafid.
>
>
>
>
Changes should be sent as a patch in unified diff format, preferably
generated wit
On 12/31/10 1:50 PM, Charles Davis wrote:
On 12/31/10 1:11 PM, Ken Thomases wrote:
I should add that this patch seem correct to me. It couldn't hurt to get
Charles Davis's input, of course.
I agree, for now. He should at least put a comment in to the effect of
"if we got this far, there's alr
'set' is not a good way to check the environment, since it also shows
shell variables that are not yet exported.
The portable way to check the environment is 'env'.
On 12/31/10 11:56 AM, Hin-Tak Leung wrote:
Susan Cragin wrote:
Does this 'path' exist in LD_LIBRARY_PATH or equivilent?
Otherwise ld might not be able to 'find' it when starting the
program.
James McKenzie
James...
You've just exhausted my technical knowledge. How do I do / find that?
Sus
Greg Geldorp writes:
> A big thank you to all the people who contributed tests and fixed
> existing tests. I think a lot of progress has been made in the month
> since WineConf and the tests are in much better shape now.
Yes, the results page is looking incredibly good lately. It seems that
2011
On 12/31/10 1:11 PM, Ken Thomases wrote:
> I should add that this patch seem correct to me. It couldn't hurt to get
> Charles Davis's input, of course.
I agree, for now. He should at least put a comment in to the effect of
"if we got this far, there's already media in the drive."
> MSDN documents
On Dec 31, 2010, at 1:38 PM, Ken Thomases wrote:
> Why does that matter? The question is, under what circumstances does it end
> up in CDROM_Verify()? What is the right behavior of CDROM_Verify() and how
> would that be implemented on Mac OS X?
I should add that this patch seem correct to me.
Susan Cragin wrote:
Does this 'path' exist in LD_LIBRARY_PATH or equivilent?
Otherwise ld might not be able to 'find' it when starting the program.
James McKenzie
James...
You've just exhausted my technical knowledge. How do I do / find that?
Susan:
For the BASH shell:
Type in set and look
On Dec 30, 2010, at 9:36 AM, James McKenzie wrote:
> This has been critically examined by several people and if the solution were
> this simple it would have been put in place a long time ago. Charles Davis
> has spend over a year looking at how to implement CDROM functionality for
> MacOSX.
Today we hit another milestone: the first 0-failure run of the 64-bit tests.
All tests passed on both the WXPX64 and W2K3R2SEX64 machines.
Sadly I missed my personal goal of having all tests pass on at least one VM for
every Windows version by the end of the year, we still don't have a Win7
mac
> >
> > int card, err, capcontrols=0
> >
> > otherwise things like:
> >
> > mixdev[mixnum].chans += capcontrols;
> >
> > mixdev[mixnum].lines =
> > HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
> > sizeof(line) * mixdev[mixnum].chans);
> >
> >
> > goes crazy like in
> > http://bugs.winehq.org
On Fri, Dec 31, 2010 at 3:48 PM, Matteo Bruni wrote:
> Maybe it's just time to remove the "replace malloc with HeapAlloc"
> task from the wiki? Or, at least, add a note to explain that we expect
> the current Wine code to be "compliant".
Done.
2010/12/30 Dan Kegel :
> Yegor wrote:
>> it's my first contribution to wine...
>
> Welcome!
>
>> so I wanted to start with some simple task.
>
> Changing memory allocation might not be simple.
>
> Your patch touches two different DLLs.
> You should probably split this patch up, one patch per dll.
>
On 12/31/2010 13:38, Alexandre Julliard wrote:
Nikolay Sivov writes:
Fix a null pointer crash
This is an internal function, the caller should take care of this.
True, it was wrong. Thanks.
André Hentschel writes:
> needed for ratGPU
> ---
> dlls/msvcr80/msvcr80.spec |2 +-
> dlls/msvcr90/msvcr90.spec |2 +-
Please fix all the msvcrt dlls, not just these two.
--
Alexandre Julliard
julli...@winehq.org
Nikolay Sivov writes:
> Fix a null pointer crash
This is an internal function, the caller should take care of this.
--
Alexandre Julliard
julli...@winehq.org
19 matches
Mail list logo
