Current state of USBD.SYS
Hi, I'm in the process of migrating custom patches made to WINE 1.1.7 to WINE 1.3.24. Among those is USBD.SYS, which we use to run a Windows driver for a specific USB device which has no equivalent Linux driver. I was wondering what to expect from 1.3.24 as far as USB device discovery and Windows driver support goes. For example, our older patched version ties into Linux HAL to find devices, but there doesn't *appear* to be the same functionality in this newer stock version. Does anyone know what the goal of usbd.sys is in WINE 1.3.24? Also what I'd like to find out is if there is maybe a cutting-edge usbd.sys module that hasn't made it into the development WINE branch. Anyway, thanks for your time and any help is greatly appreciated, as always. -Louis
Re: Best way to get Program Files/Common Files?
Thanks Bruno, ExpandEnvironmentStrings with %CommonProgramFiles% seems to be a better solution for my needs.
Re: Best way to get Program Files/Common Files?
> I need to get the user configured path to Program Files/Common Files > to save the dinput action mapping settings. > > What are the my options for doing this? > > One way I found is the SHGetSpecialFolderPath function, but it > requires me to link to shell32 and I suspect there's a better way. I believe this is the preferred way, at least from Microsoft's point of view. --Juan
Re: Best way to get Program Files/Common Files?
On Tue, Aug 9, 2011 at 18:17, Lucas Zawacki wrote: > I need to get the user configured path to Program Files/Common Files > to save the dinput action mapping settings. > > What are the my options for doing this? Maybe you can use environment variables: APPDATA CommonProgramFiles They are found on Windows >=2000. > One way I found is the SHGetSpecialFolderPath function, but it > requires me to link to shell32 and I suspect there's a better way. > > Thanks > > > Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...
Best way to get Program Files/Common Files?
I need to get the user configured path to Program Files/Common Files to save the dinput action mapping settings. What are the my options for doing this? One way I found is the SHGetSpecialFolderPath function, but it requires me to link to shell32 and I suspect there's a better way. Thanks
Re: GSoC: dinput8 Action Mapping - dialog testing
There's actually a problem with what I was intending to do. In windows the function doesnt truly create a dialog, it's more like a DirectX rendered application and just now I realized that the test will not be compatible. So I think I'll give up testing this, at least for now.
Re: [rfc] WINE_ONCE macro
I introduced exactly the same on my old DIB engine, to avoid tons of FIXMES :-) I find it quite useful. Max
Re: wldap32/tests: Skip tests if ldap_init failed (try 3)
2011/8/9 André Hentschel :
> Am 09.08.2011 19:44, schrieb Hans Leidekker:
>> On Tue, 2011-08-09 at 19:31 +0200, André Hentschel wrote:
>>
>>> diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c
>>> index 4cf8564..ed37d88 100644
>>> --- a/dlls/wldap32/tests/parse.c
>>> +++ b/dlls/wldap32/tests/parse.c
>>> @@ -128,7 +128,11 @@ START_TEST (parse)
>>> LDAP *ld;
>>>
>>> ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 );
>>> - ok( ld != NULL, "ldap_init failed\n" );
>>> + if (!ld)
>>> + {
>>> + skip("ldap_init failed, skipping tests\n");
>>> + return;
>>> + }
>>>
>>> test_ldap_parse_sort_control( ld );
>>> test_ldap_search_extW( ld );
>>
>> If it fails on Wine it's probably because LDAP development files
>> were not present at build time.
>>
>> I'm not sure if we want to hide this failure though, applications
>> may expect ldap_init to succeed.
>>
>
> Wine is supports Solaris and it fails there, so i thought it can't belong to
> the bad things.
That is a Solaris bug. Putting a skip() would potentially hide bugs on
other platforms where it works (Linux, FreeBSD, OSX).
--
-Austin
Re: wldap32/tests: Skip tests if ldap_init failed (try 3)
Am 09.08.2011 19:44, schrieb Hans Leidekker:
> On Tue, 2011-08-09 at 19:31 +0200, André Hentschel wrote:
>
>> diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c
>> index 4cf8564..ed37d88 100644
>> --- a/dlls/wldap32/tests/parse.c
>> +++ b/dlls/wldap32/tests/parse.c
>> @@ -128,7 +128,11 @@ START_TEST (parse)
>> LDAP *ld;
>>
>> ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 );
>> -ok( ld != NULL, "ldap_init failed\n" );
>> +if (!ld)
>> +{
>> +skip("ldap_init failed, skipping tests\n");
>> +return;
>> +}
>>
>> test_ldap_parse_sort_control( ld );
>> test_ldap_search_extW( ld );
>
> If it fails on Wine it's probably because LDAP development files
> were not present at build time.
>
> I'm not sure if we want to hide this failure though, applications
> may expect ldap_init to succeed.
>
Wine is supports Solaris and it fails there, so i thought it can't belong to
the bad things.
--
Best Regards, André Hentschel
Re: wldap32/tests: Skip tests if ldap_init failed (try 3)
On Tue, 2011-08-09 at 19:31 +0200, André Hentschel wrote:
> diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c
> index 4cf8564..ed37d88 100644
> --- a/dlls/wldap32/tests/parse.c
> +++ b/dlls/wldap32/tests/parse.c
> @@ -128,7 +128,11 @@ START_TEST (parse)
> LDAP *ld;
>
> ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 );
> -ok( ld != NULL, "ldap_init failed\n" );
> +if (!ld)
> +{
> +skip("ldap_init failed, skipping tests\n");
> +return;
> +}
>
> test_ldap_parse_sort_control( ld );
> test_ldap_search_extW( ld );
If it fails on Wine it's probably because LDAP development files
were not present at build time.
I'm not sure if we want to hide this failure though, applications
may expect ldap_init to succeed.
Re: wldap32/tests: Skip tests if ldap_init failed
Am 09.08.2011 19:26, schrieb Hans Leidekker:
> On Tue, 2011-08-09 at 19:17 +0200, André Hentschel wrote:
>
>> diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c
>> index 4cf8564..faad474 100644
>> --- a/dlls/wldap32/tests/parse.c
>> +++ b/dlls/wldap32/tests/parse.c
>> @@ -128,7 +128,11 @@ START_TEST (parse)
>> LDAP *ld;
>>
>> ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 );
>> -ok( ld != NULL, "ldap_init failed\n" );
>> +if (!ld)
>> +{
>> +win_skip("ldap_init failed, skipping tests\n");
>> +return;
>> +}
>>
>> test_ldap_parse_sort_control( ld );
>> test_ldap_search_extW( ld );
>
> Do you see it fail on Windows?
>
>
oops
--
Best Regards, André Hentschel
Re: wldap32/tests: Skip tests if ldap_init failed
On Tue, 2011-08-09 at 19:17 +0200, André Hentschel wrote:
> diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c
> index 4cf8564..faad474 100644
> --- a/dlls/wldap32/tests/parse.c
> +++ b/dlls/wldap32/tests/parse.c
> @@ -128,7 +128,11 @@ START_TEST (parse)
> LDAP *ld;
>
> ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 );
> -ok( ld != NULL, "ldap_init failed\n" );
> +if (!ld)
> +{
> +win_skip("ldap_init failed, skipping tests\n");
> +return;
> +}
>
> test_ldap_parse_sort_control( ld );
> test_ldap_search_extW( ld );
Do you see it fail on Windows?
Re: d3dx9: CloneMesh test and improvements
2011/8/8 Michael Mc Donnell :
> Hi
>
> I've been working on a test and improvements for CloneMesh as part of
> GSoC 2011. I would be grateful if anyone could comment on my work.
> There are five test cases in the attached patch:
>
> 0. Basic mesh cloning. Declaration has position and normal, and the
> new declaration is the same as the original.
> 1. Same as test 0, but with 16-bit indices.
> 2. Shows that the vertex buffer can be widened so that it has room
> for a new vertex component. The declaration has position and normal,
> and the new declaration has texture coordinates after position and
> normal.
> 3. Same as test 2, but the new declaration has the texture
> coordinates in between position and normal.
> 4. Shows that a vertex component can be converted into another type
> if the new declaration specifies another type. The declaration has
> position and normal. The normal is a FLOAT2 and in the new declaration
> it is instead FLOAT16_2.
>
> Test 0 and 1 tests what is already known to work in the current
> implementation. Test 2, 3 and 4 do not work in the current
> implementation because the original and new declarations are not the
> same.
>
> I've also improved the current CloneMesh implementation so that it
> also passes test 2, 3, and 4. The patch is not complete because it
> does not support converting all the possible types. I expect to
> implement conversion for the remaining types during this week.
>
> Again any comments or ideas are welcome.
>
> Thanks,
> Michael Mc Donnell
>
Hello Michael,
I have some comments:
+const UINT d3dx_decltype_size[D3DDECLTYPE_UNUSED] =
+{
I don't really like sizing the vector like that. Just remove the
D3DDECLTYPE_UNUSED between the square brackets, I'd say. Otherwise,
you could use the D3DMAXDECLTYPE define.
+ /* D3DDECLTYPE_FLOAT1*/ 1 * 4,
...
You may want to replace the 4 with a sizeof(float) for better clarity.
Same for the others.
+if (orig_declaration.Method == declaration[i].Method
+&& orig_declaration.Usage == declaration[i].Usage
+&& orig_declaration.UsageIndex == declaration[i].UsageIndex)
Does the Method field really need to be compared? Maybe add a test if
that is the case.
You may also e.g. test if in a POSITION, NORMAL, TEXCOORD(0) ->
POSITION, NORMAL, TEXCOORD(1) CloneMesh (or even the other way around)
the texture coordinates are actually lost or not.
+for (i = 0; orig_declaration[i].Stream != 0xff; i++) {
+if (memcmp(&orig_declaration[i], &declaration[i],
sizeof(*declaration))) {
+same_declaration = FALSE;
+break;
+}
+}
+
+if (vertex_size != orig_vertex_size)
+same_declaration = FALSE;
Not really a big thing, but you could do the vertex size check first
and then compare the fields only if same_declaration is still TRUE.
The tests look good to me, except some nits like the ok() in
check_vertex_components in the D3DDECLTYPE_FLOAT1 case, splitting long
lines and such.
Re: Bug #27975 and one small change
On 08/09/2011 01:49 PM, Frédéric Delanoy wrote: http://wiki.winehq.org/SubmittingPatches already links to http://wiki.winehq.org/GitWine (see http://wiki.winehq.org/SubmittingPatches#head-c088a6649bf6b17d21c57a87be967bc309b2f57c) I was just referring to the .git/config file which may need some tweaking because I remember I had some trouble in the very beginning (like everyone I suppose). But if the link already exists, that's perfect. Sorry for the noise.
Re: Bug #27975 and one small change
2011/8/9 GOUJON Alexandre : > On 08/09/2011 08:51 AM, Frédéric Delanoy wrote: >> >> 2011/8/8 Adam Stachowicz: >>> >>> From f91549a682b52b77853b53a475011c7869f861b2 Mon Sep 17 00:00:00 2001 >>> From: Saibamen >>> Date: Mon, 8 Aug 2011 15:43:48 +0200 >>> Subject: Resize control to allow wider string of polish translator and >>> bug >>> 27975 >> >> Please see http://wiki.winehq.org/SubmittingPatches for how to submit >> in the correct patch format. >> >> Frédéric > > http://wiki.winehq.org/SubmittingPatches gives good and general practices > before sending a patch but I think > http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 > is more relevant on *how* to generate a clean patch and sends it in a > correct way. > > Maybe we should add a link from the first page to the second one... http://wiki.winehq.org/SubmittingPatches already links to http://wiki.winehq.org/GitWine (see http://wiki.winehq.org/SubmittingPatches#head-c088a6649bf6b17d21c57a87be967bc309b2f57c) Frédéric
Re: Bug #27975 and one small change
On 08/09/2011 08:51 AM, Frédéric Delanoy wrote: 2011/8/8 Adam Stachowicz: From f91549a682b52b77853b53a475011c7869f861b2 Mon Sep 17 00:00:00 2001 From: Saibamen Date: Mon, 8 Aug 2011 15:43:48 +0200 Subject: Resize control to allow wider string of polish translator and bug 27975 Please see http://wiki.winehq.org/SubmittingPatches for how to submit in the correct patch format. Frédéric http://wiki.winehq.org/SubmittingPatches gives good and general practices before sending a patch but I think http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 is more relevant on *how* to generate a clean patch and sends it in a correct way. Maybe we should add a link from the first page to the second one...
