On 25 March 2010 23:04, Roderick Colenbrander wrote:
> This patch adds a first part of the new blit_shader infrastructure. In
> a few days I plan to submit more parts of it which will extend the
> blit_shader and rewrite parts in the end.
>
This is patch is pretty hacky.
> +static const struct bl
On 25 March 2010 23:58, Stefan Dösinger wrote:
> Am Donnerstag 25 März 2010 23:02:33 schrieb Roderick Colenbrander:
>>
> +DWORD color_convert_argb_to_fmt(DWORD color, WINED3DFORMAT destfmt)
> This only works with formats that are encoded in integers with 32 bit or less.
> Do we care about this lim
On Thu, Mar 25, 2010 at 11:58 PM, Stefan Dösinger
wrote:
> Am Donnerstag 25 März 2010 23:02:33 schrieb Roderick Colenbrander:
>>
> +DWORD color_convert_argb_to_fmt(DWORD color, WINED3DFORMAT destfmt)
> This only works with formats that are encoded in integers with 32 bit or less.
> Do we care abou
Am Donnerstag 25 März 2010 23:02:33 schrieb Roderick Colenbrander:
>
+DWORD color_convert_argb_to_fmt(DWORD color, WINED3DFORMAT destfmt)
This only works with formats that are encoded in integers with 32 bit or less.
Do we care about this limitation?
Damjan Jovanovic writes:
> I don't know enough about writing kernel drivers yet to decide this
> (and several other things), so I think it's best I hack at it until I
> have it working, then I'll start submitting patches again.
>
> In the meanwhile, is the use of libusb-1.0 in Wine ok? Or should
On Wed, Mar 24, 2010 at 10:04 PM, Alexandre Julliard
wrote:
> Damjan Jovanovic writes:
>
>> On Wed, Mar 24, 2010 at 9:51 PM, Alexandre Julliard
>> wrote:
>>> Damjan Jovanovic writes:
>>>
usbhub.sys isn't accessed via exports and I don't think anything
depends on usbhub.sys specifical
Whoops, forgot to cc wine-devel.
> I don't have any password-protected certificates to test with, so I can't add
> such a test (it was not required for our implementation).
You can if you create one (on Windows.)
> So what you want is to import two new functions (sk_X509_new_null() and
> sk_X5
On 2010-03-25, at 12:14 PM, Juan Lang wrote:
> Hi Philippe,
>
>>> You accept the PKCS12 file even if the password is incorrect. This is
>>> clearly wrong.
>>
>> It is not accepted. If the verification fails, ERR is spewed out and the
>> next step (parse, below) will fail as well.
>
> Is this
Piotr Caban writes:
> ---
> dlls/msvcr80/msvcr80.spec |4 +-
> dlls/msvcr90/msvcr90.spec |4 +-
> dlls/msvcrt/msvcrt.h | 44
> dlls/msvcrt/msvcrt.spec|4 +-
> dlls/msvcrt/string.c | 80
> dlls/msvcrt/tests/string.c |
Hi Philippe,
>> You accept the PKCS12 file even if the password is incorrect. This is
>> clearly wrong.
>
> It is not accepted. If the verification fails, ERR is spewed out and the next
> step (parse, below) will fail as well.
Is this how Windows fails? That is, with a parse error? Please add
Hi Juan,
> Hi Philippe, in addition to the question I had on patch 1/2, I'd like
> to know, what is the purpose of this test?
>
> +static void test_createCertificateStore(void)
> +{
> +HCERTSTORE certStore = NULL;
> +
> +certStore = CertOpenStore(CERT_STORE_PROV_SYSTEM, 0, (HCRYPTPROV)NUL
Hi Juan,
Thanks for reviewing my patches. Here are my comments:
> this attempt looks pretty incomplete. First off:
>
> +ret = pPKCS12_verify_mac(pkcs12, password, len);
> +if (ret == 0)
> +ERR_(crypt)("failed to verify pkcs12 {%p} with password
> \"%s\" using func {%p}\n", pkcs1
Hi Anh and Welcome to Wine!
It seems your patch got mangled in transit, e.g. git apply says: fatal: corrupt
patch at line 33
If you have a look at it at http://source.winehq.org/patches/ you see that the
lines are wrapped.
--
Best Regards, André Hentschel
joerg-cyril.hoe...@t-systems.com schrieb:
> Hi,
>
> you guys running Wine64 on 64bit UNIX, please test
> the patch attached to bug #22146
> http://bugs.winehq.org/show_bug.cgi?id=22146
>
> The patch is available from
> http://bugs.winehq.org/attachment.cgi?id=27027
>
> Test code that you can use
> You have DOS line endings in your patch. A simple dos2unix fixes this.
>
> Thank you
Attached the patch with unix line endings
Seb
From 44bf3ca4f53864d70d6ae89ec705db83e51e9796 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?S=C3=A9bastien=20Ramage?=
Date: Thu, 25 Mar 2010 09:00:29 +0100
Subject: [PATC
Hi,
you guys running Wine64 on 64bit UNIX, please test
the patch attached to bug #22146
http://bugs.winehq.org/show_bug.cgi?id=22146
The patch is available from
http://bugs.winehq.org/attachment.cgi?id=27027
Test code that you can use for reporting is at:
http://bugs.winehq.org/attachment.cgi?id
Hi Mike,
> From: Mike Kaplinskiy
>
> I recently discovered
> that winetestbot doesn't run on win98 by default - will keep that in
> mind in the future. Is there any reason for that?
Not really, apart from a certain amount of hate on my side towards Win9x.
I've added W98SE (which you might have gu
Am Donnerstag 25 März 2010 10:06:21 schrieb Roderick Colenbrander:
> Note I don't know much about the current FBO extension situation but
> since FBOs are finally quite common, can't we expect some features to
> be around? If this functionality is missing, perhaps we should just
> not work and let
On 03/25/2010 09:56 AM, Sébastien Ramage wrote:
You have DOS line endings in your patch. A simple dos2unix fixes this.
Thank you
Attached the patch with unix line endings
Seb
Patch should go to wine-patches. Please mark as [Try x] and tell what
the difference to the previous version is.
On 25 March 2010 10:02, Stefan Dösinger wrote:
> Good point. Maybe we should only look at those flags when we're using FBOs? I
> think the other format checking functions handle it that way, I wondered why.
Probably.
> GL_EXT_framebuffer_object doesn't require GL_ARB_depth_texure, so technically
On Thu, Mar 25, 2010 at 10:02 AM, Stefan Dösinger
wrote:
> Am Donnerstag 25 März 2010 09:10:19 schrieb Henri Verbeet:
>> So what happens if the GL implementation doesn't support
>> ARB_depth_texture, for example?
> Good point. Maybe we should only look at those flags when we're using FBOs? I
> thi
On Thu, Mar 25, 2010 at 9:26 AM, Henri Verbeet wrote:
> On 25 March 2010 09:17, Roderick Colenbrander wrote:
>> My suggestion was to extend 'init_format_texture_info' and set
>> 'wined3d_format_desc->supported' when the extension is around.
>>
> That doesn't help, the problem is with fairly old c
Am Donnerstag 25 März 2010 09:10:19 schrieb Henri Verbeet:
> So what happens if the GL implementation doesn't support
> ARB_depth_texture, for example?
Good point. Maybe we should only look at those flags when we're using FBOs? I
think the other format checking functions handle it that way, I wond
Piotr Caban writes:
> ---
> dlls/msvcr80/msvcr80.spec|4 ++--
> dlls/msvcr90/msvcr90.c | 21 +
> dlls/msvcr90/msvcr90.spec|4 ++--
> dlls/msvcr90/tests/msvcr90.c | 26 +-
> 4 files changed, 50 insertions(+), 5 deletions(-)
St
Eric Pouech wrote:
> my point was not just to say that most of the information put in current
> TRACE/WARN/FIXME/ERR statements contain more decimal than hexadecimal
> formats
> so obviously, not everybody expects hexa all over the place
Of course each TRACE statements serve the pupose of each
On 03/25/2010 09:15 AM, Sébastien Ramage wrote:
---
dlls/user32/scroll.c | 5 +
dlls/user32/tests/scroll.c | 16 +++-
2 files changed, 16 insertions(+), 5 deletions(-)
Hi
You can see at http://source.winehq.org/patches/ that your patch '59740'
had an apply failure. And fair eno
On 25 March 2010 09:17, Roderick Colenbrander wrote:
> My suggestion was to extend 'init_format_texture_info' and set
> 'wined3d_format_desc->supported' when the extension is around.
>
That doesn't help, the problem is with fairly old cards that don't
support depth textures. They obviously won't b
On Thu, Mar 25, 2010 at 9:10 AM, Henri Verbeet wrote:
> On 24 March 2010 23:53, Stefan Dösinger wrote:
>>
>> These flags will be unset if the format is not supported by GL and is
>> consistent with the other
>> depth stencil check functions.
> So what happens if the GL implementation doesn't sup
On 24 March 2010 23:53, Stefan Dösinger wrote:
>
> These flags will be unset if the format is not supported by GL and is
> consistent with the other
> depth stencil check functions.
So what happens if the GL implementation doesn't support
ARB_depth_texture, for example?
29 matches
Mail list logo
