April 2011 - Wine-Devel - list.winehq.org

Re: Summer of Code 2011 ideas

by Charles Davis

On 3/27/11 5:53 PM, Charles Davis wrote: > 1. Quartz Driver. I know you guys rejected this last year, but it looks > like AJ's been doing some work refactoring the driver interface (at > least, the GDI driver interface) lately. I also have some patches to > isolate the rest of Wine from winex11. Since the driver itself is so > huge, I'll probably end up only doing a piece of it (just enough to run > some simple programs like Notepad or Minesweeper). This still depends on > my (as yet, unfinished) Deobjectivizer tool so I don't have to code the > driver in Objective-C (or resort to Carbon, which Apple seems intent on > exorcising from Mac OS X). > 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, > D3D10 support is still in the embryonic stage (i.e. lots of stubs, > anything interesting doesn't work quite right). It looks like Henri > wants to wait until he finishes exorcising COM from WineD3D to finish > implementing D3D10 (probably because COM was too much of a burden for > what D3D10 needed from WineD3D, judging from which methods are stubs), > so if you want to wait, that's fine. If I do take this on, my goal will > probably be to get the game "Civilization V" working (at least, > partially) in D3D10 mode, because that's the only D3D10 game I happen to > own! (If it already works, and I don't know if it does because I haven't > gotten around to installing and testing it, then I'll try to make it > work better.) I haven't heard any real objections to these two (the third has been subsumed by someone with a much better proposal), so unless someone speaks up now, I will submit proposals tomorrow. BTW, if I do take up the D3D10 project, I'll consider using WoW's experimental D3D10 engine (as suggested by Jerome Leclanche) to test my D3D10 implementation. Chip

April 4, 2011

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista

by Austin Lund

On 1 April 2011 14:03, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Austin Lund <austin.lund(a)gmail.com> wrote: > >> --- a/dlls/user32/tests/msg.c >> +++ b/dlls/user32/tests/msg.c >> @@ -12681,6 +12681,7 @@ static const struct message WmSetParentSeq_2[] = { >> { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE }, >> { EVENT_OBJECT_HIDE, winevent_hook|wparam|lparam, 0, 0 }, >> { WM_WINDOWPOSCHANGED, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, >> + { HCBT_SETFOCUS, hook|optional }, >> { WM_NCACTIVATE, sent|wparam, 0 }, >> { WM_ACTIVATE, sent|wparam, 0 }, >> { WM_ACTIVATEAPP, sent|wparam, 0 }, > > This does look correct. It's pretty strange that other Windows versions > don't send HCBT_SETFOCUS notification before WM_KILLFOCUS (which is right > after WM_ACTIVATEAPP in the message sequence). > Is there any obvious reason why this passes on the testbot when I sent it myself, but the automated tests still fail? http://test.winehq.org/data/123e4ad41d81bf4edc56eeab9f3cece9b511f690/vista_… The reported sequence seems to suggest that all the activate messages are skipped. (?)

April 4, 2011

Re: gdiplus: Simplify logic/control flow in SOFTWARE_GdipFillRegion.

by Vincent Povirk

I don't think this is an improvement. I think it's easier to use a single variable to indicate failure in the code, and to only use that variable when deciding whether to proceed further. This case only works because the GdipAlloc happens to be the only operation that can fail in that block before GdipGetRegionScansI. I worry that someone (probably me) could modify the code so that is no longer the case and fail to notice that the logic needs to be changed ( to check for stat == Ok && scans, rather than just scans). On Sat, Apr 2, 2011 at 3:36 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > This doesn't make things tremendously simpler, but does avoid one > unnecessary if / condition. > > If you prefer, I can switch the two arms of the if to retain the > original !scans. > > Gerald > > --- > dlls/gdiplus/graphics.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 4fdfa9c..49f3495 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -3709,16 +3709,15 @@ static GpStatus SOFTWARE_GdipFillRegion(GpGraphics *graphics, GpBrush *brush, > if (stat == Ok && scans_count != 0) > { > scans = GdipAlloc(sizeof(*scans) * scans_count); > - if (!scans) > - stat = OutOfMemory; > - > - if (stat == Ok) > + if (scans) > { > stat = GdipGetRegionScansI(temp_region, scans, &dummy, identity); > > if (stat != Ok) > GdipFree(scans); > } > + else > + stat = OutOfMemory; > } > > GdipDeleteMatrix(identity); > -- > 1.7.4.1 > > >

April 3, 2011

Re: scarddlg: New dll stub

by Nikolay Sivov

On 4/3/2011 17:51, Stefan Leichter wrote: > let the installer from bug #26026 finish > > --- > configure.ac | 1 + > dlls/scarddlg/Makefile.in | 6 ++++ > dlls/scarddlg/main.c | 61 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/scarddlg/scarddlg.spec | 5 +++ > 4 files changed, 73 insertions(+), 0 deletions(-) > create mode 100644 dlls/scarddlg/Makefile.in > create mode 100644 dlls/scarddlg/main.c > create mode 100644 dlls/scarddlg/scarddlg.spec > +/*********************************************************************** > + * FMExtensionProcW (acledit.@) > + * > + */ > + > +LONG WINAPI FMExtensionProcW(HWND hWnd, WORD wEvent, LONG lParam) > +{ > + FIXME("%p, %d, 0x%x) stub\n", hWnd, wEvent, lParam); > + return 0; > + > +} What's that for? It's not used.

April 3, 2011

Re: Possible issue in dlls/d3dx9_36/surface.c?

by Matteo Bruni

On Sat, 2011-04-02 at 23:54 +0200, Gerald Pfeifer wrote: > Matteo et al, > > there is some code in dlls/d3dx9_36/surface.c which GCC struggles with > (in the sense of warning about it), and so do I, so I am wondering whether > you can have a look? > > Specifically, in point_filter_simple_data we have: > > DWORD val = 0, pixel; > > /* extract source color components */ > if(srcformat->type == FORMAT_ARGB) { > pixel = dword_from_bytes(srcptr, srcformat->bytes_per_pixel); > get_relevant_argb_components(&conv_info, pixel, channels); > } > > So, pixel is uninitialized, except when we have FORMAT_ARGB. > > However, directly below we then have > > /* recombine the components */ > if(destformat->type == FORMAT_ARGB) val = make_argb_color(&conv_info, channels); > > if(colorkey) { > get_relevant_argb_components(&ck_conv_info, pixel, channels); > > where pixel is passed to get_relevant_argb_components. This is guarded > by colorkey, a parameter to this function, so indeed I can see pixel being > unused here. > Currently that is not a real problem, as every pixel format has type FORMAT_ARGB (you can see that from the formats array in util.c). Surely the code could be nicer though. > > (I'd naively propose a patch like the one below; this may not be > sufficient though.) > > Gerald > > > diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c > index a3e6e68..cc36818 100644 > --- a/dlls/d3dx9_36/surface.c > +++ b/dlls/d3dx9_36/surface.c > @@ -701,7 +701,7 @@ static void copy_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsize, > DWORD val = 0; > > for(x = 0;x < minwidth;x++) { > - DWORD pixel; > + DWORD pixel = 0xFFFFFFFF; > > /* extract source color components */ > if(srcformat->type == FORMAT_ARGB) { > @@ -768,7 +768,7 @@ static void point_filter_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsi > > for(x = 0;x < destsize.x;x++) { > const BYTE *srcptr = bufptr + (x * srcsize.x / destsize.x) * srcformat->bytes_per_pixel; > - DWORD val = 0, pixel; > + DWORD val = 0, pixel = 0xFFFFFFFF; > > /* extract source color components */ > if(srcformat->type == FORMAT_ARGB) { That would silence the warnings but it doesn't look to me as the right fix. I think the easiest is to just move the format type checks from copy_simple_data and point_filter_simple_data to D3DXLoadSurfaceFromMemory (which is the only caller) and bail out if the source or the destination format is not FORMAT_ARGB. I can prepare a patch for that, if you don't feel like giving it a try. Thanks for the heads-up in any case. :)

April 3, 2011

Possible issue in dlls/d3dx9_36/surface.c?

by Gerald Pfeifer

Matteo et al, there is some code in dlls/d3dx9_36/surface.c which GCC struggles with (in the sense of warning about it), and so do I, so I am wondering whether you can have a look? Specifically, in point_filter_simple_data we have: DWORD val = 0, pixel; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { pixel = dword_from_bytes(srcptr, srcformat->bytes_per_pixel); get_relevant_argb_components(&conv_info, pixel, channels); } So, pixel is uninitialized, except when we have FORMAT_ARGB. However, directly below we then have /* recombine the components */ if(destformat->type == FORMAT_ARGB) val = make_argb_color(&conv_info, channels); if(colorkey) { get_relevant_argb_components(&ck_conv_info, pixel, channels); where pixel is passed to get_relevant_argb_components. This is guarded by colorkey, a parameter to this function, so indeed I can see pixel being unused here. (I'd naively propose a patch like the one below; this may not be sufficient though.) Gerald diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c index a3e6e68..cc36818 100644 --- a/dlls/d3dx9_36/surface.c +++ b/dlls/d3dx9_36/surface.c @@ -701,7 +701,7 @@ static void copy_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsize, DWORD val = 0; for(x = 0;x < minwidth;x++) { - DWORD pixel; + DWORD pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { @@ -768,7 +768,7 @@ static void point_filter_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsi for(x = 0;x < destsize.x;x++) { const BYTE *srcptr = bufptr + (x * srcsize.x / destsize.x) * srcformat->bytes_per_pixel; - DWORD val = 0, pixel; + DWORD val = 0, pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) {

April 2, 2011

Re: Project: x86 to ARM binary translator

by Damjan Jovanovic

On Sat, Apr 2, 2011 at 2:19 AM, Yale Zhang <yzhang1985(a)gmail.com> wrote: > Fellow developers, > I'm thinking of starting a VM project to allow running x86 Windows apps on > ARM Android. This will obviously involve binary translation. I've read about > QEMU's tiny code generator and think for a usable experience, > the intermediate micro-op representation will have to be abandoned, and use > a more efficient, though less portable x86 to ARM translator. I also saw > some Google SOC project that tried to incorporate LLVM into QEMU, but with > disastrous slow down if done naively. I still think it's worth to do so, but > lots of care will need to be done to only optimize code that needs it like > Sun's HotSpot Java compiler does. > Questions: > 1. How useful would this be and how much interest? > Obviously, this will be a huge project, and I just want to gauge the > interest before I jump in. Microsoft will be releasing Windows for ARM soon, > so there will be no need to worry about > running Office, Matlab, Visual C++, etc on ARM, leaving only legacy > applications and games to benefit from binary translation. I'm mostly > interested in seeing some 3D games run on my I would love such a project and am willing to help. Good x86 on ARM emulation is essential, and not just for Wine: Flash doesn't work on ARM, Java (in the form of OpenJDK) doesn't support ARM yet, there's the MPlayer win32codecs, etc. Complete and correct x86 emulation is mighty difficult. The total number of all 16/32/64/MMX/SSE instructions (as seen by the udis86 disassembler) is 710(!!). This is excluding instruction prefixes which change what instruction do (eg. 16 vs 32 bit memory access). When last I checked, qemu didn't support all of those instructions. > Xoom. > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > wine)? > Process VM: > + easier to incorporate 3D acceleration at API level > + uses less memory > + better performance (e.g. no need for MMU translation when accessing > memory) > + much better integration with host OS > - needs to maintain custom Windows API implementation (Wine) * To get 3D acceleration, user-space x86 X/OpenGL drivers would have to be able to talk to the ARM kernel driver for that graphics card, or you'd need x86 to ARM wrappers for X and OpenGL libraries, or you'd need to use x86 kernel driver and do x86 emulation in the kernel too (very hard), or do whole system VM and the kind of 3D acceleration passthrough that VirtualBox does at the moment (which works poorly, in my limited experience). NVidia's ioctls are undocumented IIRC, so even if they provide an ARM port, translating those between x86 and ARM might be difficult. > Whole system VM: > + simpler, more unified to implement > + much better support for apps that are dependent on new, proprietary, > obscure Windows libraries, interfaces (moot because Office, Matlab, etc > will soon be available for ARM) * poor integration with native desktop/filesystem * more to emulate -> slower > Given the aims of only running legacy applications and games, it seems a > foregone conclusion that Wine's process VM approach is best. Comments? Agree, but it doesn't have to be done as part of Wine. What Darwine did - IIRC try to make Wine DLLs PowerPC based and only the application x86 - seems like a bad idea: the application/Windows API split is badly defined and many things (eg. COM) are difficult/impossible to do correctly. I prefer qemu's approach: all user-space is x86, only the kernel is ARM. qemu-i386 doesn't even run 32 bit Wine on amd64 long mode at the moment (segfault on startup), I'll have to investigate at some stage. > 3. Will Wine ever incorporate binary translation? > My proposed design will obviously use Wine's implementation of the > Windows API, which is huge. I'm not sure how disruptive of a change binary > translation will be to Wine. > > If Wine does incorporate binary translation, maybe they can change the > name to Wine Is Now an Emulator > > If your're interested in this project, please reply. Replying. The best way to go here would probably be improving qemu. If it turns out not to be good enough, rewriting the CPU emulation but keeping the system call translation is probably easier than a whole new project written from scratch. Damjan

April 2, 2011

Re: Project: x86 to ARM binary translator

by André Hentschel

Am 02.04.2011 03:14, schrieb Charles Davis: > On 4/1/11 6:19 PM, Yale Zhang wrote: >> Fellow developers, >> >> I'm thinking of starting a VM project to allow running x86 Windows apps >> on ARM Android. This will obviously involve binary translation. I've >> read about QEMU's tiny code generator and think for a usable experience, >> the intermediate micro-op representation will have to be abandoned, and >> use a more efficient, though less portable x86 to ARM translator. I also >> saw some Google SOC project that tried to incorporate LLVM into QEMU, >> but with disastrous slow down if done naively. I still think it's worth >> to do so, but lots of care will need to be done to only optimize code >> that needs it like Sun's HotSpot Java compiler does. Maybe first to ARM Linux and then to ARM Android? >> Questions: >> >> 1. How useful would this be and how much interest? >> >> Obviously, this will be a huge project, and I just want to gauge the >> interest before I jump in. Microsoft will be releasing Windows for ARM >> soon, so there will be no need to worry about >> running Office, Matlab, Visual C++, etc on ARM, leaving only legacy >> applications and games to benefit from binary translation. I'm mostly >> interested in seeing some 3D games run on my >> Xoom. see: http://wiki.winehq.org/ARM http://lists.terrasoftsolutions.com/pipermail/yellowdog-general/2004-June/0… http://www.oesf.org/forum/index.php?showtopic=14829 http://wiki.winehq.org/MacOSX http://wiki.winehq.org/MacOSX/QemuWork >> If your're interested in this project, please reply. > I'm not competent enough to mentor you, but, being a Mac user, I have a > story to tell you. It's about a version of Wine that did incorporate > binary translation: Darwine. Darwine was separate from mainline Wine; it > incorporated QEMU directly and used it to translate x86 to PowerPC code. > In a faraway time when Macs used PowerPC CPUs, Darwine allowed x86 > Windows apps to run on Mac OS X. Now that Macs aren't built PowerPC > chips anymore, Darwine has been abandoned. You might consider using it > as a starting point, though. I know about that and was told it was never implemented because of problems with the endianess (PPC big, x86 little), so i wonder if that ever worked, or was just planned to work? Any Darwine user around? -- Best Regards, André Hentschel

April 2, 2011

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.

by Piotr Caban

Hi, On 04/02/11 08:49, Vincent Pelletier wrote: > +size_t __thiscall MSVCP_basic_string_char_find_cstr( > + basic_string_char *this, const char *str, size_t offset) > +{ > + const char *this_str = basic_string_char_const_ptr(this); > + const char *found = strstr(this_str+offset, str); > + if (found) > + return found - this_str; > + return MSVCP_basic_string_char_npos; > +} It's better to implement basic_string<char>::find(const char *str, size_t offset, size_t count) first and then call it in MSVCP_basic_string_char_find_cstr implementation. basic_string may contain nullbytes, your implementation will not work in this case. cstr may contain nullbytes as well when length is specified. Adding some tests similar to following code may be useful: basic_string<char> test = basic_string<char>("aaa"); test += '\0'; test += "bbb"; basic_string<char> test2 = basic_string<char>(test); test2 += '\0'; printf("%d %s\n", test.length(), test.c_str()); printf("%d\n", test.find("bbb", 0)); printf("%d\n", test.find(test, 0)); printf("%d\n", test.find(test.c_str(), 0, test.length())); printf("%d\n", test.find(test2, 0)); printf("%d\n", test.find(test2.c_str(), 0, test2.length())); Cheers, Piotr

April 2, 2011

Re: Project: x86 to ARM binary translator

by Stefan Dösinger

Hi, I may be telling you nonsense here, I hope Alexandre hits me with a cluestick next Wineconf if I do, but this is my 2c on such a project. On Saturday 02 April 2011 02:19:33 Yale Zhang wrote: > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > wine)? A process VM already exists. It is called qemu. I don't know if it works with Wine, but it works with basic Linux apps. I could run a statically linked ARM ls on a x86 PC(ie, the reverse of what you want). For Libraries the normal Linux multilib scheme would apply, or a chroot. The advantage of this scheme is that the Linux syscall interface is comparably small, but you need every Linux library as x86 library and translate everything. If you want to run x86 Windows apps on ARM I suggest to forget about Wine. Write an app that runs x86 Windows apps on ARM Windows. This wrapper app would be a ARM Windows app. If done properly it will automagically run on ARM Wine. This way you don't have to bother about Alexandre, your app naturally lives as a separate project etc. Plus, you only translate the app itself and not the libraries. The big drawback of that approach is that it is a *lot* of work. You'll have to translate between x86 and ARM on every library call that leaves the app's own code. You'll have to write a wrapper version of every function, COM method, callback of every DLL in C:\windows\system32. This is a *lot* of work, probably comparable to the amount of work needed for Wine itself. What you have going for yourself though is that you can start small, you don't have to implement everything at once. Start with a console hello world app, implement some kernel32 thunks. Go on with Windows, add user32 and gdi32 etc etc etc. A technical challenge is that the Windows DLLs call each other. But that would stay inside the host domain(ie, ARM), and the app doesn't see this anyway. But you'll have to translate pointers, handles etc consistently. And if there's a callback from the library back into the app(e.g. ddraw.dll:DirectDrawEnumerate) you'll have to translate it back. If you make it flexible enough to deal with potential alignment differences(ARM doesn't need that, but PPC does) as well as separate address spaces then you could achieve more goals at once: PPC, Mips, etc support, run x86 apps on x86_64 without Linux x86 libs(although it will be much slower than the classic multilib approach)

April 2, 2011