Eric Pouech wrote:
> +case CPU_x86_64:
> +context->debug.x86_64_regs.dr0 = data[0];
> +context->debug.x86_64_regs.dr1 = data[1];
> +context->debug.x86_64_regs.dr2 = data[2];
> +context->debug.x86_64_regs.dr3 = data[3];
> +context->debug.x86_64_regs.dr6
>
> In general, the idea looks right, that's how it probably should be
> implemented. This is an implementation detail through. The bigger and
> more important problem is URI parsing and canonicalization. That's where
> most of work needs to be done. In this case tests will be also very
> importan
On Tue, Apr 6, 2010 at 2:03 PM, Alexandre Julliard wrote:
> Mike Kaplinskiy writes:
>
>> Would allowing adding the fd to the poll loop after it has been
>> removed be more sane? Otherwise we have to resort to ugly things like
>> sock_try_event (which only half work).
>
> I don't think that makes
2010/4/7 Rico Schüller :
> +/* Check desc for NULL, this crashes on W7/DX10 */
> +if (!desc)
> +{
> +WARN("This should crash on W7/DX10!\n");
> +return E_FAIL;
> +}
It's perfectly fine to require a parameter to be non-NULL, and just
crash if it isn't. You'll get a ni
There is a long list of technologies in Mac OS X that could be used to improve
Wine on OS X. One of them is ColorSync. ColorSync is a color management
software that is HEAVILY integrated into the Mac OS. For instance, you can
calibrate your monitor and when OS X starts up, it will read the color
Am 07.04.2010 11:29, schrieb Henri Verbeet:
2010/4/6 Rico Schüller:
+struct d3d10_effect_shader_signature {
That isn't going to apply. Did you edit the patch? (And please keep
the formatting consistent with the existing code.)
Sorry, Thunderbird screwed up the patches. I'll s
Hi Alexandre,
> Ok so I could not run any test until compiling on cygwin works.
> But the idea was to be able to remotly compile wine with some of our patches
> applied.
>
> I was told "you can't do that, it will break minGW".
> The WINEBUILD VM exists but we can't use it (or tell me how to do tha
I didn't know this tool.
It looks quite interesting.
Thanks again for your advices
Patchwatcher is suppose to sort of do this. It only works for linux, not
other systems, but it will not only check your patch against compiling but
also against the test suit and mark and regressions.
Alexandre Goujon wrote:
> > For any productive Wine development you need not only working compiling
> > environment, but a working Wine binary, to run at least 'make test'.
>
>
> Ok so I could not run any test until compiling on cygwin works.
Even if compiling under Cygwin works, the tests sti
Dmitry Timoshkov wrote
> For any productive Wine development you need not only working compiling
> environment, but a working Wine binary, to run at least 'make test'.
Ok so I could not run any test until compiling on cygwin works.
But the idea was to be able to remotly compile wine with some o
Hi,
I forgot to mention that this patch was rebased against 1.1.42,
supersedes the former "Fix A/W mapping for 64bit Wine" patch and
is not dependent on prior 64bit patches.
Currently, I can't think of a fully general solution to the A/W
mapping problem. In theory, an unknown driver with new unkn
Hi Alexander,
Good to see you back in GSoc. I can't comment on IE / control panel as
I don't know much about it but I will comment to another small part.
> As for my own project ideas, I think it would have been interesting to
> implement IPX over TCP in winsock, since most of the games that use
Hello,
I'm a student interested in participating in Google's Summer of Code.
This isn't my first mail to the wine-devel list; I was a GSoC
partiicpant in 2007, where I worked on WIne's WordPad clone. I have also
done some work on the AppDB as well as minor bug fixes and lately a
(little) work
Eric Pouech writes:
> @@ -549,12 +549,21 @@ void get_thread_context( struct thread *thread,
> context_t *context, unsigned int
> goto done;
> }
> }
> +#ifdef __i386__
> context->debug.i386_regs.dr0 = data[0];
> context->debug.i386_regs.dr1 = data[1];
> c
Alexandre Goujon wrote:
> Currently, I can't compile on Linux and cygwin is very slow.
> So it would make my life easier if I could rely on wineTestBot...
For any productive Wine development you need not only working compiling
environment, but a working Wine binary, to run at least 'make test'.
Hi,
I have a suggestion about wineTestBot.
It's maybe the wrong place but I'm quite sure interested people read
wine-devel.
I think it would be great if we could
not only run tests (as it already does)
but also check if a patch does not break wine (on minGW, on cygwin or on MAC
for instance).
Th
On 6 April 2010 23:14, Johan Gill wrote:
> +»··»···if (!EqualRect(&scrn, &orig_rect)) {
> +»··»···/* Check that the client rect was resized */
> +»··»···rc = GetClientRect(hwnd, &test);
> +»··»···ok(rc!=0, "GetClientRect returned %x\n", rc);
> +»··»·
On 7 April 2010 11:29, Henri Verbeet wrote:
> That isn't going to apply.
Also, 3/4 and 4/4 have similar issues.
2010/4/6 Rico Schüller :
> +struct d3d10_effect_shader_signature {
That isn't going to apply. Did you edit the patch? (And please keep
the formatting consistent with the existing code.)
20 matches
Mail list logo
