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

RFC: Summer of Code Proposal: WINE XRDP Driver
by Steven Edwards March 10, 2009

March 10, 2009

Abstract: The goal of this project is to implement rdpservice support in Wine by converting XRDP in to a Winelib application allowing the execution of Wine based applications over the RDP protocol, without the need of a X11 Session/Driver . RDP protocol offers significantly faster performance than X11 or VNC for network applications. Currently if you want to run a Wine application over XRDP you tend to run in to performance problems due to the overhead of the Win32↔X11↔VNC ↔ RDP translation. Workflow: Current Design Using XRDP and Wine (Bad) RDPClient ↔ XRDP ↔ VNC ↔ X11 ↔ X11DRIVER/Wine ↔ Win32 Application Proposed Design (Good) RDPClient ↔ Wine XRDP Daemon ↔ XRDPDriver/Wine ↔ Win32application Details: 1.I believe the most simple route will be to convert XRDP to a Winelib application. Alternatively XRDP will need to be modified to allow direct execution of Wine processes. The current design of XRDP session involves loading selected unix libraries such as a libvnc redirector or librdp redirector. Given that Wine processes tend to want to manage all of their own resources, I believe a Winelib port of XRDP is the most simple route. (I have actually built XRDP as a Winelib process in the past) . This gives us the ability to directly call Win32 functions like CreateProcess from the xrdp_wm to get a proof of concept up and going in short order. 2.a wine libXRDP driver will need to be developed to encapsulate the raw XRDP bitmaps and primitives to related Win32 functions . This of course means that it won't be feature complete for a long time, but as the Quartzdrv showed, it is possible to write a driver that works for simple Winelib applications in short order. 3.Similar to x11driver in Desktop mode, Wine is going to do all of its own Window management. Much like the idea of the SugaredWine, this session would always run explorer.exe Issues: 1.writing a Wine driver is hard. Really hard. Alexandre does not like new ones because he does not want to end up being the only one maintaining them. Also the current XRDP graphic support is very primitive. It's really going to need a DIB engine and all sorts of other magic. I expect given the speed of the RDP protocol, even without the DIB engine, its still going to be faster than running the standard X11->VNC->RDP bridge just due to the removal of many layers of redirection. 2.There are licensing issues. XRDP being based on rdesktop is GPL rather than LGPL. The xrdp_wm code is all orginal to the XRDP project and is really its own library. Based upon my discussions with the XRDP maintainer in the past, I expect we should be able to get some sort of license exception for us linking to this code. Alternatively it could be maintained out of tree by certain parties interested in this support. I know in the past CodeWeavers has expressed interest in a RDP driver and its possible there are other parties that would be willing to help maintain it once a proof of concept was developed and a business case proven. Links: http://wiki.winehq.org/SugaredWine http://wiki.winehq.org/WineExplorer http://wiki.winehq.org/DesktopWindow http://xrdp.sourceforge.net/ http://www.rdesktop.org/ -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

[1/5] vbscript: Added stub DLL
by Robert Wilhelm March 10, 2009

March 10, 2009

Hi Jacek, thanks for looking at my patches. VB uses IDispatch, VBScript uses IDispatchEx. See MSDN doc for IDispatchEx. But I should probably delete this and other superfluous includes, as they currently not yet used. This is a spare time project for me in order to learn more about active scripting. Writing complete vbscript.dll is clearly too ambitious. My plan is to work further along, add more interfaces, code and finally get some "hello world" script running. Maybe this will be enough that others will join the party and e.g. start coding run-time library. Regards, Robert >Your patch series looks good for me, except one little problem: >+#include "windef.h" >+<#include "winbase.h" >+#include "winuser.h" >+#include "ole2.h" >+#include "dispex.h" >+#include "activscp.h" >+ <+ >+ > > >AFAIK VBScript is not based on IDispatchEx (except it uses just >IDispatch), so you shouldn't need to include dispex.h. (While we're at >this, also empty lines in the end of file should be removed). >BTW, are you planning working further on VBScript implementation?

1 0

problem
by savek March 10, 2009

March 10, 2009

Hello, I have an issue with wine, which consists in: when I try run any windows binary, it shows blurry, distorsioned and illegible fonts, highly descouraging me about using it, could you give me a solution, please? I'm running ArchLinux on a P4 box, thanks.

2 1

Sufficient 1.2 release criterion: passing all tests on all platforms?
by Dan Kegel March 10, 2009

March 10, 2009

Even without any new features, it seems to me that passing all tests on all platforms might all on its own merit a new stable release. That said, by the time we have that, we might well have 64 bit support working, too... - Dan

5 16

Fwd: SetDeviceGammaRamp
by Tom Wickline March 10, 2009

March 10, 2009

Forward from wine-patches ---------- Forwarded message ---------- From: 郭强 <strongpan(a)163.com> Date: Tue, Mar 10, 2009 at 1:38 PM Subject: SetDeviceGammaRamp To: wine-patches(a)winehq.org Hi, I got a question about how to use SetDeviceGammaRamp Function. As in SDK, Remarks said:'*SetDeviceGammaRamp* succeeds only for devices with drivers that support downloadable gamma ramps in hardware.' And I tried in my pc, the function return FALSE. but in my friend's pc, it work well. Maybe my pc doesnot support downloadable gamma ramps. So How do I know if my device support that? What's the definition of downloadable gamma ramps ? And what kind of device support that? Thanks so much! -- ------------------------------ 网易邮箱，中国第一大电子邮件服务商 <http://www.yeah.net> -- http://www.wine-reviews.net/ http://bordeauxgroup.com/

1 0

Wow, 2003 is almost all green... only rpcrt4:server failing
by Dan Kegel March 10, 2009

March 10, 2009

The wine test suite is making great progress towards passing on all platforms. http://test.winehq.org/data/tests/rpcrt4:server.html seems to be the sore thumb at the moment; it passes on XP and Wine, but fails everywhere else. I think this is the test that fails on the most platforms. - Dan

3 4

Re: Patch to fix bug 17619 - GetDriveTypeW reporting C: as a network share if /home is an NFS share
by Francois Gouget March 10, 2009

March 10, 2009

On Fri, 6 Mar 2009, Forest Hale wrote: > Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount. > > + if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED; I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

4 7

Re: [PATCH 1/4] gdi32/tests: Don't use bmType to skip tests on win9x - it's equal to 0 for monochrome bitmaps.
by Alexandre Julliard March 10, 2009

March 10, 2009

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/gdi32/tests/bitmap.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) The is_win9x test is broken, that GetWindowLongPtrW call will return 0 on all platforms, so it breaks the tests on Wine: gcc -m32 -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -Werror -o bitmap.o bitmap.c ../../../tools/winegcc/winegcc -m32 -B../../../tools/winebuild -mconsole bitmap.o brush.o clipping.o dc.o font.o gdiobj.o generated.o icm.o mapping.o metafile.o palette.o path.o pen.o testlist.o -o gdi32_test.exe.so ../../../libs/port/libwine_port.a -luser32 -lgdi32 -lkernel32 ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so bitmap.c && touch bitmap.ok bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap bitmap.c:105: Test failed: win9x does not initialize the bitmap make: *** [bitmap.ok] Error 10 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] gdi32/tests: Fix is_win9x test.
by Paul Vriens March 10, 2009

March 10, 2009

Huw Davies wrote: > --- > dlls/gdi32/tests/bitmap.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Wouldn't it be better to do something like: SetLastError(0xdeadbeef); GetWindowLongPtrW(GetDesktopWindow(), GWLP_WNDPROC); is_win9x = (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED); The problem with actually using GetVersion() is that you should be able to run Wine in Win98 mode (winecfg) and have the tests still succeed. -- Cheers, Paul.

1 0

Re: dlls/userenv: fixed stubs GetUserProfileDirectoryW/A (7)
by Vitaliy Margolen March 10, 2009

March 10, 2009

Andreas Rosenberg wrote: > > ------------------------------------------------------------------------ Almost there, just few small things left. > + TRACE("%p %s %p\n", hToken, lpProfileDir, lpcchSize); Don't print output parameters[lpProfileDir] as string only as a point. Unless it's used as in/out. > + TRACE( "%p %s %p\n", hToken, debugstr_w(lpProfileDir), lpcchSize ); Same thing here. > +static const WCHAR profile_pathname[] = { > + 'S', 'o', 'f', 't', 'w', 'a', 'r', 'e', '\\', > + 'M', 'i', 'c', 'r', 'o', 's', 'o', 'f', 't', '\\', > + 'W', 'i', 'n', 'd', 'o', 'w', 's', ' ', 'N', 'T', '\\', > + 'C', 'u', 'r', 'r', 'e', 'n', 't', 'V', 'e', 'r', 's', 'i', 'o', 'n', '\\', > + 0 }; > + > +static const WCHAR profile_subkey[] = { > + 'P', 'r', 'o', 'f', 'i', 'l', 'e', 'L', 'i', 's', 't', > + 0 }; > + > +static const WCHAR profile_keyname[] = { > + 'P', 'r', 'o', 'f', 'i', 'l', 'e', 's', 'D', 'i', 'r','e', 'c', 't', 'o', 'r', 'y', > + 0 }; > + res = RegOpenKeyExW( HKEY_LOCAL_MACHINE, profile_pathname, 0L, KEY_QUERY_VALUE, &keyProfileDir ); > + res = RegGetValueW( keyProfileDir, profile_subkey, profile_keyname, RRF_RT_ANY, > + NULL, buffer, &sizePath ); /* RegGetValue expects pcbData in bytes */ You opening the wrong key and querying the wrong value. You should be opening "Software\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList" key and getting the value of "ProfilesDirectory" entry. Now about those fixed size buffers in GetUserProfileDirectoryW(). Why can't you use the passed in buffer instead? And the last thing - token. Look at _GetUserSidStringFromToken() from shell32/shellpath.c how to get the user from the token. Vitaliy

2 1