May 2014 - Wine-Devel - list.winehq.org

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Wine 64 bit
by Kevin Davies June 5, 2015

June 5, 2015

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard April 23, 2015

April 23, 2015

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

[RFC 0/11] Linux FF: Intro
by Elias Vanderstuyft Sept. 7, 2014

Sept. 7, 2014

Hi, This is the sequel of the mail with title: "Discussion and Improvement of Wine's Linux Force Feedback implementation". This mail is meant to give an introduction to the next 11 mails: All tests were performed using wine-1.7.11-206-g82b3813 (but none of the files of which I propose changes to be made in, are affected in the current (2014-03-04) wine-version 1.7.13) Because I haven't created any (formal) patch yet (and instead first request for comments), I tried to keep the line numbers to reference the affected files more or less based to the version I started from, where I could. However, the orig code of a (informal) patch that has to be applied after (and thus is dependent of) a previous patch, may be different from the initial code of the wine-version I started from. After having discussed everything, I will send a proper patchset. In these mails, sometimes 'FEdit' is mentioned: it's a MS application that allows to create all FF effect types (except CustomForce and rumble/vibration effects), and therefore the ideal test application. Physical behavior is compared between Windows7 (using Logitech MOMO wheel with latest drivers installed) running in Virtualbox, and my patched Wine-version. In the end, (using a dummy FF driver on the Linux side, thanks to Michal Malý), the behavior of Wine is almost (limitations caused by the dummy ff driver, such as updating an effect while playing is not implemented) identical, if not better (in some aspects) then the Windows equivalent. Sometimes I refer to linux-input mailing lists to prove a statement, because the links may vanish (unlikely though), I provide the titles corresponding with the links: (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) "ff-core effect id handling in case of a failed effect upload" (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08459.html) "Questions about the documentation/specification of Linux ForceFeedback input.h" Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] Elias

2 3

Re: configure: Add -linotify when present, for non-Linux platforms.
by Alexandre Julliard Aug. 23, 2014

Aug. 23, 2014

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

2 1

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

Fix for PlgBlt, the XFORM matrix was calculated incorrectly
by Alexander Almaleh June 17, 2014

June 17, 2014

I had tried to submit a patch for that 5 years ago<http://www.winehq.org/pipermail/wine-devel/2009-December/080391.html>, but couldn't figure out how to make a patch/test it, and eventually gave up and forgot about it. But recently I remembered about it, and now I want to try again. So, this time I've prepared a test that can prove that the previous implementation does not calculate the XFORM matrix correctly, and that my patch will fix it. The test is a VC6 project, you can find it at https://drive.google.com/file/d/0B9PGUhmmnsm1S2VvZzc3WmhBY3c/edit?usp=shari…. The test is a demo of PlgBlt that I found on CodeProject<http://www.codeproject.com/Articles/17712/The-GDI-magic-Rendering-reflectio…>. You can compare how it works on XP and on Wine. For testing, I directly inserted the original Wine implementation of PlgBlt, as well as my patched version, into the VC6 project, and tested on that. This is because there seems to be an additional problem with MaskBlt, which I'll try tackling next. I have screenshots of what the demo looks using Windows's PlgBlt<http://imgur.com/q8qKGd7>, and Wine's PlgBlt <http://imgur.com/smYEV6z>. To test it, simply look at this function in the VC6 project: BOOL MyPlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { // return MyPlgBltWinePatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); return MyPlgBltWineUnpatched(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); // return PlgBlt(hdcDest, lpPoint, hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hbmMask, xMask, yMask); } Uncomment the function you want to test. If you need something else (like binaries), just write. And this is the patch itself. I've tried to keep the changes minimal, with respect to white-space, etc. I've removed a "return FALSE", because I don't calculate a determinant explicitly. commit c9ca2cab58fa0cba3d6b24cfb2af507fd1c07227 Author: Alexander Almaleh <sashoalm(a)gmail.com> Date: Tue May 20 18:33:55 2014 +0300 Fix for the calculation of the XFORM matrix in PlgBlt. diff --git a/dlls/gdi32/bitblt.c b/dlls/gdi32/bitblt.c index 4750d1b..1de25b9 100644 --- a/dlls/gdi32/bitblt.c +++ b/dlls/gdi32/bitblt.c @@ -992,22 +992,32 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) { + /* we need to use floating-point precision when calculating the + * XFORM matrix to avoid loss of precision due to rounding */ + typedef struct tagPOINTLF + { + double x, y; + } POINTLF; + int oldgMode; /* parallelogram coords */ - POINT plg[3]; + POINTLF plg[3]; /* rect coords */ - POINT rect[3]; + POINTLF rect[3]; XFORM xf; XFORM SrcXf; XFORM oldDestXf; - double det; + int ii; /* save actual mode, set GM_ADVANCED */ oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED); if (oldgMode == 0) return FALSE; - memcpy(plg,lpPoint,sizeof(POINT)*3); + for (ii = 0; ii < 3; ii++) { + plg[ii].x = lpPoint[ii].x; + plg[ii].y = lpPoint[ii].y; + } rect[0].x = nXSrc; rect[0].y = nYSrc; rect[1].x = nXSrc + nWidth; @@ -1015,33 +1025,39 @@ BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, rect[2].x = nXSrc; rect[2].y = nYSrc + nHeight; /* calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram to rectangle) */ - /* determinant */ - det = rect[1].x*(rect[2].y - rect[0].y) - rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y); - - if (fabs(det) < 1e-5) - { - SetGraphicsMode(hdcDest,oldgMode); - return FALSE; - } TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n", hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y); /* X components */ - xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x - plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det; - xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) - - rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) + - rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x) - ) / det; + xf.eM11 = -(rect[1].y*plg[2].x+rect[0].y*(plg[1].x-plg[2].x) + -rect[2].y*plg[1].x+plg[0].x*(rect[2].y-rect[1].y)) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+ + rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eM21 = (plg[0].x*(rect[2].x-rect[1].x)-plg[1].x*rect[2].x + +plg[2].x*rect[1].x+(plg[1].x-plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x + +rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); + xf.eDx = -(rect[0].y*(plg[2].x*rect[1].x-plg[1].x*rect[2].x) + +plg[0].x*(rect[1].y*rect[2].x-rect[2].y*rect[1].x) + +(rect[2].y*plg[1].x-rect[1].y*plg[2].x)*rect[0].x) + /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y + *rect[1].x+(rect[1].y-rect[2].y)*rect[0].x); /* Y components */ - xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det; - xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; - xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) - - rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) + - rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y) - ) / det; + xf.eM12 = -(rect[1].y*(plg[2].y-plg[0].y)+rect[0].y*(plg[1].y + -plg[2].y)+rect[2].y*(plg[0].y-plg[1].y))/(rect[0].y*(rect[2].x + -rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y + -rect[2].y)*rect[0].x); + xf.eM22 = ((plg[0].y-plg[1].y)*rect[2].x+(plg[2].y-plg[0].y)*rect[1].x + +(plg[1].y-plg[2].y)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x) + -rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y) + *rect[0].x); + xf.eDy = (rect[0].y*(plg[1].y*rect[2].x-plg[2].y*rect[1].x) + -rect[1].y*plg[0].y*rect[2].x+rect[2].y*plg[0].y*rect[1].x + +(rect[1].y*plg[2].y-rect[2].y*plg[1].y)*rect[0].x)/(rect[0].y + *(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x + +(rect[1].y-rect[2].y)*rect[0].x); GetWorldTransform(hdcSrc,&SrcXf); CombineTransform(&xf,&xf,&SrcXf);

4 10

Re: wined3d: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4 (try 4)
by Stefan Dösinger June 11, 2014

June 11, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-30 00:45, schrieb Andrei Slăvoiu: > Add back glsl check to make sure the card is capable of DX10. > > --- dlls/wined3d/directx.c | 4 +++- 1 file changed, 3 > insertions(+), 1 deletion(-) Looks good to me. Note that Alexandre and Henri are on holidays right now, so it might take a while before it is committed or you receive further comments. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiD0QAAoJEN0/YqbEcdMwcjcP/jAOsNo8MoM8sSlc2RVtU7Y5 tHVmUyMZ0xPSa7DaA13GFT7/hPnRXimRY39epjJ3subulmprkXV+HNtaHWBVkEvR lB+YSJJDFGJ9V81o7aVSUfXydeY81C3TB6TbztO9WtVPSVaE9/ZXJ1ZO3edufoXT XhXMJwce9HmL8nU+SRFo+mAc/FLimCuTwMMf6OF61KlAMTkzGSQoh8sUSwO0hndL /+yARXxgYhBAtepVb2vuL7411/VWlbzrD8S8h4sZhEnCgLNuyGjXFyggjTZn+MWd zYf5MgBWmY/YJu1VES3lkM8VM5FpgJgEcM3DG8BEQ3yI5eyBLReMiKQe3uuyhlnJ KdE9tSPP3Ts2gHYeZ90kGImebtjy5sxA0gsekY5J4oNsbDUfO01OoHde+54GG6WD 25aogs1+edJNZMGI6pxScDl6EoPgbTlBjL5dJ2xDYc1P/ACezNqPBe+tCDoqoVon WBlqNSNntcfCUBEoiXpOcRFK0PeJDIMHRKpZEBM63V3gFW6w0KuI+Sj0JcwFxy+u saLOwXDpaGerhar2njWiCEKwM1NfW2Wj7wcY0/eiy56bi9UvhDCAUqqZ98xlFZuP m8Js4Bwzlp7NHQjaqXo/h3uK36B0OngHZkjRm/hXMEFuQHfCSbKtUMZLn27JI+3a chXJiqk95eUes6GLKzGo =tusS -----END PGP SIGNATURE-----

3 2

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4
by Stefan Dösinger June 3, 2014

June 3, 2014

Am 23.05.2014 um 00:23 schrieb Andrei Slăvoiu <andrei.slavoiu(a)gmail.com>: > Mesa drivers do not expose EXT_GPU_SHADER4 as all functionality it offers is > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. The problem is that without GL_EXT_gpu_shader4 or GL_ARB_shader_texture_lod we cannot handle the texldd instruction. Right now we cannot use core contexts, so unless the driver exposes one of those extensions in compatibility contexts we are stuck on a shader model 2 feature level :-( . The level detection your patch changes isn't directly related to this, as the shader model version support is controlled differently. But a Radeon 9500 matches a card with shader model 2 support much better than a Radeon R9. Does this driver / gpu combination support GL_ARB_shader_texture_lod?

3 9

Re: ntdll: Use lockfree implementation for get_cached_fd.
by Ken Thomases June 2, 2014

June 2, 2014

On May 31, 2014, at 10:28 AM, Sebastian Lackner wrote: > Explanation: The basic idea of this patch is that we have a global > counter 'fd_cache_epoch' which is incremented, whenever the file > descriptor cache is updated. get_cached_fd() first reads the counter, > then the fd entry, and afterwards the counter again - if the counter has > changed we know that a second thread has maybe modified the content, and > have to read it again. The memory barrier is there to ensure that > compilers don't optimize away the two reads of 'fd_cache_epoch'. Please > note that: > > * the order of the write instructions when updating the content is > important - this way we ensure that threads only see either (0, *) = not > set, or a valid entry. > > * I assume that reading/writing up to the pointer size can be done as an > atomic operation (threads either see the old or new value, but no > partial updates). This assumption is also used in a lot other parts of > wine, for example here: > http://source.winehq.org/source/dlls/ntdll/sync.c#L1295 > [ It would probably be more safe to introduce special > interlocked_get/interlocked_set macros/functions for that, but not sure > what other people think about that... ] Thanks for working on this. Interesting stuff. I think there are still some issues. In order to ensure a consistent view of the ordering of memory operations, memory barriers have to be used in both the writer and the reader. The writer issues a write barrier after it has written and the reader issues a read barrier before it reads. The appropriate barriers are implicit in interlocked_xchg_add() for incrementing fd_cache_epoch, but the first read of it in get_cached_fd() has no read barrier before it. I think this is benign, though, because I think this can only result in the code thinking the epoch changed when it hasn't. It may retry unnecessarily. More problematic is the writing of the fd and its attributes. There are barriers implicit in the interlocked_xchg() which clears the fd, but there's no write barrier after the final write to it. There's no read barrier before the first read of them. You mention the order of writing, attributes first then fd, as being important. But there's no barrier in between the two operations, so either the compiler or the CPU could reorder either the writes or the reads, thwarting your design. The compiler can also reorder the reading of the fd_cache_epoch with respect to the reading of the fd or attributes. I think you can get this as the effective sequence: thread1 / get_cached_fd / read fd, get old fd thread2 / add_fd_to_cache / clear fd thread2 / add_fd_to_cache / increment epoch thread2 / add_fd_to_cache / set fd thread1 / get_cached_fd / read epoch thread1 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / get_cached_fd / return old fd I think it's sufficient to have a write barrier after writing the fd and then a read barrier just before reading it. I _think_ that this obviates the need for the barrier at the bottom of the do-while loop. That is, you can just move that barrier up a line. I'm not 100% confident of my analysis of that. (Well, frankly, I'm never 100% certain of my analysis of this sort of code.) In the email thread regarding Daniel Horn's patch, I suggested an approach using interlocked_cmpxchg() to check if the fd had changed after reading the attributes. Was there a reason you rejected that approach? You mentioned an approach you experimented with using interlocked_cmpxchg64(). What was that about? Were you treating the fd and attributes combined as a single 64-bit value and then checking them both? Was that safer than my suggestion for some reason? If the only advantage is a slight performance improvement (especially in light of the huge difference that either approach has to the status quo, judging by your chart), then I'd argue for the simpler approach that's more easily analyzed for correctness. If the above issue is addressed, that leaves one remaining problem: get_cached_fd() can encounter a false negative: thread1 / add_fd_to_cache / set fd to -1 thread1 / add_fd_to_cache / increment epoch thread2 / get_cached_fd / read epoch thread2 / get_cached_fd / read attributes thread2 / get_cached_fd / read fd, gets -1 thread2 / get_cached_fd / check if epoch has changed, conclude it hasn't thread1 / add_fd_to_cache / set attributes thread1 / add_fd_to_cache / set fd thread2 / get_cached_fd / return -1 thread2 / server_get_unix_fd / see get_cached_fd as having failed since it returns -1 thread2 / server_get_unix_fd / do get_handle_fd server request thread2 / server_get_unix_fd / call add_fd_to_cache to cache the new fd I think you want to try get_cached_fd() again, inside the critical section, if the first call fails. -Ken

2 2

Video memory size detection in D3D
by Ruslan Kabatsayev June 2, 2014

June 2, 2014

Hello all, It seems Wine doesn't use any way to reliably detect video memory size, and for many video cards needs it to be specified as HKCU\Software\Wine\Direct3D\VideoMemorySize key in registry. But there exist at least three (vendor-specific) GL/GLX extensions which seem to address exactly this. Namely, for Mesa it's GLX_MESA_query_renderer [1], for nVidia it's GL_NVX_gpu_memory_info [2], and for ATI/AMD it's GL_ATI_meminfo [3]. Mesa extension is shipping starting from Mesa 10.0, nVidia ships their extension in 195.XX drivers (said in specification; I have it exposed with my 313.09 driver), don't know status of ATI extension though (marked as "???" in spec). It'd be good if Wine could utilize these. Is there any work towards this already? Regards, Ruslan [1]: http://www.opengl.org/registry/specs/MESA/glx_query_renderer.txt [2]: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt [3]: http://www.opengl.org/registry/specs/ATI/meminfo.txt

5 6

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)
by Stefan Dösinger June 2, 2014

June 2, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-29 01:33, schrieb Andrei Slăvoiu: > Drop the check for glsl_version. All wine shaders use #version 120 > so it doesn't matter. That's not quite right. Yes, it is true that we never use GLSL 130, so the version check isn't representative for what wined3d actually supports. For shader model 4 support we need much more than just GLSL 130, half of the d3d10 infrastructure is still missing. GL_ARB_shader_texture_lod doesn't imply shader model 4 support. My Radeon X1600 supports this extension on OSX, and this is a shader model 3 card. The X1600 doesn't support EXT_gpu_shader4 or GLSL 130. The point of this code is to check the capabilities of the card, not the capabilities of our d3d implementation. Thus to prevent SM 3 cards from being reported with PCI IDs that suggest SM 4 capabilities you need to check for all the other functionality that's supported by EXT_gpu_shader4 / GLSL 130. Even if we have a SM 4 capable card our d3d9 implementation does not expose SM 4 support. But neither does Microsoft's d3d9 implementation. There's also GLX_MESA_query_renderer. It gives us the PCI IDs and video memory size directly, without all the string parsing guesswork. We cannot use it wined3d directly. A possible approach would be to expose a similar WGL_WINE/MESA_query_renderer extension from winex11.drv and winemac.drv and use that in wined3d. The current wined3d guesswork code could be moved to winex11.drv and used in cases where GLX_MESA_query_renderer is not supported. (OSX has similar functionality that's always available) User32 also has a function (EnumDisplayDevices) to query the GPU identification string, and some applications (Company of Heroes demo) fail if the user32 GPU name differs from the d3d9 GPU name. So maybe a WGL extension isn't quite the right interface, and it should be something that does not require a GL context so user32.dll can use it as well. EnumDisplayDevices does not export all the information wined3d needs though - the PCI IDs and video memory size are missing I think. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThvZZAAoJEN0/YqbEcdMwsY8QAJG1NQVMSqjwaguVR0cwwNXq IMYCRWL+5cJPxK4Eodt4bF+zZDObqCz9r3hAJVlkA6bJIcflNHJwedT0ddeOAfpe 0Xc8g+NvspN715yNt51PpzcnlSqh2vS18qp1JLb4l00pZuPt8PMNqC0gaePkv+tY 1wY3B/kgbl0TfcIRpxWbwZBcIAM2h4g+FGCHFPFeznhMYWqFaJ67OKW1KAdfpBTT lPZsaNDXtU8hSaVQYVk7ITulUl0C8tW/MExnh4zclz6b/wQuG+/M0WRg5v/YDlNq 0ZAsVqT60+MbepR87ehYDnLB7RMjZMjZhEZ4/drafFbOQBmqL7YJjgbFsbBBXLTt COf/1mjiz7TptUvSUyDRc27o1K+YP1UoswsVdXT37sWkP9gtHtQFeLLNx8ZuR4pa 2yQ7xNIBi7KPNBjz9Q0RKYvc11oGVUvFSuD0gLgNuHZxdOmBWwZyHeSce9adHHGU 5t4Oz0FsTZuEiiuJXPTDatp06KQQpUZ/c7FgcO7bxIpn/NNUCZGKZdKT/ZYM1waf BEtBL2Ov+DzRnvRM3/lVPdaiMD1IY54bqTeU7NOiKCEFhBl0elCAblj155tVaKdR 5WekiCEsvB8S4FE6stDa+GewpBWUZiVLGSL49S0MViPqAbkbgcjcNlRVg6IEH2Zo tyQIl6/9DwdY1TCllA9W =Z1W8 -----END PGP SIGNATURE-----

3 7

New Wine patches
by Chakke, Neha (GE Oil & Gas) June 2, 2014

June 2, 2014

Hello , I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . http://wiki.winehq.org/USB I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. Thanks and regards, Miss Neha Chakke Engineering/Technology GE Oil & Gas Measurement & Control T: +49 (0) 2233 601 123 neha.chakke(a)ge.com<mailto:neha.chakke(a)ge.com> www.ge-mcs.com<http://www.ge-mcs.com/> [NewMeatball] GE Sensing & Inspection Technologies GmbH Robert-Bosch-Str. 3 50354 Hürth Germany

3 2

Re: ntdll: Use lockfree implementation for get_cached_fd. (try 2)
by Ken Thomases June 1, 2014

June 1, 2014

On May 31, 2014, at 12:05 PM, Sebastian Lackner wrote: > Changes in try 2: > > * Always try to access the fd cache two times - this ensures that we > don't release a file descriptor when its still in use by a second thread. Heh. Well, you can ignore that part of my reply to your previous try. :) > * Replace interlocked_xchg() with an assert(). The original code looks > like its valid that the fd is nonzero at this point, but in fact this > would cause releasing a file descriptor which is still in use. I'll leave it to others to comment on that. > Replacing with an assert() also saves a couple of CPU cycles. I understand that this is an attempt to improve performance, but I don't think it's necessary to squeeze every last CPU cycle out of this code. -Ken

2 1

Re: ntdll/tests: Fix exception test failures on x86_64.
by Marvin May 31, 2014

May 31, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7354 Your paranoid android. === w2000pro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:406: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:406: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:406: Test failed: 42: Wrong exception address 7751ED97/003D0001 === w2008s64 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77E5ED97/003C0001 === w7u (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:406: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:406: Test failed: 42: Wrong exception address 00290000/00290001 exception: unhandled exception 80000004 at 00290000 exception.c:406: Test failed: 42: Wrong exception address 77174D17/00290001

1 0

Re: dmscript/tests: Test some IPersistStream methods of DMScriptTrack.
by Marvin May 31, 2014

May 31, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7339 Your paranoid android. === build (build) === Patch failed to apply

2 1

vs2013 support
by Daniel Lehman May 30, 2014

May 30, 2014

Is anyone already working on VS2013 support (msvcp120.dll)? or have plans to? Thanks daniel

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME (try 2)
by Marvin May 29, 2014

May 29, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7316 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Re: [2/2] ws2_32: Properly implement SO_CONNECT_TIME
by Marvin May 28, 2014

May 28, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7301 Your paranoid android. === w2000pro (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w7u (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w8 (32 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === wvistau64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0 === w2008s64 (64 bit sock) === sock.c:4244: Test failed: unexpected connect time 0 sock.c:4250: Test failed: unexpected connect time 0

1 0

About wineserver and winsock
by Bruno Jesus May 27, 2014

May 27, 2014

Hi all, after studying the ws2_32 dll code for some time while looking for ways to optimize it I started wondering why is the wineserver required (please don't stop reading yet). make test takes 45 seconds in my machine while it takes 25 seconds in a XP VM running on the same machine. The culprit is test_send() [1] which takes 24 seconds in wine and 1.8 seconds in windows. This long time is related to the 1 million recv() calls in test_send(). Each call to recv() has to call wineserver to do a enable_event(FD_READ) operation, if you comment that line out [2] wine magically takes 1.7 seconds, just like windows does (obviously commenting that line generaters other errors related to event sequences). So, in simple words: what if we move all wineserver socket code to a thread that is started in the ws2_32 DLL. I know this may sound very silly for the experienced wine developers, maybe some operations are impossible without the wineserver, maybe there is much more things affected, but I think it's better to ask and get crushed with (hopefully) constructive criticism than forget about the idea. My main objective with this is to speedup the whole implementation and properly implement the select call (different socket states result in different checks required) and WSACleanup call (which needs to close every open socket on last cleanup) and some other get/setsockopt stuff. [1] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/tests/sock.c#l… [2] http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ws2_32/socket.c#l6684 Best wishes, Bruno

5 4

Re: [PATCH 2/2] propsys: Forward exported calls to corresponding methods
by Jacek Caban May 27, 2014

May 27, 2014

Hi Nikolay, On 05/27/14 11:09, Nikolay Sivov wrote: > From 386a536f9ae75505cd95601e4a8ca936b826658c Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Mon, 26 May 2014 22:38:35 +0400 > Subject: [PATCH 2/2] propsys: Forward exported calls to corresponding methods It seems to me that forwarding the other way be more logical. Jacek

1 0