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
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
2010/6/24 Paul Chitescu pa...@voip.null.ro:
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
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 the ddraw
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
On 24 June 2010 05:18, Misha Koshelev misha...@gmail.com 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
On 24 June 2010 05:18, Misha Koshelev misha...@gmail.com 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
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 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
Ken Sharp kennyb...@o2.co.uk 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.
Hello Ken,
Ken Sharp wrote:
From: Ken Sharp kennyb...@o2.co.uk
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
On Wed, 23 Jun 2010, Dmitry Timoshkov wrote:
Francois Gouget fgou...@free.fr 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
+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
On 24 June 2010 17:40, Stefan Dösinger stefandoesin...@gmx.at 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
On 24 June 2010 05:18, Misha Koshelev misha680 at gmail.com 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
On 24 June 2010 18:11, Misha Koshelev misha...@gmail.com 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
Henri Verbeet hverb...@gmail.com wrote:
On 24 June 2010 18:11, Misha Koshelev misha...@gmail.com 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
Gert van den Berg wine-de...@mohag.net 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
On Tue, Jun 22, 2010 at 9:42 AM, Dan Kegel d...@kegel.com 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
On Thu, Jun 24, 2010 at 11:39:49AM -0700, James Mckenzie wrote:
Gert van den Berg wine-de...@mohag.net 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
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 index
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
On Thu, 2010-06-24 at 11:33 -0700, James Mckenzie wrote:
Henri Verbeet hverb...@gmail.com wrote:
On 24 June 2010 18:11, Misha Koshelev misha...@gmail.com 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
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
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.
25 matches
Mail list logo
