February 2009 - Wine-Devel - list.winehq.org

Re: Need help on couple of patches

by Igor Tarasov

> 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.

Feb. 19, 2009

Re: Need help on couple of patches

by James McKenzie

Dmitry Timoshkov wrote: > "Igor Tarasov" <tarasov.igor(a)gmail.com> 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. > > Igor: 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? James McKenzie

Feb. 19, 2009

Re: Need help on couple of patches

by Dmitry Timoshkov

"Igor Tarasov" <tarasov.igor(a)gmail.com> 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: > > static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, > const NMHEADERW *lpnmh) > { > ... > switch (lpnmh->hdr.code) > { > ... > case HDN_ITEMCLICKW: > case HDN_ITEMCLICKA: > { > ... > notify_forward_header(infoPtr, lpnmh); > } > break; > > Is that really should be tested for being executed, by simulating > mouse click? Or I just don't understand something? 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. -- Dmitry.

Feb. 19, 2009

Re: [8/9] setupapi: implement SetupPromptForDiskA by wrapping around W version

by Ricardo Filipe

2009/2/19 Juan Lang <juan.lang(a)gmail.com> > 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... i assumed using UTF8 would be "safer" for the resources, since they can be in utf8 required languages... i'll take this and your other suggestions into account and resend the patches tomorrow. i just tried to split the patches as much as possible maintaining "buildability" between patches. thank you.

Feb. 19, 2009

Re: Wine & viruses

by Ben Klein

2009/2/19 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: >> 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: >>> 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 map sections of an exe file with executable permissions > if it's on a noexec filesystem. It crashes trying to branch to the > entry point. Worked for me. vfat filesystem mounted with noexec flag, kernel 2.6.28. I tested it before commenting.

Feb. 19, 2009

Re: [8/9] setupapi: implement SetupPromptForDiskA by wrapping around W version

by 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

Feb. 19, 2009

Re: [1/9] setupapi: add header information for SetupPromptForDisk

by Juan Lang

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 series), along with your patch to create the new dialog.c file (patch 3 in your series), and your patch to create a do-nothing dialog (patch 4 in your series.) In this way, each patch has a single functional change. If you do it as I suggest, patch 1 will change the public header file. Patch 2 will introduce a new dialog. The remaning patches seem split appropriately, so you'd end up with a 7 patch series. --Juan

Feb. 19, 2009

Re: Wine64 - msvcrt dll test fix

by Ricardo Filipe

this was commited already today. :) http://source.winehq.org/git/wine.git/?a=shortlog 2009/2/18 Juan M. Navarro <juan.m.navarro(a)gmail.com> > Resending as plain text. > > Thanks, > Juan > > On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro > <juan.m.navarro(a)gmail.com> wrote: > > Hello all! > > > > This is my first patch ever, and first open source contribution ever. > > > > The strlen function returns a size_t that represents an unsigned int in > > 32-bit environments, and an unsigned long in 64-bit environments. The > strlen > > function call has been changed to an lstrlen function call, which always > > returns an integer. > > > > I am a grad student at UCLA that has just started working on porting Wine > to > > 64-bit environments. > > > > I attest to not having seen any Microsoft source, or dissasembling > > Microsoft's DLL's. > > > > Thanks, > > > > Juan > > > >

Feb. 19, 2009

Re: Win to Lin Library Wrapper

by Stefan Dösinger

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 currently has two surface implementations, one for GL based rendering and one for SW emulation(2D only) /me remembers the uproar when the ddraw rewrite broke the ability to compile ddraw without GL headers. (gentoo useflags OMG!!!)

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by Jérôme Gardou

Henri Verbeet a écrit : > 2009/2/18 Jérôme Gardou <jerome.gardou(a)gmail.com>: > >> 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 major >> architecture change in the current wine's d3d implementation though. >> >> > Possible sure, but I don't think it would be worth the effort. IIRC > ddraw support might be a problem as well. > > Well, the fact is that wined3d is a bit d3d8/9 centric, and integrating DXGI and d3d10/11 might as well be tricky. I've seen that some work had begun, and I'm quite curious on which design decision you will make. As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d.

Feb. 18, 2009