Stefan Dösinger a écrit :
> Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
>
>> As of ddraw, wouldn't it be possible to write it on top of d3d9, as it
>> is already done with wined3d.
>>
> That will screw non-opengl ddraw rendering, which the VNC/remote X/old
> card/bad driv
> But I've looked through listview tests and it seems to be quite simple
> (much simplier than WinAPI and C appeared to me at the very start :)
> ), so I hope to figure it out.
If you get stuck, send what you have and ask for help. We're trying
to encourage you to keep working on it, so your patc
> The key is to see what happens and if it is what you expected. Can this
> also be emulated in any version of Windows to verify this is what
> happens there?
I hope that clicking listview header and then bumping message to the
application happens in any Windows version. I hope.
Anyway, I do und
> It's up to you how to execute the requested functionality.
> If that's absolutely necessary it's not too hard to send
> WM_LBUTTONDOWN/WM_LBUTTONUP to the control.
...for experienced C programmer. And I am not one. But I'll try.
Dmitry Timoshkov wrote:
> "Igor Tarasov" wrote:
>
>
>> Now I don't get it. Looked through listview tests and there are not
>> even one mouse-related test. And my patch could be tested by just
>> sending HDN_ITEMCLICKW to listview control. And capturing the response
>> notifications.
>>
>
>
"Igor Tarasov" wrote:
> Now I don't get it. Looked through listview tests and there are not
> even one mouse-related test. And my patch could be tested by just
> sending HDN_ITEMCLICKW to listview control. And capturing the response
> notifications.
Then just do it that way.
> But the code is:
2009/2/19 Juan Lang
> Hi Ricardo,
>
> +DialogTitleW = MultiByteToUnicode(DialogTitle, CP_UTF8);
> You should be using CP_ACP here, not CP_UTF8. Same applies to
> remaining character conversions. In fact, you could use strdupAtoW
> instead.
> --Juan
>
> that is something i should have asked.
2009/2/19 Vincent Povirk :
>> 2009/2/18 IneedAname :
>>> Why not make Wine honor the noexe flag on the mount?
>>
>> This might not be a bad idea, if it's possible. Make Wine refuse to
>> run apps on noexec filesystems.
>
> This already doesn't work, even though Wine doesn't account for it.
> Wine c
Hi Ricardo,
+DialogTitleW = MultiByteToUnicode(DialogTitle, CP_UTF8);
You should be using CP_ACP here, not CP_UTF8. Same applies to
remaining character conversions. In fact, you could use strdupAtoW
instead.
--Juan
Hi Ricardo,
> dlls/setupapi/setupapi_private.h | 11 +++
> include/setupapi.h | 14 +-
I'd suggest you have the changes to setupapi.h as one patch on their
own. The changes to setupapi_private.h can be combined with the
changes to the .rc file (patch 2 in your
this was commited already today. :)
http://source.winehq.org/git/wine.git/?a=shortlog
2009/2/18 Juan M. Navarro
> Resending as plain text.
>
> Thanks,
> Juan
>
> On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro
> wrote:
> > Hello all!
> >
> > This is my first patch ever, and first open source
Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
> As of ddraw, wouldn't it be possible to write it on top of d3d9, as it
> is already done with wined3d.
That will screw non-opengl ddraw rendering, which the VNC/remote X/old
card/bad driver users will not really like. WineD3D currentl
Henri Verbeet a écrit :
> 2009/2/18 Jérôme Gardou :
>
>> Out of curiosity, would moving to this sort of architecture
>> http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That
>> may give manufacturer the possibility to develop wine-direct3d drivers
>> and support what wine does
Alexander Morozov wrote:
>> If that USB Key is not of a supportable kind, then I apologize for
>> asking.
>>
>
> I think you should try.
>
Thanks. I tried this way:
git clone git://source.winehq.org/git/wine.git ~/wine-git
git-am 0001...
git-am 0002...
./tools/wineinstall
When launchi
>> I just cant think of any regression test for that patch. It should
>> test if the notification is really being forwarded?
> Yes, that's what I mean. You're right, that might be hard, since you
> have to simulate a mouse click.
Now I don't get it. Looked through listview tests and there are not
Alexander Morozov wrote:
> I know nothing about these devices and I did not test them. But I think for
> working with them a driver is also necessary (not only dll).
To clarify, does your patch provide the general services on which all
(many) USB .sys drivers are built? or is it very specific to
Not sure. I can crossbuild it here on my mac with mingw without any
issue. I will admit my knowledge of why is pretty limited.
-aric
Nikolay Sivov wrote:
> Aric Stewart wrote:
>> could you check to see if uuid is being build properly?
>>
>> -aric
> Aric, is there any reason that we don't usuall
Aric Stewart wrote:
> could you check to see if uuid is being build properly?
>
> -aric
Aric, is there any reason that we don't usually link to uuid in tests?
For example guids stored in uuid are redefined inline in urlmon/tests/url.c:
DEFINE_GUID(CLSID_IdentityUnmarshal,0x001b,0x,0x,0
could you check to see if uuid is being build properly?
-aric
Nikolay Sivov wrote:
> Building today crosstests I've got:
>
> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include
> -g -O2 -o inputprocessor.cross.o inputprocessor.c
> i586-mingw32msvc-gcc -c -I. -I. -I../../../
Building today crosstests I've got:
i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include
-g -O2 -o inputprocessor.cross.o inputprocessor.c
i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include
-g -O2 -o testlist.cross.o testlist.c
i586-mingw32msvc-gcc input
Hi Igor,
> I just cant think of any regression test for that patch. It should
> test if the notification is really being forwarded?
Yes, that's what I mean. You're right, that might be hard, since you
have to simulate a mouse click.
> And does that mean that tests for the second patch are also
Hi Juan,
Thanks for quick reply.
> A regression test would go a long way toward proving your fix is correct.
There are two problems:
1. I am not that good in C and I have never written any regression tests in C.
2. I just cant think of any regression test for that patch. It should
test if the n
Igor Tarasov a écrit :
> Hello!
>
> I've written 2 patches, and I need advice on both of them.
>
> First one is here:
> http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html
>
> It's a single-line patch that adds forwarding notification that was
> omitted in wine code. This fix loo
Hi Igor,
> It's a single-line patch that adds forwarding notification that was
> omitted in wine code. This fix looks pretty simple, but it included
> lots of reading/testing/debugging, and here is what I came with. And
> as I told there it fixes one wine bugzilla bug.
A regression test would go
Hello!
I've written 2 patches, and I need advice on both of them.
First one is here:
http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html
It's a single-line patch that adds forwarding notification that was
omitted in wine code. This fix looks pretty simple, but it included
lots
> Now I kindly ask: is there a simple way to integrate the official branch
> with just the USB patches?
You can use patches for wine-1.1.15 and git am.
> If that USB Key is not of a supportable kind, then I apologize for asking.
I think you should try.
2009/2/17 Vincent Povirk :
> My opinion on this particular issue doesn't matter, but we don't
> strictly prevent Windows apps from seeing the underlying Linux
> environment. Any app can make linux system calls, access the filename
> conversion functions, invoke linux programs, and access the unix
On Wed, Feb 18, 2009 at 5:33 PM, Vincent Povirk
wrote:
>> 2009/2/18 IneedAname :
>>> Why not make Wine honor the noexe flag on the mount?
>>
>> This might not be a bad idea, if it's possible. Make Wine refuse to
>> run apps on noexec filesystems.
>
> This already doesn't work, even though Wine doe
2009/2/17 Andrew Talbot :
> Changelog:
>ntdll: Replace malloc() with RtlAllocateHeap().
>
> diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c
> index 145540f..0cade3f 100644
> --- a/dlls/ntdll/server.c
> +++ b/dlls/ntdll/server.c
> @@ -743,13 +743,13 @@ static void setup_config_dir(void)
>
> Wine can't mount sections of an exe file with executable permissions
> if it's on a noexec filesystem.
Err, sorry, meant to say "map", not "mount".
> 2009/2/18 IneedAname :
>> Why not make Wine honor the noexe flag on the mount?
>
> This might not be a bad idea, if it's possible. Make Wine refuse to
> run apps on noexec filesystems.
This already doesn't work, even though Wine doesn't account for it.
Wine can't mount sections of an exe file wi
On Wed, Feb 18, 2009 at 5:20 AM, Francois Gouget wrote:
> My remark was not so much about including windows.h rather than
> winfoo.h, but about including it in winetest.h when the parent C file
> has already included the winxxx.h files it needs. That is, in Wine it
> seems we have a policy to put
On Wednesday 18 February 2009, Ben Klein wrote:
> 2009/2/18 Martin Hinner :
> > Hi,
> >
> > I will start one more hot discussion. Sorry if it was discussed
> > earlier, I am not regular reader of this mailing-list. I tried to
> > search google, found several discussions, but no real result:
>
> It
Hans Leidekker writes:
> Some tests in James' original patch failed here, which I have fixed.
I still see failures:
../../../tools/runtest -q -P wine -M fusion.dll -T ../../.. -p
fusion_test.exe.so asmenum.c && touch asmenum.ok
asmenum.c:430: Test failed: Expected "wine, Version=1.0.1.2, Cultu
Wonderful, I was looking for a function JUST like that.
Reworked patch coming up shortly.
-aric
Hans Leidekker wrote:
>>> +LPCWSTR ptr,ptr2;
>>> +SYSTEMTIME tm;
>>> +int i;
>>> +
>>> +memset(&tm,0,sizeof(tm));
>>> +
>>> +ptr = expiry;
>>> +for (i = 0; i < 7; i++)
>>> +
> > +LPCWSTR ptr,ptr2;
> > +SYSTEMTIME tm;
> > +int i;
> > +
> > +memset(&tm,0,sizeof(tm));
> > +
> > +ptr = expiry;
> > +for (i = 0; i < 7; i++)
> > +{
> > +if (strncmpiW(day[i],ptr,3)==0)
> > +{
> > +tm.wDayOfWeek = i;
> > +brea
2009/2/18 Jérôme Gardou :
> Out of curiosity, would moving to this sort of architecture
> http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That
> may give manufacturer the possibility to develop wine-direct3d drivers
> and support what wine does not support. This would require a m
Stefan Dösinger a écrit :
> Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
>
>> So it wouldn't be possible to hook Wine's Direct3D implementation into
>> Gallium3D on Linux and use the hardware directly instead of translating it
>> to OpenGL and then sending it to the hardware?
>>
Aric Stewart writes:
> +LPCWSTR ptr,ptr2;
> +SYSTEMTIME tm;
> +int i;
> +
> +memset(&tm,0,sizeof(tm));
> +
> +ptr = expiry;
> +for (i = 0; i < 7; i++)
> +{
> +if (strncmpiW(day[i],ptr,3)==0)
> +{
> +tm.wDayOfWeek = i;
> +break;
>
Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
> So it wouldn't be possible to hook Wine's Direct3D implementation into
> Gallium3D on Linux and use the hardware directly instead of translating it
> to OpenGL and then sending it to the hardware?
Possible yes. I don't know if its gain
2009/2/18 Marcus Meissner :
> On Wed, Feb 18, 2009 at 09:33:01PM +1100, Ben Klein wrote:
>> 2009/2/18 IneedAname :
>> > Why not make Wine honor the noexe flag on the mount?
>>
>> This might not be a bad idea, if it's possible. Make Wine refuse to
>> run apps on noexec filesystems.
>
> Likely will b
On Wednesday 18 February 2009 12:33:01 Ben Klein wrote:
> 2009/2/18 IneedAname :
> > Why not make Wine honor the noexe flag on the mount?
>
> This might not be a bad idea, if it's possible. Make Wine refuse to
> run apps on noexec filesystems.
It is usual to mount FAT filesystems noexec (since the
On Wed, Feb 18, 2009 at 09:33:01PM +1100, Ben Klein wrote:
> 2009/2/18 IneedAname :
> > Why not make Wine honor the noexe flag on the mount?
>
> This might not be a bad idea, if it's possible. Make Wine refuse to
> run apps on noexec filesystems.
Likely will break installing all DVD/CD Software ;
2009/2/18 IneedAname :
> Why not make Wine honor the noexe flag on the mount?
This might not be a bad idea, if it's possible. Make Wine refuse to
run apps on noexec filesystems.
On Tue, 17 Feb 2009, Steven Edwards wrote:
> On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget wrote:
> > ---
> >
> > I moved them after the windows.h include though in practice the needed
> > winnt.h has already been included by the time we include winetest.h. So
> > maybe windows.h should be nu
On Wed, Feb 18, 2009 at 2:11 AM, Roderick Colenbrander <
thunderbir...@gmx.net> wrote:
> > On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson
> > wrote:
> >
> > > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > > > I had an interesting thought the other day, and that is to having
> som
On Wed, Feb 18, 2009 at 3:16 AM, Dmitry Timoshkov
wrote:
> Is there a specific problem you are trying to point out indirectly,
> or that's just a speculation?
I was just thinking perhaps we need a better way of making sure the
headers match up with the PSDK. I know we can do a MSVC configuration
Hi, first of all, thanks for your great effort in adding USB to Wine!
I have an app. needing a Marx Cryptobox USB, here drivers and info:
http://www.marx.com/rc1/en/support_downloads.php
I would like to help by testing it. I've tried to download the etherhack
branch of wine sources and compile
On Tue, 17 Feb 2009 17:11:20 +0100
Martin Hinner wrote:
> The problem is that some (almost all?) distributions simply execute
> .exe file when you click on it. I was amazed when testing JTAGTest on
> Linux! This is in my opinion quite big issue as ordinary users do not
> have problem clicking o
http://lkcl.net/namedpipes/namedpipes-emulation.txt
this specification is intended to be implemented as a library, similar
to a systems library that provides for example TCP/IP in userspace.
thus it could easily be utilised by samba, samba tng, samba 4, apache
runtime or in fact any POSIX-complian
"Steven Edwards" wrote:
> I've agreed with the logic and the reasons behind it for the Wine
> libraries. My point was that we already avoid it more than enough in
> libraries, and maybe its a good thing after far as winelib goes to
> insure the apps in the programs directory always do include win
> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson
> wrote:
>
> > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > > I had an interesting thought the other day, and that is to having some
> > > built in support for forwarding windows dlls to linux .so's.
> >
> > IIRC, this kind of thi
On Tue, Feb 17, 2009 at 10:40 PM, Dmitry Timoshkov
wrote:
> The reason why we avoid windows.h inclusion in Wine is compilation
> time by avoiding inclusion of all-in-one headers windows.h does. It's
> always a good programming practice to include only those .h files that
> are really needed, inclu
53 matches
Mail list logo
