2008/7/7 Tobias Jakobi <[EMAIL PROTECTED]>:
>
The test doesn't get run this way. If it did it would fail of course,
so you should either submit the test after your second patch, or put
the ok that tests the pool type inside a todo_wine block and remove it
again in your second patch.
2008/7/8 Austin Lund <[EMAIL PROTECTED]>:
> 2008/7/7 Austin Lund <[EMAIL PROTECTED]>:
>> 2008/7/3 Austin Lund <[EMAIL PROTECTED]>:
>>> I get a crash all the time in winetest since 1.0. Seems there is not
>>> a problem with any of the tests themselves (i.e. running make test).
>>>
>>> The last few
2008/7/7 Austin Lund <[EMAIL PROTECTED]>:
> 2008/7/3 Austin Lund <[EMAIL PROTECTED]>:
>> I get a crash all the time in winetest since 1.0. Seems there is not
>> a problem with any of the tests themselves (i.e. running make test).
>>
>> The last few lines of output from winetest is:
>>
>> fixme:xra
I apologise for the simple mistakes. But I only made those spelling errors
after the fact and I was trying to get it working, I saw from google one
forums post where the U was capitalised so I thought I'd try it, I just had
forgot to put it back.
I have fixed all the error and now it doesn't compl
On Mon, Jul 7, 2008 at 6:24 PM, Austin Lund <[EMAIL PROTECTED]> wrote:
> Does anyone else get the following compile error at commit
> 2734fb44e0f4065179044b9eb93f87a7630f292d:
>
> make[2]: Entering directory `/home/lund/src/wine/wine-git/dlls/rpcrt4'
> make[2]: *** No rule to make target
> `../../i
Does anyone else get the following compile error at commit
2734fb44e0f4065179044b9eb93f87a7630f292d:
make[2]: Entering directory `/home/lund/src/wine/wine-git/dlls/rpcrt4'
make[2]: *** No rule to make target
`../../include/wine/rpcss_shared.h', needed by `ndr_contexthandle.o'.
Stop.
make[2]: Leavi
> What's with the weird spacing?
Thanks for the catch. I spaced on the spacing. Revised patch with
corrected spacing is attached.
Peace,
-Roy
From 11425fd623f6375937b3d97c8d682506cc08d39a Mon Sep 17 00:00:00 2001
From: Roy Shea <[EMAIL PROTECTED]>
Date: Mon, 7 Jul 2008 16:13:33 -0700
Subject: [
On Mon, Jul 7, 2008 at 5:05 PM, Roy Shea <[EMAIL PROTECTED]> wrote:
> This revision uses a more concise check of hash equality than prior
> patch archived at:
>
> http://www.winehq.org/pipermail/wine-patches/2008-June/056139.html
>
> Call to memcmp in test_calchash assumes length of hash and expect
> I have #include , maybe I do not have my makefile correct. I've
> attached the makefile, the cudart.c and all the nvidia header's need (14 of
> them) in one tar.bz2 file. Can someone check my makefile and all? I read
> through the nvidia license and it is ok to redistribute the headers.
Nothing
I have #include , maybe I do not have my makefile correct. I've
attached the makefile, the cudart.c and all the nvidia header's need (14 of
them) in one tar.bz2 file. Can someone check my makefile and all? I read
through the nvidia license and it is ok to redistribute the headers.
On Mon, Jul 7, 2
Hi students,
As you might know it's time for midterm evaluations. Unfortunately for
some students I haven't seen the progress they made, and I highly
encourage all students to send their patches early and often, even if
it's not yet finished.
Also, I would like to hear from all students now a ref
> cudart.c:261: error: expected ')' before 'bufferObj'
> cudart.c:265: error: expected declaration specifiers or '...' before
> 'GLuint'
>
> cudaError_t WINAPI wine_cudaGLRegisterBufferObject( GLuint bufferObj ){
Check your includes again. GLuint is defined in here.
--Juan
I just have a makefile. No makefile.in. Perhaps I used winemaker wrong? I
simply did "winemaker --dll cuda".
On Mon, Jul 7, 2008 at 5:00 PM, John Klehm <[EMAIL PROTECTED]>
wrote:
>
>
> Check the IMPORT variable in Makefile.in and see if everything you
> need is listed.
>
> --John
>
On Mon, Jul 7, 2008 at 3:52 PM, Seth Shelnutt <[EMAIL PROTECTED]> wrote:
> Ah ok, now I understand.
>
> I am having a problem with the opengl section of it. It doesn't like GLuint
> . I've added the gl.h file to my list of headers as I thought maybe I needed
> the header to define it. But it still
Ah ok, now I understand.
I am having a problem with the opengl section of it. It doesn't like GLuint
. I've added the gl.h file to my list of headers as I thought maybe I needed
the header to define it. But it still doesn't like it. Here are the errors,
and one of the lines of code. I've googled i
On Mon, Jul 7, 2008 at 12:08 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 6, 2008 at 10:29 AM, James Hawkins <[EMAIL PROTECTED]> wrote:
>> No, this is hiding a bug. The test code conforms with the API. The
>> problem is that ConvertINetMultiByteToUnicode uses the value of an
>> out-only
Zac Brown wrote:
> Add stub implementation for WinHttpCloseHandle
>
>
ignore, forgot patch.
On Mon, Jul 7, 2008 at 1:56 PM, Massimo Del Fedele <[EMAIL PROTECTED]> wrote:
>
> Because AppSearchReg does search in reg, where paths are un-slashed.
> I could have fixed more low-level, of course, but then you'd have big
> probability to break unrelated stuffs.
Listen, I don't want to come off a
James Hawkins ha scritto:
> On Mon, Jul 7, 2008 at 10:04 AM, Massimo Del Fedele <[EMAIL PROTECTED]> wrote:
>> I'll repost that one... I'd like some feedback if it looks wrong.
>>
>
> This isn't going to be committed without a test.
>
>> To maintain consistence between global MSI path properties (
On Sat, Jul 5, 2008 at 9:24 PM, Vitaliy Margolen
<[EMAIL PROTECTED]> wrote:
> +LinuxInputEffectImpl_Stop(iface);
> +LinuxInputEffectImpl_Unload(iface);
Vitaliy,
Native behavior is for Unload to stop the effect also (see msdn or
test it yourself), so the call to Stop here is unne
"Maarten Lankhorst" <[EMAIL PROTECTED]> writes:
> It won't violate the locking rules, since this is the way it is
> designed. If you look at OutputPin_SendSample, you will see it takes
> the critical section to obtain whether the pin is connected to
> something, and if it is, it will send the data
Hi Alexandre,
2008/7/7 Alexandre Julliard <[EMAIL PROTECTED]>:
> "Maarten Lankhorst" <[EMAIL PROTECTED]> writes:
>
>> diff --git a/dlls/quartz/acmwrapper.c b/dlls/quartz/acmwrapper.c
>> index d877930..22bfb87 100644
>> --- a/dlls/quartz/acmwrapper.c
>> +++ b/dlls/quartz/acmwrapper.c
>> @@ -186,7 +
On Mon, Jul 7, 2008 at 12:46 PM, Markus <[EMAIL PROTECTED]> wrote:
> If d3d9 could not be properly initialized, the value 'n/a' is set. This
> behavior has been verified against the native dxdiagn.dll. The
> corresponding testcase will follow once I have time.
>
You forgot the patch.
--
James Ha
Hi Seth,
> Now are you saying the code should be,
> retval, WINAPI wine_cudaGetDeviceCount( int* count ){
> return cudaGetDeviceCount( count );
> }
>
> or should it be
>
> retval, WINAPI wine_cudaGetDeviceCount( int* count )
>
> or
>
> retval = WINAPI wine_cudaGetDeviceCount( int* count ){
>
> I am also not quite sure about some constructs, like
>
> "wine_cudaBindTexture( size_t* offset, const struct texture < T, dim,
> readMode >& texRef, const void* devPtr, const struct cudaChannelFormatDesc&
> desc, size_t size = UINT_MAX )" As far as I know this contains C++ or
> Microsoft syntax,
The compiler chokes on the C++ coding that you pointed out. I'm not sure
exactly how to handle it, maybe just convert it all to c syntax? For now
I'll just commit out those lines and just work on trying to get something to
compile.
Now are you saying the code should be,
retval, WINAPI wine_cudaGet
On Mon, Jul 7, 2008 at 10:04 AM, Massimo Del Fedele <[EMAIL PROTECTED]> wrote:
> I'll repost that one... I'd like some feedback if it looks wrong.
>
This isn't going to be committed without a test.
> To maintain consistence between global MSI path properties (as
> CommonAppDataFolder) which are r
Actually you want something like
retval WINAPI wine_cudaSomething(int a, int etc)
so instead of the void use the return value the function is supposed to
return
WINAPI tells the compiler about the calling convention(ie, first parameter
on the stack, in ecx, or elsewhere, who takes care about
Am Montag, den 07.07.2008, 17:17 +0200 schrieb Michael Karcher:
Sorry for commentless resending. I am too stupid to notice that July had
begun and considered the mail lost as it didn't appear in June's
archive. Still I wonder why the patch (series) didn't make it in. Any
feedback?
Regards,
Mich
2008/7/7 Alexandre Julliard <[EMAIL PROTECTED]>:
> "Rob Shearman" <[EMAIL PROTECTED]> writes:
>
>> tools/widl/proxy.c |3 +++
>> tools/widl/server.c |3 +++
>> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> This one doesn't work:
>
> ../../../tools/runtest -q -P wine -M rpcrt4.dll -
"Rob Shearman" <[EMAIL PROTECTED]> writes:
> Skip calling the Pointer marshalling/unmarshalling/buffer
> sizing/freeing function in this case.
This one doesn't work either:
../../../tools/runtest -q -P wine -M qmgr.dll -T ../../.. -p qmgr_test.exe.so
file.c && touch file.ok
fixme:qmgr:BITS_IBac
> I think should split my patch into many little commits.
> Should also add some tests or make some changes?
Yes, add conformance tests for the new ntoskrnl functions
and usbd.sys, and break the patch up a lot...
Looks like people have been hoping for something like
this for a couple years now,
"Rob Shearman" <[EMAIL PROTECTED]> writes:
> tools/widl/proxy.c |3 +++
> tools/widl/server.c |3 +++
> 2 files changed, 6 insertions(+), 0 deletions(-)
This one doesn't work:
../../../tools/runtest -q -P wine -M rpcrt4.dll -T ../../.. -p
rpcrt4_test.exe.so server.c && touch server.ok
> Title says it all.
Not *quite* all. Inquiring minds always want to know what
app it will help and/or bugzilla entry it will fix.
Codeweavers folks often don't mention that for
business reasons, but if you're at liberty to mention it,
it's always nice to include that in patch descriptions.
> Split it at least into the sub driver/dll parts.
>
> You can leave out the "configure" part, it will be regenerated form
> configure. ac anyway. Same for dlls/Makefile.in
>
> The ntoskrnl changes might break the already working copy protection
> drivers, so either try them yourself after the patc
> We are very interested in Wine having a more native OS X interface.
> However, our analysis is that the task is difficult and will require a
> long time to stabilize and get right. I am excited by and
> interested in
> Emmanuel's work, but I am told not to be too excited, that it's not
> a mag
"Maarten Lankhorst" <[EMAIL PROTECTED]> writes:
> diff --git a/dlls/quartz/acmwrapper.c b/dlls/quartz/acmwrapper.c
> index d877930..22bfb87 100644
> --- a/dlls/quartz/acmwrapper.c
> +++ b/dlls/quartz/acmwrapper.c
> @@ -186,7 +186,9 @@ static HRESULT
> ACMWrapper_ProcessSampleData(TransformFilterI
On Mon, Jul 07, 2008 at 12:10:17PM +0400, Alexander Morozov wrote:
> Hello All,
>
> I created a patch which adds support of USB hardware tokens with native
> Windows drivers (.sys):
> ftp://ftp.etersoft.ru/pub/download/amorozov/0001-Support-of-native-Windows-drivers-for-USB-tokens.txt
> Now SafeN
Hello All,
I created a patch which adds support of USB hardware tokens with native
Windows drivers (.sys):
ftp://ftp.etersoft.ru/pub/download/amorozov/0001-Support-of-native-Windows-drivers-for-USB-tokens.txt
Now SafeNet UltraPro (driver sntnlusb.sys, vid/pid 04b9:0300) and Eutron
SmartKey 3 (dr
Am Sonntag, den 06.07.2008, 13:45 -0700 schrieb Jon Griffiths:
> Title says it all.
> +case 0x3ba:
> +/* CRT status register (read only)
> + * This register is read repeatedly to signal whether a hercules/
> + * monochrome adapter is present, which is si
40 matches
Mail list logo
