If i've understood what i read before, i think i've found a sort of xinput's
conformance test suite writen by windows coder
what do you think of that ?
http://www.codeproject.com/KB/directx/xbox360_cont_xinput.aspx
We've got the source code for a test and even binaries !!
I've to test its beha
2008/7/31 Rob Shearman <[EMAIL PROTECTED]>:
> 2008/7/30 Reece Dunn <[EMAIL PROTECTED]>:
>> When running the ole32:marshal tests on Vista, the call to
>> CoUnmarshalInterface fails. This results in pProxy being NULL which
>> then causes the crash on the QueryInterface call.
>>
>> This patch makes su
Please bottom post on this ML.
Aric Stewart wrote:
> Here is a revised patch which builds the scancode->DIK table on
> initialization making no xserver round trips required on lookup.
>
> How does this look?
>
> -aric
>
> Aric Stewart wrote:
>> Yes, I have verified those vkeys in windows.
> I'm sorry, I cannot reproduce this. Which settings are you using?
I see it now, it only occurs with medium post processing settings.
The patch obviously has a flaw when the drawable is bigger than the target,
in which case the coordinate system's origin is outside of the target's
area. I think I
> this patch break PP effects even more with Max Payne 2 (demo) and
> ORM=backbuffer.
> Bullettime PP works, but cutscene PP breaks. Interested in a screenshot?
I'm sorry, I cannot reproduce this. Which settings are you using?
cutscene post processing works flawlessly here with this patch, even i
> Rolf Kalbermatter wrote:> > Not sure about what you mean with injecting here
> but in normal application operation> when loading a DLL explicitedly from a
> specific directory (which is not the current> directory nor the application
> directory or one of the standard search paths),
> Windows
On Thu, Jul 31, 2008 at 1:45 PM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> "Lei Zhang" <[EMAIL PROTECTED]> writes:
>
>> While mucking around in programs/cmd/wcmdmain.c, I noticed
>> console = SHGetFileInfo();
>> always returned 0 for just "msiexec".
>
> cmd is supposed to build a full path he
On Thu, Jul 31, 2008 at 1:50 PM, Jacek Caban <[EMAIL PROTECTED]> wrote:
>> While running mshtml/tests/dom.c on a slow dual processor
>> under valgrind, I got the following hang:
>
> I know about this bug and it's not easy to fix (because it's hard to
> reproduce it). It's on my TODO list.
OK. It
Hi Damjan,
Damjan Jovanovic wrote:
> Changelog:
> * Added a rudimentary implementation of CLSID_InternetShorcut, with
> tests (#3546).
>
> Damjan Jovanovic
>
+
+static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out)
+{
+INT len;
+if (in == NULL)
+{
+*out = NULL;
+return
Hi Dan,
Dan Kegel wrote:
> While running mshtml/tests/dom.c on a slow dual processor
> under valgrind, I got the following hang:
> ...
> 7 0x04b22c1c GetMessageA+0x60(msg=0x7f21fdc8, hwnd=0x0, first=0x0,
> last=0x0) [dlls/user32/message.c:2976] in user32 (0x7f21fda8)
> 8 0x04946eb1 run_domtest
Hongbo Ni wrote:
>I think when processing the imports for C:\DirA\B.dll to load C.dll, it
should
>try C:\DirA\C.dll first, then form the standard load locations.
>
>I think it should call load_library( "C:\DirA\C.dll ",
LOAD_WITH_ALTERED_SEARCH_PATH)
>so C.dll can be loaded into C:\DirX\X.exe pro
"Lei Zhang" <[EMAIL PROTECTED]> writes:
> While mucking around in programs/cmd/wcmdmain.c, I noticed
> console = SHGetFileInfo();
> always returned 0 for just "msiexec".
cmd is supposed to build a full path here, but either way it won't work
because SHGetFileInfo doesn't work for builtins. This i
> 2008/7/31 Stefan Dösinger <[EMAIL PROTECTED]>:
> > +if(Adapters[0].opengl) {
> Shouldn't you be checking the adapter for which the caps are requested
> instead?
True. In practise it doesn't matter because its unlikely one adapter has GL
support and the other doesn't, but still using 0 here is
Does the attached patch fix the warnings?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dan Kegel
> Sent: Thursday, July 31, 2008 12:22 PM
> To: wine-devel
> Cc: Stefan Dösinger
> Subject: New valgrind warnings in wined3d/arb_program_shader.c
>
>
Alexandre Julliard wrote:
> It would be cleaner to pass the actual buffer size to the function, it's
> complex enough that it would be easy to inadvertently break the
> guarantee that the allocated space is large enough.
We already pass a length pointer to that
"convert_PCREDENTIALW_to_PCREDENTIA
On Thu, Jul 31, 2008 at 3:11 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> You should be using %11% instead of hardcoding system32, but it
> shouldn't make any difference either way. Why do you need to change
> this?
While mucking around in programs/cmd/wcmdmain.c, I noticed
console = SHGetF
Jeff Latimer wrote:
> Are you planning to move on to MultiByteToWideChar tests?
No, feel free to go ahead with them.
I mainly wanted to fix http://bugs.winehq.org/show_bug.cgi?id=8598 and a fix
for this bug required a working wide-character to multibyte conversion in
the CRT and Win32.
This is
Dan Kegel wrote:
> your change [...] seems to have triggered some valgrind warnings,
Thanks for providing the valgrind output!
Indeed, I was passing a wrong length to a WideCharToMultiByte call, which
led to the use of uninitialized stack memory.
Fixed here:
http://www.winehq.org/pipermail/wine
Here is a revised patch which builds the scancode->DIK table on
initialization making no xserver round trips required on lookup.
How does this look?
-aric
Aric Stewart wrote:
Yes, I have verified those vkeys in windows.
the VK_OEM_* keys are specificaly VK codes that vary from keyboard to
ke
Hi Stefan,
your recent round of changes (circa
http://www.winehq.org/pipermail/wine-cvs/2008-July/045946.html)
seems to have triggered a whole bunch of valgrind warnings, e.g.
http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-d3d9_visual-diff.txt
+ Use of uninitialised value of size 4
+a
Hi Colin,
your change
http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b811d1141acd6ec76fca6
seems to have triggered some valgrind warnings,
http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-diff.txt
e.g.
+ Use of uninitialised value of size 4
+a
Andre Wisplinghoff wrote:
> Wrapping was still wrong. Sorry for that. Just using attachments now.
>
> dlls/user32/tests/input.c | 37 +
> 1 files changed, 37 insertions(+), 0 deletions(-)
>
>
>
2008/7/31 Stefan Dösinger <[EMAIL PROTECTED]>:
> +if(Adapters[0].opengl) {
Shouldn't you be checking the adapter for which the caps are requested instead?
You'll need to modify stretch_rect_fbo() as well.
Hi,
I looked up the XInput documentation a while ago, and the DLL seemed rather
small and simple to me. My quick uneducated guess is that it should be pretty
streightforward to wrap it to the standard joystick API.
What I recommend you as a start is to boot Windows, get some Windows
development
chourmovs wrote:
> I'd like to participate to wine improvement instead of
> always requesting for new features
>
> ... xinput support lack for new games and its
> implementation is maybe not the hardest thing to do
Please start by writing conformance tests.
See
http://www.winehq.org/site/docs/win
Yes, I have verified those vkeys in windows.
the VK_OEM_* keys are specificaly VK codes that vary from keyboard to
keyboard. VK_OEM_3 is just one example.
-aric
Vitaliy Margolen wrote:
> Aric Stewart wrote:
>> vkey codes similarly do not produce a clean 1 to 1 correspondance.
>> the '@' key (0
Aric Stewart wrote:
> vkey codes similarly do not produce a clean 1 to 1 correspondance. the
> '@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' key on
> the us keyboard.
This is needs to be fixed in x11drv then. Not in dinput. Have you verified
what v_keys you getting from window
Am Donnerstag, den 31.07.2008, 08:53 +0200 schrieb Michael Karcher:
> SDL uses something like the DIK codes seem to be with their SDLK
> constants.
Argl! That sentence sense no make does. I meant to say: "SDL's SDLK_*
constants seem to be conceptually what Window's DIK_* are."
Regards,
Michael K
Yes this is a specific problem I am seeing. In a Japanese online Mahjong
game, there appears to be no way to remap the keys and the game is using
the top 2 rows of the keyboard to control the movement of the tiles in
the game.
the top row scan codes for a japanese keyboard are:
1234
"Colin Finck" <[EMAIL PROTECTED]> writes:
> @@ -947,7 +947,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const
> CREDENTIALW *CredentialW,
> if (CredentialW->TargetName)
> {
> CredentialA->TargetName = buffer;
> -string_len = WideCharToMultiByte(CP_ACP, 0, Crede
"Damjan Jovanovic" <[EMAIL PROTECTED]> writes:
> +static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out)
> +{
The usual pattern is to return the new pointer, not an HRESULT. The only
possible error is E_OUTOFMEMORY anyway.
> +static HRESULT WINAPI
> UniformResourceLocatorA_SetUrl(IUniformResourceLoc
Colin Finck wrote:
> Add a lot of new tests for the actual WideCharToMultiByte string
> conversion as well.
Are you planning to move on to MultiByteToWideChar tests? I was
planning on adding a few and don't want to get into your way.
Jeff
"Lei Zhang" <[EMAIL PROTECTED]> writes:
> @@ -143,9 +143,9 @@
> HKCR,lnkfile\CLSID,,2,"{00021401---C000-0046}"
> HKCR,lnkfile\shellex\IconHandler,,2,"{00021401---C000-0046}"
>
> HKCR,lnkfile\shellex\ContextMenuHandlers\{00021401---C000-0046},,0x1
H. Verbeet wrote:
> 2008/7/30 Reece Dunn <[EMAIL PROTECTED]>:
>> SetMaterial crashes when passed a NULL argument.
>>
> If you're going to do that, you might as well remove the entire test.
> I think this test has caused trouble before.
>
>
>
There is even a bug report for this:
http://bugs.wine
2008/7/30 Reece Dunn <[EMAIL PROTECTED]>:
> When running the ole32:marshal tests on Vista, the call to
> CoUnmarshalInterface fails. This results in pProxy being NULL which
> then causes the crash on the QueryInterface call.
>
> This patch makes sure that the pProxy-dependant tests are only called
2008/7/30 Reece Dunn <[EMAIL PROTECTED]>:
> SetMaterial crashes when passed a NULL argument.
>
If you're going to do that, you might as well remove the entire test.
I think this test has caused trouble before.
37 matches
Mail list logo
