September 2015 - Wine-Devel

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

Running WineTest every day the easy way
by Francois Gouget Feb. 10, 2016

Feb. 10, 2016

So this time I've done things in the right order: first publish the code and then announce it. So here's wt-daily, a script to "orchestrate all the daily WineTest runs and related tasks." Here's the 'quickstart guide': git clone https://github.com/fgouget/wt-daily.git cd wt-daily vi wt-daily.config In this file set the following environment variables: email="your email address here" tag="a-tag" desc="A description of your system for Wine developers" shutdown="suspend" Then when you know you won't be needing your computer for a while, just type ./wt-daily. This will update and rebuild Wine, run the tests and finally suspend your machine. It's that simple! If you'd rather not suspend your machine you can set shutdown to "poweroff", "reboot" or even leave it out to keep the computer on. By default wt-daily will ask for your green light before starting the tests. So you can start it while still using the computer and click 'Ok' once you take off. To have the tests run automatically (e.g. from cron), pass --auto-test on the command line or set default_options="--auto-test" in the configuration file. If you have a 64-bit system then you can also set the {tag,desc}wow32 and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run the tests using the Mac driver instead of (or in addition to) X11. The script should work on OS/X though I have obviously not tested it in a long time. I'ĺl be happy to get feedback on that, particularly in the form of patches. Now you can totally stop reading here. But there's a ton more that the script can do. Read on if you want to discover more. You can have the script start an application that will prevent the tests from running until you close it. I used that to run the tests on a MythTV client box. Wine would get updated and rebuilt in the background while I was watching TV and once that was done the script would run the tests and finally power off the computer. You can also take an image of a suitably configured Windows partition and have wt-daily restore that image to the partition, reboot to Windows which will automatically run WineTest (you'll find the batch script for that in the repository), then reboot back to Linux (or shutdown the computer). This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers boxes to run the tests on Linux, then Windows 8.1 and then Windows 10. All automatically. The script actually runs every hour and skips the tests (and rebooting) if nothing changed since the last run. I also have this Windows image thing set up on my fg-acer64 laptop but there I interactively select which Windows image to restore, with a choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going through a reboot). You can also extend wt-daily to add non Wine tasks. For instance on my laptops it runs another script that synchronizes the Documents folder with my desktop and runs 'git fetch --all' in all my Git repositories. This way the next time I go offline everything is up to date. The repository also contains a number or scripts that you may find useful in your own automation tasks as they support not just Linux but OS/X too. wt-image Creates, checks, restores or reboots to a disk image. wt-bot Update, build and check the Wine source code, and run the tests. wt-make Seeks to automatically fully use CPU and I/O parallelism when running make. wt-ask Asks a simple Yes/No question to the user. wt-notify Displays a notification to the user. wt-power Powers off, reboots, suspends or hibernates the computer. wt-screensaver Controls the screensaver. In particular it can prevent it from triggering. wt-nice Runs the specified command with the lowest possible CPU and I/O priority. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

1 1

Bugzilla changes
by Austin English Dec. 29, 2015

Dec. 29, 2015

Howdy all, As Alexandre mentioned [1], at WineConf we made several decisions to modify bugzilla in a few ways. I've now implemented those changes, which are outlined below: * New wine-staging product: This should be used for bugs caused by patches that are in wine-staging, but that do not occur in wine-development (i.e., wine-staging patch regressions) * New STAGED resolution: This is to differentiate bugs that are FIXED (in wine-development) from bugs that are not present in wine-staging because of one or more patches. The anticipated workflow is: UNCONFIRMED > bug confirmed, NEW > patch written and sent to wine-patches, if it's accepted, FIXED. If not, and the patch is integrated into wine-staging, then the bug is STAGED. When the patch is revised and eventually integrated into wine-development, the bug should move to FIXED. * New NEEDINFO resolution: There's a lot of confusion and different handling by triagers for what to do with bug reports that are incomplete (i.e., leaving it open versus closing invalid). To mitigate this, I've added a NEEDINFO resolution. If a bug report lacks needed information, set it to this status. Bug that have been open NEEDINFO for more than 1 year can be closed. * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other projects do, and eliminates confusion about the upstream/downstream distinction. Please let me know if there are any questions or ideas for further enhancements. [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html -- -Austin

6 11

A new attempt on WSACleanup
by Bruno Jesus Nov. 25, 2015

Nov. 25, 2015

Hi all, a possible way to solve the WSACleanup in the DLL side is to retrieve all existing sockets from the current process in a server call and then closing then inside winsock. Is it possible to make a wine server call that returns variable length data? If yes, can anyone show an example? Such function would also allow for a proper implementation of SetTcpEntry (iphlpapi) which would make firewalls that like to close TCP connections happy.

4 8

Videos or Slides from WineConf
by Joel Holdsworth Oct. 25, 2015

Oct. 25, 2015

Hi, are there any plans to publish videos or slides from wineconf? Joel

11 15

Re: d3d8: Adjust D3DCOLOR_ARGB to avoid shift overflow.
by Stefan Dösinger Oct. 16, 2015

Oct. 16, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-13 um 22:56 schrieb Gerald Pfeifer: > -#define D3DCOLOR_ARGB(a,r,g,b) ((D3DCOLOR)((((a)&0xff)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff))) > +#define D3DCOLOR_ARGB(a,r,g,b) ((D3DCOLOR)((((a)&0xffu)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff))) Wouldn't it make sense to make the masks for the other channels unsigned too? Are there any possible side effects when compiling code with winelib? The native header uses a signed 0xff. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9o1AAAoJEN0/YqbEcdMwVwUP/3G2g6LM41sKgJt3/mxlhkQ4 BdxJ+Oj2Sz1FdefWNzohcRGI5V8AaRSfoCyCQCvSvFRUm72VY9aMKvK3Nhg7gku0 OmP9z81GEDIb13eLNGrcGNmU97wsqk69MtahHFZ3tj8gYLEWVW3sZPwU64VOa89g 7eLLrx5xXGAhoyzN/q85rV7oGj6xmCzv8YKzasv7BAQIdARVwoSVzmyH2kqbuJFf ENVHyoPSJpphYBc4vxSOLVelgVCGEeAdAECnaGpGG+UfT8Sha3GTFu5q6Nn8P9Gx 3irwIPv7nfgqgdBFDRZUOuck/P5mirM9K3YQLB5309usVh7czusvR6LRWR7g5/gD aCf3fub02sfVe0+Sl2NBMfjF361qaOcMpv63e6+QGToKRIXSE9Ht/v4oUeblNi+h H6K/ljyv/kXr9mDUQBRbRUFlcKtp9Cm49xHAK7cT2xDrIj9z18mExKeARz+V1hiF Fs9W/sJao6F+LN9p1XpdZ+Ha10zvFUrsF3OPj09nyv/C+lXdIt5WgFIiI6gzsD/Z +vKFEoiYWnea9xBO9hUprnr4HTNlCMCZroQrvgeJm3xVxhcZZ9d7XQk7Q+oS1UlU S1g4FJL/Ea8EPNW5bq35F9x50azgZVKmdgIDe1ZtogDF+tgGwuuHN5DiqHAhU2cM deINoftjzz/ztYWqm2Yh =kZgE -----END PGP SIGNATURE-----

2 1

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe Oct. 11, 2015

Oct. 11, 2015

Hi, I had a problem with Majesty Gold HD running at glacial speed on my machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. I profiled wine (Instruments time profile) and noticed that most time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine with an optimized sse2 version from pixman did not make much of a difference. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

WineConf 2015 decisions
by Alexandre Julliard Oct. 10, 2015

Oct. 10, 2015

Over the last few months there have been a lot of discussions about how to improve our development process. I've been gathering feedback, and last week at WineConf I summarized the suggestions in my keynote presentation; the slides can be viewed at http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are: - Wine-staging is now considered an integral part of the Wine development process, and will be used as a mechanism to enable more patches to meet the requirements for inclusion in the main tree. We will all be working together as a team. - Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla. - We will switch to a time-based stable release, on a yearly schedule. The code freeze will start every year in the fall. Michael Stefaniuc will be maintaining the stable branch starting with 1.8. - We will start enforcing a Signed-Off-By header on patches, to make it possible to better distribute reviewing responsibility, and to allow multiple authors to cooperate on a patch. - We will keep a list of maintainer contact information for the various submodules; developers will be encouraged to go through the respective maintainer before submitting to wine-patches. - There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches. - The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved. - We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements. These changes will be implemented over the next few weeks. I'm hoping that this will make the development process more pleasant for everybody, and enable us to better respond to users' needs. Once these changes are in place, I'll also encourage everybody who had given up in disgust to give us another chance; and if things are still not satisfactory, please send us feedback. This is a work in progress, and we will continue to listen and work on making things better. -- Alexandre Julliard julliard(a)winehq.org

9 17

Re: [PATCH 1/2] reg: simplify root key search
by Stefan Dösinger Oct. 3, 2015

Oct. 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks, this time the patches apply OK for me. I've told Alexandre that the patches look OK to me, let's see what he says. Cheers, Stefan Am 2015-09-03 um 21:51 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > --- > programs/reg/reg.c | 85 +++++++++++++++++++++++++++--------------------------- > 1 file changed, 43 insertions(+), 42 deletions(-) > > diff --git a/programs/reg/reg.c b/programs/reg/reg.c > index 4ec25bc..0f28b63 100644 > --- a/programs/reg/reg.c > +++ b/programs/reg/reg.c > @@ -22,6 +22,32 @@ > > #define ARRAY_SIZE(A) (sizeof(A)/sizeof(*A)) > > +static const WCHAR short_hklm[] = {'H','K','L','M',0}; > +static const WCHAR short_hkcu[] = {'H','K','C','U',0}; > +static const WCHAR short_hkcr[] = {'H','K','C','R',0}; > +static const WCHAR short_hku[] = {'H','K','U',0}; > +static const WCHAR short_hkcc[] = {'H','K','C','C',0}; > +static const WCHAR long_hklm[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > +static const WCHAR long_hkcu[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > +static const WCHAR long_hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > +static const WCHAR long_hku[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > +static const WCHAR long_hkcc[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > + > +static const struct > +{ > + HKEY key; > + const WCHAR *short_name; > + const WCHAR *long_name; > +} > +root_rels[] = > +{ > + {HKEY_LOCAL_MACHINE, short_hklm, long_hklm}, > + {HKEY_CURRENT_USER, short_hkcu, long_hkcu}, > + {HKEY_CLASSES_ROOT, short_hkcr, long_hkcr}, > + {HKEY_USERS, short_hku, long_hku}, > + {HKEY_CURRENT_CONFIG, short_hkcc, long_hkcc}, > +}; > + > static const WCHAR type_none[] = {'R','E','G','_','N','O','N','E',0}; > static const WCHAR type_sz[] = {'R','E','G','_','S','Z',0}; > static const WCHAR type_expand_sz[] = {'R','E','G','_','E','X','P','A','N','D','_','S','Z',0}; > @@ -95,51 +121,26 @@ static int reg_message(int msg) > return reg_printfW(formatW, msg_buffer); > } > > -static int reg_StrCmpNIW(LPCWSTR str, LPCWSTR comp, int len) > +static inline BOOL path_rootname_cmp(const WCHAR *input_path, const WCHAR *rootkey_name) > { > - int i; > + DWORD length = strlenW(rootkey_name); > > - for (i = 0; i < len; i++) > - { > - if (!str[i]) > - { > - len = i + 1; > - break; > - } > - } > - > - return CompareStringW(CP_ACP, NORM_IGNORECASE, str, len, comp, len) - CSTR_EQUAL; > + return (!strncmpiW(input_path, rootkey_name, length) && > + (input_path[length] == 0 || input_path[length] == '\\')); > } > > -static HKEY get_rootkey(LPWSTR key) > +static HKEY path_get_rootkey(const WCHAR *path) > { > - static const WCHAR szHKLM[] = {'H','K','L','M',0}; > - static const WCHAR szHKEY_LOCAL_MACHINE[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > - static const WCHAR szHKCU[] = {'H','K','C','U',0}; > - static const WCHAR szHKEY_CURRENT_USER[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > - static const WCHAR szHKCR[] = {'H','K','C','R',0}; > - static const WCHAR szHKEY_CLASSES_ROOT[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > - static const WCHAR szHKU[] = {'H','K','U',0}; > - static const WCHAR szHKEY_USERS[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > - static const WCHAR szHKCC[] = {'H','K','C','C',0}; > - static const WCHAR szHKEY_CURRENT_CONFIG[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > - > - if (!reg_StrCmpNIW(key, szHKLM, 4) || > - !reg_StrCmpNIW(key, szHKEY_LOCAL_MACHINE, 18)) > - return HKEY_LOCAL_MACHINE; > - else if (!reg_StrCmpNIW(key, szHKCU, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_USER, 17)) > - return HKEY_CURRENT_USER; > - else if (!reg_StrCmpNIW(key, szHKCR, 4) || > - !reg_StrCmpNIW(key, szHKEY_CLASSES_ROOT, 17)) > - return HKEY_CLASSES_ROOT; > - else if (!reg_StrCmpNIW(key, szHKU, 3) || > - !reg_StrCmpNIW(key, szHKEY_USERS, 10)) > - return HKEY_USERS; > - else if (!reg_StrCmpNIW(key, szHKCC, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_CONFIG, 19)) > - return HKEY_CURRENT_CONFIG; > - else return NULL; > + DWORD i; > + > + for (i = 0; i < ARRAY_SIZE(root_rels); i++) > + { > + if (path_rootname_cmp(path, root_rels[i].short_name) || > + path_rootname_cmp(path, root_rels[i].long_name)) > + return root_rels[i].key; > + } > + > + return NULL; > } > > static DWORD wchar_get_type(const WCHAR *type_name) > @@ -237,7 +238,7 @@ static int reg_add(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > @@ -307,7 +308,7 @@ static int reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6XG1AAoJEN0/YqbEcdMwWysP/0BvR0rXG67sd/NC5pPItrVv R2bGZceGH8yJpBuYOxpp2W5p9sCRMfoc2giTXrhmvUwVrutXrUbI9c/SqOlLZL6I YLOObNIo/DI6MxBwGaZ2jKGJKWEW3kzg5qKkJWzPIMg92zfbgtQxiTxhvAvd1xaR MxXLzKt+mhMWjPwyFR3omSFCTkvTguWxnXIVEf2S6TRshJnI0A10vJQUj1AC4dsX ZnHZkuXOAgwzgzmvkEnxbNsgkRzqmXCZaUbapcgJ5TXwwuiLMr4AuPbEcYmdf2g+ CqIYeIUYVtbg3pga/9WFdSki0YaAcJJ7kYTt5lEYRN3/V93W6QsPp/SaUXyx1J1B UOCbuj1UNx8OvRRvmABLrTvgbUQMrjlDXPP9QeNBHe8xQCQ1iV/AJ02DdbLrRleJ a/+CgisljGNzuH6Mu+5bKoKAEyEV3KAF3CIz6dJyBB5KQRY6Rk5AZMhWSQAhkJke ICBh+ITIBWYCsm+NDF+RuYutXhtstxvbewRHmwg4KnF2ouOTtQ2ypV+N2Z9JLNQ8 I25+6YB+1WDuDKYa87MPzbac6DX5IyzIPKiGsvLBngMiUcpfSDj6mgJTS4DkTwSM O+JYL5v8x7TIOmxKLGUfXXnvA+aiZ29/nrlLrZY8QoKLvHvpAxOz/SjUhDZa02IC twXso6DreRFxb4DyflTj =BizJ -----END PGP SIGNATURE-----

2 4

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes
by Stefan Dösinger Oct. 1, 2015

Oct. 1, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent > *device_parent, void *container_parent, - struct > wined3d_volume *volume, void **parent, const struct > wined3d_parent_ops **parent_ops); + HRESULT (__cdecl > *volume_created)(struct wined3d_device_parent *device_parent, + > struct wined3d_texture *texture, unsigned int sub_resource_idx, + > void **parent, const struct wined3d_parent_ops **parent_ops); Is there a reason why you're passing the wined3d_texture container instead of the container parent? It doesn't matter too much because you can either do wined3d_resource_get_parent or d3d*_texture->wined3d_texture, but I think it is a needless change. It seems the patch is bigger than it needs to be. You could just add unsigned int sub_resource_idx and keep the rest in place. Through struct d3d8_texture *texture inside struct d3d8_volume you already have access to the wined3d texture. With the addition of the sub resource idx you can migrate the volume methods one by one, and in the last patch that removes access to wined3d_volume drop struct wined3d_volume *volume from the callback. For surfaces in d3d8 and d3d9 you have to make sure you're always creating a d3d8/9_texture struct for plain surfaces, but this is something you can change internally in d3d8/9. It doesn't matter too much for this patch because the volume API is pretty simple, but the next patch is pretty complicated because it changes all the stuff at once. It'll be terrible to bisect / fix if there are regressions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr 1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2 nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO 2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki otAB34aWZl2+f/socndA =6ndo -----END PGP SIGNATURE-----

3 4

opengl32: it does not compile well in CYGWIN and MINGW
by carlo.bramix＠libero.it Oct. 1, 2015

Oct. 1, 2015

Hello, I'm writing here for asking a suggestion about a patch that I have sent one month ago. The fix attached in this email: https://www.winehq.org/pipermail/wine-patches/2015-August/141811.html is required because, when compiling opengl32 on Windows (CYGWIN or MINGW), the compiler complains that the exported functions are redeclared without dllimport attribute, while they should be declared with dllexport from beginning. This error can be fixed by adding the definition of _GDI32_ so that WINGDIAPI macro is declared correctly. This fix already exists for example in /dlls/gdi32/Makefile.in as you can see here: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/Makefile.in I hope that it could be committed because perhaps it does not make difference on platforms without dllexport/dllimport attribute support, but it does on real Windows. Thank you. Sincerely, Carlo

2 1

Wined3d wireframe rendering
by Bruno Jesus Oct. 1, 2015

Oct. 1, 2015

Hi all, I know it may sound idiot as I have zero knowledge on 3d graphics but is it possible to make wined3d to not add textures to things resulting in a sort of wireframe renderer? The long and uninteresting background: I used to play a game called X-moto in 300Mhz Celeron Linux computer, in its standard rendering mode it was impossible to play the game due to low fps, but it had an awesome wireframe mode that played smoothly. So if this could be achieved globally by wined3d we could play new games on old computers (my overly noob conclusion about all this). Thanks in advance for any reply, Bruno

5 9

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2) (resend)
by Marvin Sept. 30, 2015

Sept. 30, 2015

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=16918 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

libosmesa bitness
by André Hentschel Sept. 30, 2015

Sept. 30, 2015

Hi, Does someone can tell which version of libosmesa Wine needs? You can build libosmesa for 8, 16 or 32 channel bits puk suspects we need the 42 bits version ;) 8 is the default and it seems to me we want that, so can someone confirm that?

1 0

Re: [PATCH] usp10/tests: fix some tests on Hebrew and Arabic locales
by Marvin Sept. 30, 2015

Sept. 30, 2015

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=16916 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly
by Nikolay Sivov Sept. 30, 2015

Sept. 30, 2015

On 30.09.2015 19:04, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > - status_c = pDeleteSecurityContext( &client.ctxt ); > - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + if (client.ctxt.dwLower || client.ctxt.dwUpper) > + { > + status_c = pDeleteSecurityContext( &client.ctxt ); > + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + } Why is this a problem only on macos?

2 1

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder
by Nikolay Sivov Sept. 30, 2015

Sept. 30, 2015

On 30.09.2015 18:54, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/windowscodecs/tests/pngformat.c | 4 ++++ > 1 file changed, 4 insertions(+) > If this is about fixing macos failures, Vincent pointed out that there was a decision at some point to fix broken builds and not to workaround that in test code.

3 2

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.
by Ken Thomases Sept. 30, 2015

Sept. 30, 2015

On Sep 30, 2015, at 2:53 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > dlls/user32/driver.c | 16 ++++++++++++++-- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 1 + > dlls/winex11.drv/window.c | 29 +++++++++++++++++++++++++++++ > dlls/winex11.drv/winex11.drv.spec | 1 + > dlls/winex11.drv/x11drv.h | 1 + > dlls/winex11.drv/x11drv_main.c | 1 + > 7 files changed, 48 insertions(+), 2 deletions(-) Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? -Ken

2 2

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)
by Piotr Caban Sept. 30, 2015

Sept. 30, 2015

Hi, On 09/07/15 16:21, YongHao Hu wrote: > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ > +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* err_code, enum file_type* type) > +{ > + HANDLE handle; > + WIN32_FIND_DATAA data; > + char temppath[MAX_PATH]; > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); > + strcpy(temppath, dest); > + strcat(temppath, "\\*.*"); Is native limiting the path to MAX_PATH characters? What happens if longer path is passed? > + handle = FindFirstFileA(temppath, &data); > + if(handle == INVALID_HANDLE_VALUE) { > + if(GetLastError() == ERROR_PATH_NOT_FOUND) > + *err_code = ERROR_BAD_PATHNAME; > + else > + *err_code = GetLastError(); This doesn't look right. Probably some other function is returning different error on windows and on wine (or different function is used internally). Anyway I don't think we need to be compatible here (at least as long as there's no application that depends on it). > + while(!strcmp(data.cFileName, ".") || !strcmp(data.cFileName, "..")) { > + if(!FindNextFileA(handle, &data)) { > + *err_code = ERROR_SUCCESS; > + *type = status_unknown; > + return NULL; You're leaking handle here. Thanks, Piotr

2 2

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.
by Marvin Sept. 30, 2015

Sept. 30, 2015

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=16898 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban Sept. 29, 2015

Sept. 29, 2015

On 09/21/15 15:08, Martin Storsjo wrote: > if(d>MSVCRT_UI64_MAX/10 || hlp<d) { Please also update overflow checking rules (use base instead of 10). > +static void test_strtod(void) > +{ > + test_strtod_str("infinity", INFINITY, 8); > + test_strtod_str("INFINITY", INFINITY, 8); > + test_strtod_str("InFiNiTy", INFINITY, 8); > + test_strtod_str("INF", INFINITY, 3); > + test_strtod_str("-inf", -INFINITY, 4); > + test_strtod_str("inf42", INFINITY, 3); > + test_strtod_str("inffoo", INFINITY, 3); > + test_strtod_str("infini", INFINITY, 3); > + > + test_strtod_str("NAN", NAN, 3); > + test_strtod_str("nan", NAN, 3); > + test_strtod_str("NaN", NAN, 3); > + > + test_strtod_str("0x42", 66, 4); > + test_strtod_str("0X42", 66, 4); > + test_strtod_str("-0x42", -66, 5); > + test_strtod_str("0x1p1", 2, 5); > + test_strtod_str("0x1P1", 2, 5); > + test_strtod_str("0x1p+1", 2, 6); > + test_strtod_str("0x2p-1", 1, 6); > + test_strtod_str("0xA", 10, 3); > + test_strtod_str("0xa", 10, 3); > + test_strtod_str("0xABCDEF", 11259375, 8); > + test_strtod_str("0Xabcdef", 11259375, 8); > + > + test_strtod_str("0x1.1", 1.0625, 5); > + test_strtod_str("0x1.1p1", 2.125, 7); Could you please also add few more tests, like: test_strtod_str("0x1.A", ...); /*to show that part after decimal point is correctly handling hexadecimal digits */ test_strtod_str("0x1p1a", ...); /* to show that exponential part is not handling hexadecimal digits */ Thanks, Piotr

2 1

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.
by Nikolay Sivov Sept. 29, 2015

Sept. 29, 2015

On 29.09.2015 10:27, Ken Thomases wrote: > If the client requests a bold typeface of a font which doesn't actually provide > a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes > italic by apply a shear transform. > > These techniques work passably when antialiasing is in effect. However, when > antialiasing is disabled at small sizes by the font's GASP table, the results > are horrible. The glyphs have many spurs or appear furry. > > On the theory that fonts disable antialiasing via the GASP table at small sizes > because hinting should produce pixel-perfect results and that that rationale is > voided by the application of procedural bolding or italicizing, we ignore the > GASP table and always antialias for fake bold or italic fonts. Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself. > > There is a new registry setting to disable this and revert to the previous > behavior: > > [HKEY_CURRENT_USER\Software\Wine\Fonts] > "AntialiasFakeBoldOrItalic"="n" What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com>

2 2

Migrating away from Sourceforge
by Austin English Sept. 29, 2015

Sept. 29, 2015

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.
by Marvin Sept. 28, 2015

Sept. 28, 2015

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=16895 Your paranoid android. === w1064 (32 bit device) === device.c:2612: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2617: Test failed: The focus window is active. device.c:2625: Test failed: Got unexpected hr 0x88760869. device.c:2631: Test failed: Got unexpect screen size 1152x870. device.c:2646: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=2. device.c:2655: Test failed: Got unexpect screen size 1152x870. device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2676: Test failed: Got unexpect width 1152. device.c:2677: Test failed: Got unexpect height 864.

1 0

Re: ieframe: add a better toolbar bitmap
by Jacek Caban Sept. 28, 2015

Sept. 28, 2015

Hi Jared, On 09/26/15 20:02, Jared Smudde wrote: > --- > dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes > 1 files changed, 0 insertions(+), 0 deletions(-) That file is generated from ietoolbar.svg, so it's the SVG file that should be changed. You may enable generating those file in your build with --enable-maintainer-mode configure option. Thanks, Jacek

2 1

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.
by Michael Müller Sept. 28, 2015

Sept. 28, 2015

Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: > From: Michael Müller <michael(a)fds-team.de> > > For https://bugs.winehq.org/show_bug.cgi?id=34558 > > Depending on the compiler optimization flags there is still no guarantee that > everything will fit into the available stack space, no matter if its declared > as static or not. As suspected the idea does not work for all optimization levels. At least GCC merges the content of the functions when using -O2 and therefore reintroduces the problem - even __attribute__ ((noinline)) is not sufficient. As most distributions compile Wine with -02, I would suggest to ignore the patch for now. Maybe we can come up with a more general solution.

2 1

Re: msadpcm32.acm: Stop converting data instead of crashing
by Andrew Eikum Sept. 28, 2015

Sept. 28, 2015

On Sun, Sep 27, 2015 at 12:42:42AM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > Tomb Raider 3 uses a single archive with all wav files inside, when > playing some specific sounds it passes incorrect lengths of data that > reach the next wav file header. This causes an assert in the code that > is now gracefully handled. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=21000 > diff --git a/dlls/msadp32.acm/msadp32.c b/dlls/msadp32.acm/msadp32.c > index 2c61575..0924163 100644 > --- a/dlls/msadp32.acm/msadp32.c > +++ b/dlls/msadp32.acm/msadp32.c > @@ -249,9 +249,17 @@ static void cvtSSms16K(const ACMDRVSTREAMINSTANCE *adsi, > { > const unsigned char* in_src = src; > > - assert(*src <= 6); > + /* Catch a problem from Tomb Raider III (bug 21000) where it passes > + * invalid data after a valid sequence of blocks */ > + if (*src > 6 || *(src + 1) > 6) > + { > + /* Recalculate the amount of used output buffer. We are not changing > + * nsrc, let's assume the bad data was parsed */ > + *ndst -= nblock * nsamp_blk * adsi->pwfxDst->nBlockAlign; > + ERR("Invalid ADPCM data, stopping conversion\n"); Looks reasonable, thanks. I think you should change that message to a WARN. Audio methods are often called thousands of times per second, so spamming an ERR can be very obnoxious. Andrew

3 3

Re: [PATCH] opengl32: use thunks for glDebugMessageCallback
by Matteo Bruni Sept. 28, 2015

Sept. 28, 2015

2015-09-27 21:00 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > Also regenerated opengl files, to exclude the glDebugMessageCallback functions. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/opengl32/make_opengl | 6 + > dlls/opengl32/opengl_ext.c | 343 +++++++++++++++++++++++++++++++++++++++---- > dlls/opengl32/opengl_ext.h | 5 + > dlls/opengl32/opengl_norm.c | 90 +++++++++++- > dlls/opengl32/tests/opengl.c | 96 +++++++++++- > dlls/opengl32/wgl.c | 52 +++++++ > include/wine/wgl.h | 100 +++++++++++++ > include/wine/wgl_driver.h | 47 +++++- > include/winternl.h | 5 +- > 9 files changed, 708 insertions(+), 36 deletions(-) > diff --git a/include/winternl.h b/include/winternl.h > index 2fe2a2d..8e85eb4 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -341,7 +341,10 @@ typedef struct _TEB > PVOID GdiThreadLocaleInfo; /* 6fc/0870 */ > ULONG UserReserved[5]; /* 700/0878 */ > PVOID glDispachTable[280]; /* 714/0890 */ > - PVOID glReserved1[26]; /* b74/1150 */ > + PVOID glDebugCallback; /* b74/1150 */ > + PVOID glDebugCallbackAMD; /* b78/1158 */ > + PVOID glDebugCallbackARB; /* b7c/1160 */ > + PVOID glReserved1[23]; /* b80/1164 */ > PVOID glReserved2; /* bdc/1220 */ > PVOID glSectionInfo; /* be0/1228 */ > PVOID glSection; /* be4/1230 */ The callbacks should be per-GL context, that's why I mentioned the struct opengl_context as a possibly suitable place to store the application-provided callbacks. The test should actually test something. You probably need to create a debug context (the extension specifies that "For performance reasons it is recommended, but not required, that implementations restrict supporting this extension only to contexts created using the debug flag as provided by WGL_create_context or GLX_create_context") and enable the DEBUG_OUTPUT_SYNCHRONOUS_ARB flag. Also it would be definitely nicer if the test is implemented in a separate function, instead of stuffing it into START_TEST(opengl). For the records, you can find the relevant extension spec at https://www.opengl.org/registry/specs/ARB/debug_output.txt. GL_KHR_debug specifies some further related bits but I think you can mostly ignore that for this patch.

1 0

How to add the Signed-off-by field in the git patch
by Dmitry Timoshkov Sept. 28, 2015

Sept. 28, 2015

Hi all, since I personally asked that question and investigated a bit the subject, here is some information that could be probably useful to someone else: http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… http://git-scm.com/docs/git-format-patch (CONFIGURATION section) Personally I've chosen to add [format] signOff = true to git.config file. -- Dmitry.

5 4

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values
by Marvin Sept. 28, 2015

Sept. 28, 2015

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=16891 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

2 1

Help building a DLL at run-time
by Hugh McMaster Sept. 28, 2015

Sept. 28, 2015

Does anyone know a way to build DLLs at runtime? Testing regsvr32.exe requires one or more DLLs, so I compiled a test DLL for use with the tests. Apparently, the tests should be self-contained, meaning the DLL is produced at run-time. I'm assuming this is done for anyone using the winetest program. I thought I could write the DLL manually, using IMAGE_NT_HEADERS and other structures. Unfortunately, I'm unable to write the required functions to the file. For one thing, functions have no size. Another method would be to build the DLL and use the linker to convert the DLL to an object file, link the binary in, and then output it at run-time. Alternatively, I can leave the tests out of the source tree. Opinions?

1 0

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view
by Nikolay Sivov Sept. 27, 2015

Sept. 27, 2015

On 26.09.2015 22:11, Barrett Karish wrote: > Test Program: https://bugs.winehq.org/attachment.cgi?id=35473 > --- By test I meant a test integrated into wine tests, in this case it should go to comctl32/tests/listview.c. Test should basically create Listview of particular style, enable item text edit control and check its style. I think I tried that long time ago and test didn't confirm what appeared to be obvious fix, but I might be wrong.

1 0

Re: user32/tests: Allow tracing in menu test
by Dmitry Timoshkov Sept. 26, 2015

Sept. 26, 2015

André Hentschel <nerv(a)dawncrow.de> wrote: > + if (winetest_debug > 1) > + trace("item #%u: fType %04x, fState %04x, wID %u, hSubMenu %p\n", > + i, mii.fType, mii.fState, mii.wID, mii.hSubMenu); Please use 4 spaces for indentation after 'if ()', not 8. Also, what's the reason of this patch? There are several other similar disabled debug traces in that file, anything special about this one? And I'd suggest to simply replace if (0) by if (1) in the personal build if you really need to see the traces. -- Dmitry.

4 4

prelink (needed to compile wine) missing on Fedora 23
by Zhenbo Li Sept. 26, 2015

Sept. 26, 2015

Hello, I installed Fedora 23 Alpha to my computer, and tried to compile wine today. After running "./configure", I got this in my terminal configure: WARNING: prelink not found, base address of core dlls won't be set correctly. The reason is that prelink has been obsoleted since Fedora 23[1] There is a successful build for wine on Fedora23[2], and it seems that that package has been affected by missing prelink too.[3] Is this a critical problem? Should I ignore this WARNING, or try to fix it? Thank you [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… -- Have a nice day! Zhenbo Li

3 4

Re: ntdll: Fix for 64-bit builds (at least on OSX)
by Charles Davis Sept. 25, 2015

Sept. 25, 2015

Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) Chip

2 2

Re: [PATCH] usp10/tests: Catch case where enumerated font name is too long
by Marvin Sept. 25, 2015

Sept. 25, 2015

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=16855 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Dropping support for win2k in tests
by Jacek Caban Sept. 25, 2015

Sept. 25, 2015

Hi all, I mentioned the concern on WineConf already and we quickly decided to not care about win2k during WineConf test session. But there is more to that: do we want to drop win2k support in our tests. I think we do. We have extra code to handle it all over tests codebase. Those are mostly skip()s + broken()s because, well, we don't care about win2k results. And if we don't care, then what's the point to bother and do the extra work. Stefan mentioned that ddraw has differences between win2k and newer version. That's true for other libraries as well. I don't think that's enough for the reason to keep win2k supported. A real case where test results on win2k was useful lately would be. Do we have an example of a real (not theoretical) use of win2k tests in recent Wine development? Thanks, Jacek

1 0

Wine and Buildroot
by André Hentschel Sept. 25, 2015

Sept. 25, 2015

Hi, For those interested, I just add an introduction of Buildroot to our Wine-Wiki: http://wiki.winehq.org/Buildroot See also my slides from WineConf2015: http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=otherar… And a short WWN article from March 2015: https://www.winehq.org/wwn/387#Wine%20in%20Buildroot

2 1

Wine Stable/Release Changes
by Michael Stefaniuc Sept. 25, 2015

Sept. 25, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon. Release Process Changes - ----------------------- - - Switch to time based releases. - - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September. - - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze. - - The stable release will be supported in bugzilla. - - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks. - - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. Discussion - ---------- The discussion was done based on slide 9 of Alexandre's keynote http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks. The discussion quickly geared to the changes accepted from above with the focus on implementation details: - - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise. - - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC. - - Nobody else volunteered during the discussion for the stable maintainer role. For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal. (*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+ Z9VxsMM7J1/wdpAyC8DPJaE= =zhZ8 -----END PGP SIGNATURE-----

6 6

Re: [PATCH] [comctl32] Fix sizing of edit window for listview icon view
by Nikolay Sivov Sept. 25, 2015

Sept. 25, 2015

On 25.09.2015 4:33, Barrett Karish wrote: > --- > dlls/comctl32/listview.c | 42 +++++++++++++++++++++++++----------------- > 1 file changed, 25 insertions(+), 17 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index e3fad51..ba227a7 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -6048,12 +6048,15 @@ static LRESULT CALLBACK EditLblWndProcA(HWND hwnd, UINT uMsg, WPARAM wParam, LPA > */ > static HWND CreateEditLabelT(LISTVIEW_INFO *infoPtr, LPCWSTR text, BOOL isW) > { > - static const DWORD style = WS_CHILDWINDOW|WS_CLIPSIBLINGS|ES_LEFT|ES_AUTOHSCROLL|WS_BORDER|WS_VISIBLE; > - HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); > + DWORD style = WS_CHILDWINDOW | WS_CLIPSIBLINGS | ES_LEFT | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE | ES_MULTILINE; > + HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); Hi, Barrett. Please use existing 4 space formatting and avoid unnecessary changes. > HWND hedit; > > TRACE("(%p, text=%s, isW=%d)\n", infoPtr, debugtext_t(text, isW), isW); > > + if (infoPtr->uView == LV_VIEW_ICON) > + style |= ES_CENTER; We need a test that proves that Edit gets centered style on icon view. > + > /* window will be resized and positioned after LVN_BEGINLABELEDIT */ > if (isW) > hedit = CreateWindowW(WC_EDITW, text, style, 0, 0, 0, 0, infoPtr->hwndSelf, 0, hinst, 0); > @@ -6093,7 +6096,6 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > HFONT hOldFont = NULL; > TEXTMETRICW tm; > RECT rect; > - SIZE sz; > HDC hdc; > > TRACE("(nItem=%d, isW=%d)\n", nItem, isW); > @@ -6152,24 +6154,30 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > GetWindowTextW(infoPtr->hwndEdit, disptextW, DISP_TEXT_SIZE); > TRACE("edit box text=%s\n", debugstr_w(disptextW)); > > - /* get string length in pixels */ > - GetTextExtentPoint32W(hdc, disptextW, lstrlenW(disptextW), &sz); > + DrawTextW(hdc, disptextW, -1, &rect, infoPtr->uView == LV_VIEW_ICON ? LV_FL_DT_FLAGS : LV_SL_DT_FLAGS | DT_CALCRECT); > > - /* add extra spacing for the next character */ > - GetTextMetricsW(hdc, &tm); > - sz.cx += tm.tmMaxCharWidth * 2; > + if (infoPtr->uView != LV_VIEW_ICON) > + { > + /* add extra spacing for the next character */ > + GetTextMetricsW(hdc, &tm); > + rect.right += tm.tmMaxCharWidth; > + rect.left -= 2; > + rect.top -= 1; > + rect.bottom += 2; > + } > + else > + { > + rect.bottom += 3; > + } > This should ideally use some font metrics instead of hardcoded magic, but I know we do it this way already. > - if (infoPtr->hFont) > - SelectObject(hdc, hOldFont); > + if (infoPtr->hFont) > + SelectObject(hdc, hOldFont); > > - ReleaseDC(infoPtr->hwndSelf, hdc); > + ReleaseDC(infoPtr->hwndSelf, hdc); > > - sz.cy = rect.bottom - rect.top + 2; > - rect.left -= 2; > - rect.top -= 1; > - TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, sz.cx, sz.cy); > - MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, sz.cx, sz.cy, FALSE); > - ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > + TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top); > + MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, FALSE); > + ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > SetFocus(infoPtr->hwndEdit); > SendMessageW(infoPtr->hwndEdit, EM_SETSEL, 0, -1); > return infoPtr->hwndEdit; >

1 0

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add tests.
by Marvin Sept. 23, 2015

Sept. 23, 2015

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=16838 Your paranoid android. === w1064 (32 bit thread) === thread.c:1087: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

2 1

Inconsistent argument type declaration in dinput.h: WriteEffectToFile()
by Elias Vanderstuyft Sept. 23, 2015

Sept. 23, 2015

Hi everyone, The docs of IDirectInputDevice8::WriteEffectToFile() declare the third argument as LPCDIFILEEFFECT rgDiFileEft: https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… This is inconsistent with Microsoft's "dinput.h" file, they declare it as LPDIFILEEFFECT (thus, no "const"): ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… Wine's "dinput.h" follows the same mistake as Microsoft's: https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 Is there a particular reason for this? Best regards, Elias

3 4

Re: [PATCH 11/12] ddraw: cache active DCs
by Stefan Dösinger Sept. 23, 2015

Sept. 23, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > + sub_resource = wined3d_texture_get_sub_resource(surface_impl->wined3d_texture, surface_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > + if (FAILED(hr = wined3d_surface_getdc(wined3d_surface, &surface_dc))) I expect the getdc call to fail because the application already called GetDC. I think you can just add a HDC dc field to struct wined3d_surface and compare it to the dc passed to GetSurfaceFromDC. > + if (!hdc) > { > - TRACE("No surface found for dc %p.\n", hdc); > *Surface = NULL; > return DDERR_NOTFOUND; > } Personally I prefer to write a WARN if we return failure to the application. Note that this is just my personal choice though, the existing code is not consistent here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAnJqAAoJEN0/YqbEcdMwGTwP/3zCYpjVZYY0M3Mafxs7j3Dq WPDkiiRzshspPTLIx3kurk7lRd2JXa8GbXZ8bOjx6bOz9wZC1wtejQEwLGhENOgz bzX9tyYT2FdRXVXM0V0bEOAvd0rivgIeE0xcPWYZg289bHTx4bw/3Ql+uSsUY/8L lamfMT5xOKhZmr6T5mI3MpHjUnbIUtBrOHvAggNexfl+RcvlFgmsl1MqajBHO+O7 W1ws4F35MzbXiEKUNEX3yH1cr3WRW+9xcAi89YYTnOTIpYsJHGOOOXoAeF1G2W2c dvj131zQRdlIknLxxZPZXSQJJffdiDdnuJ6xeMfJ1f9SdH0PNPKhX08wH2Wz+Zr8 77zY0vK2iqnAl0HUcq4WrL4TLh60VU2UeyhAy8vqYjso60OvANAmYBljgO5Z4oI/ mypsa1sq11Vrp+DAIaxFyj15whgdV2tE/NvC4Kapx4OK8DTQ+9xHGJoED9AX/E+/ OvynPYd/r/WPYyIYJpSv/YOAN4OAusNpY7i4nlXu8RbphTFcNZTrtLU/EUJCfI6T LaEx3TX9/Dg4BNrwY72cPleLKSZbGK1/59q0XWbH5Oft8HS48jL7IEJkNsNtJpqf GOJr/EotzHpJC2QGKOZ19NhgcCb22GbF8jCniLMVUSj/DelDzKOJs+5VaRiFcNqo AVr5Gv4UMzGlq7CjMo4v =UoFu -----END PGP SIGNATURE-----

1 0

Re: [PATCH 11/12] ddraw: cache active DCs
by Jonas Maebe Sept. 23, 2015

Sept. 23, 2015

Riccardo Bortolato wrote on Wed, 23 Sep 2015: Disclaimer: I'm everything but an expert on Wine internals, so I'm just asking in case I'm not missing something obvious. > - surface_impl = wined3d_surface_get_parent(wined3d_surface); > - *Surface = &surface_impl->IDirectDrawSurface7_iface; > - IDirectDrawSurface7_AddRef(*Surface); > - TRACE("Returning surface %p.\n", Surface); > - return DD_OK; > + wined3d_mutex_lock(); > + LIST_FOR_EACH_ENTRY(surface_impl, &ddraw->active_dcs, struct > ddraw_surface, active_dcs_entry) Here you get a mutex lock before iterating over the active_dcs. > + if (surface_dc == hdc) > + { > + wined3d_mutex_unlock(); > + *Surface = &surface_impl->IDirectDrawSurface7_iface; > + IDirectDrawSurface7_AddRef(*Surface); > + TRACE("Returning surface %p.\n", Surface); > + return DD_OK; > + } Here you free the lock before increasing the reference count. At first sight, it would seem that you either don't need the lock while iterating, or that you should increase the reference count before releasing the lock in order to avoid races (unless the lock is for a completely unrelated reason) > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -2176,7 +2176,9 @@ static HRESULT WINAPI > ddraw_surface7_GetDC(IDirectDrawSurface7 *iface, HDC *hdc) > if(hdc) *hdc = NULL; > return DDERR_INVALIDPARAMS; > > - default: return hr; > + default: > + list_add_head(&surface->ddraw->active_dcs, > &surface->active_dcs_entry); Here you add something to the actives_dcs list without locking, so this can race with the iterating (unless this is implicitly synchronised in another way I'm not aware of). > @@ -2246,6 +2248,8 @@ static HRESULT WINAPI > ddraw_surface7_ReleaseDC(IDirectDrawSurface7 *iface, HDC h > hr = ddraw_surface_update_frontbuffer(surface, NULL, FALSE); > wined3d_mutex_unlock(); > > + list_remove(&surface->active_dcs_entry); > + > return hr; > } Similarly, here you remove an item after releasing the lock, so it can race with both adding and iterating (same caveat). Jonas

2 1

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces
by Stefan Dösinger Sept. 23, 2015

Sept. 23, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > wined3d_mutex_lock(); > + sub_resource = wined3d_texture_get_sub_resource(bitmap_impl->wined3d_texture, bitmap_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > hr = wined3d_device_set_cursor_properties(device->wined3d_device, > - hotspot_x, hotspot_y, bitmap_impl->wined3d_surface); > + hotspot_x, hotspot_y, wined3d_surface); > wined3d_mutex_unlock(); You may want to consider changing wined3d_device_set_cursor_properties to accept a wined3d_texture instead. Keep in mind though that this would be a bit of a side quest, as you'll have to find out if native accepts surfaces that are part of textures or just stand-alone surfaces created by CreateImageSurface. If it is the latter (which I suspect it is) then wined3d_texture alone is OK. Otherwise you need texture + idx. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmlwAAoJEN0/YqbEcdMwGlkP/RfRVsceuPRGgVE0yJvhV26U ci6CDlrj4Lb2mFcH3IVlJKuJEOcT2TLrcx2hT3H2+0OjDBvAIJyLhzjxABaZsg0N OU4TJCvLfPiieF0npy7EBpUoe+E8a4046DRnLJsooco1Cp+Fk2LZO4B1OjMoaexl FaO9zoAO+3KlTNVwRKX65KnOsZB7PtP0soCS9Gsmvx1gwwVe42uQ8B5pSgQQzcgW UablqGdE0NnUGN2Bcj6vxPdW14FEaWC7Mp8fBl8olLO/FdlEoehzUMO7bPJNgGr2 wePB12qwmTfizcQ+Nmd5/HAGZMsn4vgfxu+kQSb0iaWxdgRtqKztlkLzAOFvGDTS x+yZ2pWTcNp41MzZI9yxRStI5eLq5ZBQ9vY64A85W3Zwj/wTb7eR6A/qWveOUYsG 6EtQ9F0pQ43hotiE9a/8AdvTlrwQ+lcK6W01Ngg2mh9xnZ8pcD1Zqugy7RYDoHiQ u+yd0BxvV3SjmjA0h4qZRVUh/ct5UMPCp6gJdHJFtSsKfoRAq96BzI3g3AFGH+Xv u0Tkjq7QbhtLPxdjdc8A61SbwRFqygrj3XsZi0ji6qar5tjW58u0PdRskb4NTUhu lEYUETpysaj29ktGURJ3s5/G1TKauDM9G4jx9puM8Kh0LilKshRwIsJaZf+4uHeW BBmwwFk8QMQpKffLOCie =W7On -----END PGP SIGNATURE-----

2 1

Re: kernel32: Create registry keys for available COM ports
by Austin English Sept. 22, 2015

Sept. 22, 2015

On Tue, Sep 22, 2015 at 3:14 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > dlls/kernel32/kernel_private.h | 3 +++ > dlls/kernel32/oldconfig.c | 42 +++++++++++++++++++++++++++++++++++++++--- > dlls/kernel32/volume.c | 2 +- > 3 files changed, 43 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/kernel_private.h b/dlls/kernel32/kernel_private.h > index 76611d7..9f2db22 100644 > --- a/dlls/kernel32/kernel_private.h > +++ b/dlls/kernel32/kernel_private.h > @@ -107,6 +107,9 @@ extern void LOCALE_InitRegistry(void) DECLSPEC_HIDDEN; > /* oldconfig.c */ > extern void convert_old_config(void) DECLSPEC_HIDDEN; > > +/* volume.c */ > +extern char *get_dos_device_path(LPCWSTR) DECLSPEC_HIDDEN; > + > /* returns directory handle for named objects */ > extern HANDLE get_BaseNamedObjects_handle(void) DECLSPEC_HIDDEN; > > diff --git a/dlls/kernel32/oldconfig.c b/dlls/kernel32/oldconfig.c > index 2c8bc18..b7f6b97 100644 > --- a/dlls/kernel32/oldconfig.c > +++ b/dlls/kernel32/oldconfig.c > @@ -264,8 +264,8 @@ static int SCSI_getprocentry( FILE * procfile, struct LinuxProcScsiDevice * dev > } > > > -/* create the hardware registry branch */ > -static void create_hardware_branch(void) > +/* create the scsi registry branch */ > +static void create_scsi_branch(void) > { > /* The following mostly will work on Linux, but should not cause > * problems on other systems. */ > @@ -389,6 +389,41 @@ static void create_hardware_branch(void) > } > > > +/* create SERIALCOMM branch */ > +void create_serialcomm_branch(void) > +{ > + static WCHAR comW[] = {'C','O','M','1',0}; > + UNICODE_STRING nameU; > + DWORD disp; > + HANDLE key; > + int i; > + > + /* Ensure there is a SERIALCOMM key */ > + if (create_key( 0, "Machine\\HARDWARE\\DEVICEMAP\\SERIALCOMM", &key, &disp )) return; > + > + for (i = 1; i <= 9; i++) > + { > + char *link; > + int ret; > + > + comW[3] = 0x30 + i; > + link = get_dos_device_path( comW ); > + ret = access( link, R_OK | W_OK ); > + > + RtlCreateUnicodeString( &nameU, comW ); > + if (ret) > + NtDeleteValueKey( key, &nameU ); > + else > + NtSetValueKey( key, &nameU, 0, REG_SZ, (BYTE*)comW, sizeof(comW) ); > + RtlFreeUnicodeString( &nameU ); > + > + HeapFree(GetProcessHeap(), 0, link); > + } > + > + NtClose(key); > +} > + > + > /*********************************************************************** > * convert_old_config > */ > @@ -400,5 +435,6 @@ void convert_old_config(void) > /* create some hardware keys (FIXME: should not be done here) */ > if (create_key( 0, "Machine\\HARDWARE", &key, &disp )) return; > NtClose( key ); > - if (disp != REG_OPENED_EXISTING_KEY) create_hardware_branch(); > + if (disp != REG_OPENED_EXISTING_KEY) create_scsi_branch(); > + create_serialcomm_branch(); > } > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 7a1dc11..43fbb7e 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -99,7 +99,7 @@ static char *read_symlink( const char *path ) > } > > /* get the path of a dos device symlink in the $WINEPREFIX/dosdevices directory */ > -static char *get_dos_device_path( LPCWSTR name ) > +char *get_dos_device_path( LPCWSTR name ) > { > const char *config_dir = wine_get_config_dir(); > char *buffer, *dev; > -- > 1.9.1 Hi Andre, You forgot to sign off on this patch ;) -- -Austin

1 0

Re: msi: Set the PrimaryVolumeSpaceRequired and PrimaryVolumeSpaceRemaining properties.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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=16820 Your paranoid android. === w7u (32 bit install) === The test timed out === wvistau64 (64 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [2/2] wininet/tests: Fix a couple of test failures.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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=16819 Your paranoid android. === w2000pro (32 bit http) === http.c:2400: Test failed: InternetReadFile failed 12030 http.c:2401: Test failed: count was wrong === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [1/2] wininet/tests: Never use a proxy for connections to localhost.
by Marvin Sept. 22, 2015

Sept. 22, 2015

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=16818 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: How to add the Signed-off-by field in the git patch
by Hin-Tak Leung Sept. 22, 2015

Sept. 22, 2015

You don't need to edit git's config by hand - 'git config --global ... ' can do that for you. read the documentation for git-config, and particularly the --global option. I also have colorised diff and a few other useful thing configured. ------------------------------ On Tue, Sep 22, 2015 3:21 PM BST Aaryaman Vasishta wrote: >Hi Dimitry, > >Thanks! this will definitely help if this info is added to the wiki too. >Though it seems to be down right now. There's a discussion going on about >it on IRC right now. > >Cheers, >Aaryaman > >On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Hi all, >> >> since I personally asked that question and investigated a bit the subject, >> here is some information that could be probably useful to someone else: >> >> >> http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… >> >> http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… >> >> http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… >> http://git-scm.com/docs/git-format-patch (CONFIGURATION section) >> >> Personally I've chosen to add >> [format] >> signOff = true >> to git.config file. >> >> -- >> Dmitry. >> >> >>

1 0

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const
by Nikolay Sivov Sept. 22, 2015

Sept. 22, 2015

On 22.09.2015 0:06, Marcus Meissner wrote: > Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dinput/device.c | 4 ++-- > dlls/dinput/device_private.h | 4 ++-- > include/dinput.h | 8 ++++---- > 3 files changed, 8 insertions(+), 8 deletions(-) > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case?

4 3

No release this week
by Alexandre Julliard Sept. 21, 2015

Sept. 21, 2015

Hey guys, Because of WineConf, it looks like I won't be able to make a release today. And since I'll be taking some vacation next week, I plan to release 1.7.52 on Friday two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Marvin Sept. 21, 2015

Sept. 21, 2015

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=16808 Your paranoid android. === w2003std (32 bit string) === Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 === w7u (32 bit string) === Failure running script in VM: timed out waiting for the child process

2 1

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban Sept. 21, 2015

Sept. 21, 2015

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

2 1

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer Sept. 20, 2015

Sept. 20, 2015

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer Sept. 20, 2015

Sept. 20, 2015

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: psapi/tests: Don't check for exact value (try 7)
by Marvin Sept. 20, 2015

Sept. 20, 2015

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=16805 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 No test summary line found === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 No test summary line found

2 1

Wine test update
by Jeremy White Sept. 20, 2015

Sept. 20, 2015

We reviewed my list of interesting test bot vm failures: https://www.winehq.org/~jwhite/latest.html and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. The following glorious people volunteered to work on one or more of these issues: Andrew, Alexandre, Aric, Francois, Huw, Stefan, Piotr, Jacek, Qian, Hans, and Sebastian, and I've emailed Bruno to ask him to look into one. Cheers, Jeremy

2 1

Winsock 2
by Christopher Harrington Sept. 20, 2015

Sept. 20, 2015

I'm looking at trying to implement some of the Winsock 2 stubs, namely WSALookupServiceBegin/Next/End. I'm probably only going to implement enough of it that my target binary will stop bailing out with "out of memory". I suspect the app is using it to resolve DNS... Am I stepping on anyone's toes? If not, can someone point me at the right place to look for where wine is currently doing DNS lookups so I can reuse that non-broken code? Thank you in advance. -Chris Harrington

3 4

Changes for Wine on Debian
by Kyle Auble Sept. 20, 2015

Sept. 20, 2015

Hi everyone, I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now. Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons. When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself. - Kyle

4 8

RFC - oleaut32: Cope with invalid icon data
by Bruno Jesus Sept. 19, 2015

Sept. 19, 2015

While testing bug [1] I noticed that invalid data is sent to OLEPictureImpl_LoadIcon. This patch is meant to resist these kind of issues and makes the game goes on a little further until other crash. I'm sending this as RFC because I don't know then icon structure but my tests seem very straight forward from what I can guess from the function. [1] https://bugs.winehq.org/show_bug.cgi?id=21012 Thanks in advance and best regards, Bruno

1 0

Re: wined3d: TRACE fixes. (try 2)
by Henri Verbeet Sept. 18, 2015

Sept. 18, 2015

On 16 September 2015 at 14:39, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > @@ -1243,7 +1243,7 @@ static int context_choose_pixel_format(const struct wined3d_device *device, HDC > unsigned int cfg_count = device->adapter->cfg_count; > unsigned int i; > > - TRACE("device %p, dc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > + TRACE("device %p, hdc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > device, hdc, debug_d3dformat(color_format->id), debug_d3dformat(ds_format->id), > auxBuffers, findCompatible); This isn't wrong, but I'd be more inclined to change the parameter to match the trace than the other way around. > @@ -157,8 +157,8 @@ HRESULT CDECL wined3d_palette_create(struct wined3d_device *device, DWORD flags, > struct wined3d_palette *object; > HRESULT hr; > > - TRACE("device %p, flags %#x, entries %p, palette %p.\n", > - device, flags, entries, palette); > + TRACE("device %p, flags %#x, entry_count %d, entries %p, palette %p.\n", > + device, flags, entry_count, entries, palette); Unsigned values should use %u instead of %d. > @@ -114,7 +114,7 @@ enum wined3d_event_query_result wined3d_event_query_finish(const struct wined3d_ > const struct wined3d_gl_info *gl_info; > enum wined3d_event_query_result ret; > > - TRACE("(%p)\n", query); > + TRACE("(%p, %p)\n", query, device); This isn't wrong per se either, but I'd prefer that as "query %p, device %p.\n" like the rest of wined3d. > @@ -1275,7 +1275,7 @@ static void shader_dump_decl_usage(const struct wined3d_shader_semantic *semanti > break; > > case WINED3D_DECL_USAGE_BLEND_INDICES: > - TRACE("blend"); > + TRACE("indices"); I'd either just leave that the way it is, or change it to "blendindices". In the latter case you'd have to change the one for WINED3D_DECL_USAGE_BLEND_WEIGHT to "blendweight", and the one for WINED3D_DECL_USAGE_TEXCOORD to "texcoord%u" as well. > @@ -2037,8 +2037,8 @@ static HRESULT shader_set_function(struct wined3d_shader *shader, const DWORD *b > unsigned int backend_version; > const struct wined3d_d3d_info *d3d_info = &shader->device->adapter->d3d_info; > > - TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u.\n", > - shader, byte_code, output_signature, float_const_count); > + TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u, type %#x, max_version %d.\n", > + shader, byte_code, output_signature, float_const_count, type, max_version); %d -> %u

1 0

Optimizing synchronization objects
by Daniel Santos Sept. 17, 2015

Sept. 17, 2015

Alexandre, First off I apologize for the size of this email, I'm trying to keep it as concise as possible. I've been experimenting with ways to optimize synchronization objects and have implemented a promising proof of concept for semaphores using glibc's nptl (posix) semaphore implementation. I posted revision 3 of this today, although I appear to have used the wrong msg id in the --in-reply-to header. :( So my goal is to eventually make similar optimizations for all synchronization objects, or at least those that have demonstrable performance problems. The basic theory of operation is that when a client sends a create_semaphore, the server creates a posix semaphore with a unique name which is passes to the client process so that it can open it locally. This allows the client to perform ReleaseSemaphore without a server call as well as WaitFor(Multiple|Single)Object(s) for cases where the wait condition can be determined to be satisfied without a server call (i.e., either bWaitAll = FALSE and a signalled semaphore is found in the handle list prior to a non-semaphore objects or bWaitAll = TRUE and all handles are signalled semaphores). For all other conditions, it uses a traditional server call. However, it has two problems: 1. It uses glibc's implementation of POSIX semaphores which uses shared memory to share them with other processes, and 2. It uses glibc's implementation of POSIX semaphores which are incompatible across 32- and 64-bit ABI processes. I have not been able to find any more flaws in a case where both program and wineserver are the same ABI. All tests pass and I've added one more (although more tests are clearly needed). Since this implementation only uses sem_trywait (and never sem_wait or sem_timedwait), we don't really even need a full-featured semaphore -- a simple 32- or 16-bit number that's accessed atomically would suffice as a replacement. Although I did plan to eventually explore having a client program block w/o calling the server, the benefit of that is minimal compared to the benefit of being able to avoid the server call for releasing a semaphore and "wait"ing when the semaphore is already available. So now I want to understand the minimum threshold of acceptability in wine for such a mechanism. We discussed this in chat and quite a bit and can I see many possibilities, each with its own particular issues. I'm listing them in order of my personal preference (most preferred first). Option 1: Simple shared memory & roll our own semaphore Similar to what glibc's NPTL semaphores are doing, except that we would only need a single integral value and not even a futex. The obvious downside is that a process can corrupt this memory and cause dysfunction of other processes who also have semaphores in that page. This could be minimized by giving every process their own page that is only shared between the server and the process unless a semaphore in that process is shared with another program, at which time the memory page could be shared with that process as well. Thus, the scope of possible corruption is limited to how far you share the object. In the worse case of memory corruption, the wineserver would either leave a thread of one of these processes hung, release one when it shouldn't be released or determine that the memory is corrupted, issue an error message, set the last error to something appropriate and return WAIT_FAILED. Option 2: System V semaphores On Linux, these are hosted in the kernel, so you can't just accidentally overwrite them. They will be slightly slower than shared memory due to the system call overhead. You probably know them better than I, but at the risk or stating the obvious, the following are their limitations. Their max value on Linux is SHRT_MAX so any request for a higher lMaximumCount would have to be clipped. There are also limits on Linux that can be adjusted by root if needed for some application, but the default is a maximum of 32000 (SEMVMX) total semaphores on the system, 128 (SEMMNI) semaphore sets and a max size of 250 (SEMMSL) semaphores per set. They are also persistent, so if the wine server crashes, they can leave behind clutter. Option 3: Move semaphores completely into the client In this scenario, the wine server can never be exposed to corrupted data. It is very fast when locking can be performed in the client, but very complicated and potentially slower for mixed locks. Calls to WaitForMultipleObjectsEx containing both semaphores and other objects (especially with bWaitAll = TRUE) may require multiple request/reply cycles to complete. The client must successfully lock the semaphores prior to the server calling satisfied on the server-side objects. Here is an optimistic use case that only requires a single request/reply cycle 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which succeeds. 3. Client passes request to server (with semaphore states) and blocks on pipe 4. Server gets value of all server-side objects and determines that the condition can be satisfied, so calls satisfied on all objects 5. Server sends response to client 6. Client wakes up and completes the wait call. Here is a slightly less optimistic case 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which fails on one semaphore. 3. Client rolls back locks on all which had succeeded. 4. Client passes request to server (with semaphore states) 5. Client blocks on the semaphore that was locked and the server pipe 6. Server updates thread status (blocking on native object) 7. Semaphore is signaled and client wakes up 8. Lock is obtained on semaphore that was previously locked 9. Client now calls trywait on remaining semaphores which again succeeds. 10. Client sends update to server and blocks on pipe 11. Server checks all server-side objects, which are all signaled, so calls satisfied on all objects 12. Server updates thread status and notifies client 13. Client wakes up and completes wait call. As you can see this can get more complicated. If the server discovers that an server object isn't signaled it will have to notify the client to rollback the locks and wait for server objects to be ready. So which of these solution is most appealing to you?

4 10

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.
by Henri Verbeet Sept. 17, 2015

Sept. 17, 2015

On 16 September 2015 at 00:02, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > This patch series fixes several places where glyph table values are > not const, preventing the compiler from placing the table in read-only > memory. > Did you verify this does what you think it does? I suspect you don't really understand const and relocations.

2 5

Prep for Wineconf - testing
by Jeremy White Sept. 17, 2015

Sept. 17, 2015

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [10/10] msvcirt: Implement strstreambuf::seekoff (resend)
by Piotr Caban Sept. 17, 2015

Sept. 17, 2015

Hi, On 09/17/15 11:06, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(strstreambuf_seekoff, 16) > streampos __thiscall strstreambuf_seekoff(strstreambuf *this, streamoff offset, ios_seek_dir dir, int mode) > { > - FIXME("(%p %d %d %d) stub\n", this, offset, dir, mode); > - return EOF; > + char *base[3]; > + > + TRACE("(%p %d %d %d)\n", this, offset, dir, mode); > + > + if (dir < 0 || dir > 2 || !(mode & (OPENMODE_in|OPENMODE_out))) > + return EOF; > + /* read buffer */ > + if (mode & OPENMODE_in) { > + base[0] = this->base.eback; > + base[1] = this->base.gptr; > + base[2] = this->base.egptr; The code will be easier to read if you use SEEKDIR_beg, SEEKDIR_cur and SEEKDIR_end instead of its values. > + if (this->base.gptr >= this->base.egptr) > + call_streambuf_underflow(&this->base); According to my testing call_streambuf_underflow should be called always, even so default implementation will just return in this case. I was not really checking it but it looks wrong that you store base table values before underflow is called. Patches 1-9 looks good for me. Thanks, Piotr

1 0

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME
by Henri Verbeet Sept. 17, 2015

Sept. 17, 2015

On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=39277 > > Side note: I'm pretty sure I've seen this or a similar issue on my > Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it > further at the time, so I'd really like to see this committed :). > This should probably go to winediag then.

2 2

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2)
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16776 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

Re: rsaenh/tests: Adjust length value to pass on Win 10
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16775 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

The fg-xxx VMs now accessible on demand
by Francois Gouget Sept. 16, 2015

Sept. 16, 2015

So as you may know I run WineTest in a variety of Windows configurations daily (28). The results can be seen on test.winehq.org but the problem is investigating the test failures because most of these configurations cannot be found on the Wine TestBot. I have three options to work around this: * As I mentionned before (1), if you're interested in a specific configuration I may be able to temporarily switch a WineTestBot VM to that configuration. * Another option is to send me an executable to run in the VM and I'll send back the results. * And the new option is that I can now give you VNC access to the VM. Access is open to any Wine developer (i.e. you got a patch accepted in Wine). To get access to the VM contact me on IRC or send me an email and give me the tag of the VM configuration you're interested in (e.g. fg-winxp-lusr). Then I'll start up the VM in the right configuration and send you the address to use to connect to the VM. Of course if I'm asleep or out you may have to wait a bit to get access. Also my uplink is not very fast so expect slow refreshes and some lag. But in the short test I've done it seems to be usable (at least to someone who's used to transatlantic VNC links with an elastic mouse pointer). And for reference here is a list of the available VM configurations. We may not care about some of them, for instance those running the earlier service pack revisions. Let me know if that's the case. Windows 2000 ------------ The French Windows 2000 Professional SP4 installed from an official Microsoft CD. Unless otherwise noted the tests are run in an administrator account. fg-win2000-4sp IE 5.00 SP2 fg-win2000-ie55 = 4sp + IE 5.5 SP2, MSXML3 fg-win2000-ie6 = ie55 + IE 6.0 SP1 fg-win2000-up1 = ie6 + all updates up to 2011/03/21 fg-win2000-uplast = up1 + DirectX 9.0c, WMP 9, .Net 1.1 & 2.0 fg-win2000-rusr = uplast but in a 'Restricted User' account fg-win2000-susr = uplast but in a 'Power User' account Windows XP ---------- I created this VM from the Compaq Windows XP partition of my (former) computer. So this started with a number of extra non-Microsoft applications (blasts from the past: Netscape 7, RealOne Player, etc.). On the one hand this is more representative of what Windows users normally have and on the other the configuration is not as 'straight out of the box' as the other VMs. That may not matter though. fg-winxp-1sp XP SP 1, IE 6.0 SP1, DirectX 8.1 fg-winxp-2sp = 1sp + XP SP2, IE 6.0, DirectX 9.0c, .Net 1.0 SP3 fg-winxp-2spie7 = 2sp + IE 7.0, WMP 10, .Net 1.1 fg-winxp-3sp = 2spie7 + XP SP3, WMP 11, .Net 2.0 SP2 & 3.0 SP2 & 3.5 SP1 fg-winxp-3spie8 = 3sp + IE 8 fg-winxp-last = 3spie8 + all updates up to 2011/09/08 fg-winxp-lusr = last but in a 'Limited User' account Windows 7 --------- Installed from an official English Windows 7 Ultimate CD. Unless otherwise noted the tests are run in an administrator account with Elevated Privileges. fg-win7u64-0sp Base install + French language pack (but still configured for English) fg-win7u64-1sp = 0sp + SP1 fg-win7u64-1spie9(64) = 1sp + IE 9.0, all language packs fg-win7u64-1spie9adm = 1spie9 but no 'Elevated Privileges' fg-win7u64-1spie9usr = 1spie9 but in a 'Standard user' account fg-win7u64-1spie9-ar = 1spie9 but in an Arabic locale fg-win7u64-1spie9-de = 1spie9 but in a German locale fg-win7u64-1spie9-es = 1spie9 but in a Spanish locale fg-win7u64-1spie9-fr = 1spie9 but in a French locale fg-win7u64-1spie9-he = 1spie9 but in a Hebrew locale fg-win7u64-1spie9-ja = 1spie9 but in a Japanese locale fg-win7u64-1spie9-ko = 1spie9 but in a Korean locale fg-win7u64-1spie9-mx = 1spie9 but in a mixed locale (1) https://www.winehq.org/pipermail/wine-devel/2015-September/109252.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

1 0

Re: [PATCH 1/4] xaudio2: Implement IXAudio2SourceVoice frequency functions
by Chris Robinson Sept. 16, 2015

Sept. 16, 2015

On 09/15/2015 10:25 AM, Andrew Eikum wrote: > @@ -801,14 +802,26 @@ static HRESULT WINAPI XA2SRC_SetFrequencyRatio(IXAudio2SourceVoice *iface, > float Ratio, UINT32 OperationSet) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %f, 0x%x\n", This, Ratio, OperationSet); > + > + EnterCriticalSection(&This->lock); > + > + This->freq_ratio = Ratio; > + This->freq = This->fmt->nSamplesPerSec * Ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; ... > @@ -816,7 +829,16 @@ static HRESULT WINAPI XA2SRC_SetSourceSampleRate( > UINT32 NewSourceSampleRate) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %u\n", This, NewSourceSampleRate); > + > + EnterCriticalSection(&This->lock); > + > + This->fmt->nSamplesPerSec = NewSourceSampleRate; > + This->freq = NewSourceSampleRate * This->freq_ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; > } ... > @@ -2989,7 +3012,7 @@ static BOOL xa2buffer_queue_period(XA2SourceImpl *src, XA2Buffer *buf, ALuint al > buf->offs_bytes += submit_bytes; > > alBufferData(al_buf, src->al_fmt, submit_buf, submit_bytes, > - src->fmt->nSamplesPerSec); > + src->freq); > > alSourceQueueBuffers(src->al_src, 1, &al_buf); > This doesn't strike me as correct. Assuming the SampleRate or FrequencyRatio can be altered in real-time, this will break the OpenAL buffer queue which needs to have the same sample rate on each buffer. SetFrequencyRatio looks like it'd map directly to the AL source's pitch property, while SetSourceSampleRate may be a bit trickier depending on when it's allowed to be called (it'd require stopping the source and clearing the queue, then rebuffering and requeueing the buffers to start where it left off). Also, I notice the OperationSet parameter isn't used. What is that for?

2 1

RFC: Hybrid (wineserver / process-local) native semaphores
by Daniel Santos Sept. 16, 2015

Sept. 16, 2015

This patch set fixes most performance problems caused by ReleaseSemaphore() and WaitForSingle/MultipleObject(s) making server calls. One victim of this is Star Wars Battlefront (https://bugs.winehq.org/show_bug.cgi?id=29582) where the majority of the CPU time is spent on context switching while the program spams ReleaseSemaphore, WaitForSingle/MultipleObject(s) and GetForgroundWindow, the later of which I made a work-around hack for and that some players have been using. This patch set doubles performance of bug #29582. (When combined with GetForgroundWindow hack the problem is completely resolved.) The patch set works by having the server create a POSIX semaphore object and sharing the key to that object with the client process, enabling the client process to be able to implement ReleaseSemaphore and optimistic-case wait calls (where no blocking is reburied) without a server call. Blocking waits and any wait-multiple that cannot be resolved in the client process (e.g., bWaitAll=TRUE and objects include non-semaphores) is still handled by the server. (Implementing blocking wait calls on the client can yield some performance improvements because a context switch to another thread in the same program won't require swapping out the memory map & such, but I would expect this to be less significant.) However, upon further experimentation, I discovered that POSIX semaphores in glibc are actually implemented using a shared memory page, which may not be acceptable since a bad process can corrupt that page and potentially cause sem_* function calls in the server to fail as well as other client programs fail and/or deadlock. I am working on a System V adaptation, but I thought it would be a good idea to see feedback & comments now. Another problem is that this causes the threadpool test fails at line 1299, where the previous "release all semaphores and wait for callback" test is done in reverse order. I presume this is due to the nature of the linux scheduler being inconsistent with how Windows *happens* to schedule its threads. I have an idea for a fix for this already, but I will still have to dig deeper into it. The code is still in experimental quality (assert(0)s and such) and I've already re-worked the configure.ac stuff, I'm mostly concerned with feedback on the general scheme. Thanks! Daniel

5 46

Re: [PATCH 1/3] oledb32: Add DataConvert support of DBTYPE_VARIANT(NULL) to DBTYPE_DBDATE
by Nikolay Sivov Sept. 16, 2015

Sept. 16, 2015

If it acts the same for all source variant types it looks like it'd be better to test them all and have this case handled once.

2 1

Re: [3/3] Add period to status bar, dialog box messages (try 2)
by Nikolay Sivov Sept. 16, 2015

Sept. 16, 2015

On 15.09.2015 11:28, Florian Pelz wrote: > STRINGTABLE > { > - IDS_STATUS_DONE "Done" > + IDS_STATUS_DONE "Done." > IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." > } I don't think it's better really to have punctuation in status bars. Probably messages can live without it, unless they consist of multiple sentences, then last one needs termination too.

2 2

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16750 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0003012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung Sept. 16, 2015

Sept. 16, 2015

------------------------------ On Wed, Sep 16, 2015 3:45 AM BST Vincent Povirk wrote: >> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? > >Currently, Wine does not have the ability to load pure .NET PE images >in a 64-bit process. > >Ntdll needs to call _CorValidateImage during the loading process. >_CorValidateImage needs to convert the image, in memory, to the >correct architecture. > >It's complicated, and I don't have a solution. Actually you do :-). Using http://madewokherd.nfshost.com/omgsecret/mono-64bit-exe.tar.gz from https://bugs.winehq.org/show_bug.cgi?id=30518 It is a bit dated, but does the job. I was very confused by both of libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll in c:/windows/mono/mono-2.0/bin/ In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll are never used, at the moment. When 64-bit mono loads a .NET PE image which then P/Invoke, it does so P/Invoke to 64-bit dlls.

2 1

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION. (try 2)
by Dmitry Timoshkov Sept. 16, 2015

Sept. 16, 2015

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > +void X11DRV_FlashWindow( HWND hwnd, BOOL bInvert ) > +{ > + struct x11drv_win_data *data = get_win_data( hwnd ); > + XEvent xev; > + > + if (!data) > + return; > + > + memset( &xev, 0, sizeof(xev) ); > + xev.type = ClientMessage; > + xev.xclient.window = data->whole_window; > + xev.xclient.message_type = x11drv_atom( _NET_WM_STATE ); > + xev.xclient.format = 32; > + xev.xclient.data.l[0] = 1; > + xev.xclient.data.l[1] = XInternAtom( data->display, "_NET_WM_STATE_DEMANDS_ATTENTION", > + False ); > + > + XSendEvent( data->display, DefaultRootWindow( data->display ), False, > + SubstructureNotifyMask, &xev ); > + release_win_data( data ); > +} This can't work, please have a look how XSendEvent is used in other parts of x11drv. -- Dmitry.

1 0

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with UrgencyHint flag.
by Dmitry Timoshkov Sept. 16, 2015

Sept. 16, 2015

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > This patch only set UrgencyHint flag when the window is minimized. > Because X11 only define UrgencyHint, the specific UI effect is > implemented by WM/DE. Different WM/DE may have different UI effect > which is quite different from Windows. Probably FlashWindow should be implemented with _NET_WM_STATE_DEMANDS_ATTENTION instead. -- Dmitry.

2 1

disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung Sept. 16, 2015

Sept. 16, 2015

Hi, I am not having any luck trying to disable wow64 temporarily to test 64-bit wine-mono P/invoke . I tried moving syswow64, removing 32-bit wine, moving wow32.dll, etc. It either insists on p/invoking 32-bit dlls, or not recognizing the .net assembly at all. What I like to do is to test a pure 64-bit code-path - starting with neutral .net assembly, p/invoke to 64-bit dll's. This is possible on windows - in fact cmd.exe on win 8 64-bit will refuse to p/invoke to 32-bit dll's. Is there any way of doing this with 64-bit wine and 64-bit wine-mono? Hin-Tak

2 1

Re: [PATCH 3/4] xaudio2: Call OnStreamEnd callback
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16733 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB6EDD4B7D === w1064 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFC549A4B7D

1 0

Re: [PATCH] mshtml: Fixed tests on some Windows versions.
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16726 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 === w1064 (64 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132

1 0

Re: ieframe: Fixed tests on some VMs.
by Marvin Sept. 16, 2015

Sept. 16, 2015

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=16725 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE === w1064 (32 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 === w1064 (64 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182

1 0

Re: [PATCH 7/7] wined3d: remove wined3d_surface_preload
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; You don't need this anymore.

1 0

Re: [PATCH 5/7] wined3d: remove wined3d_volume_from_resource from the public api
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 7fb136d..49ed8db 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2332,6 +2332,7 @@ BOOL volume_prepare_system_memory(struct wined3d_volume *volume) DECLSPEC_HIDDEN > HRESULT wined3d_volume_create(struct wined3d_texture *container, const struct wined3d_resource_desc *desc, > unsigned int level, struct wined3d_volume **volume) DECLSPEC_HIDDEN; > void wined3d_volume_destroy(struct wined3d_volume *volume) DECLSPEC_HIDDEN; > +struct wined3d_volume *wined3d_volume_from_resource(struct wined3d_resource *resource) DECLSPEC_HIDDEN; You never want to use this from inside wined3d. If there are any callers they should use volume_from_resource() instead.

1 0

Re: [PATCH 3/7] wined3d: introduce new wined3d_texture_(un)map functions
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static const struct wined3d_texture_ops texture2d_ops = > { > texture2d_sub_resource_load, > @@ -924,6 +935,8 @@ static const struct wined3d_texture_ops texture2d_ops = > texture2d_sub_resource_validate_location, > texture2d_sub_resource_upload_data, > texture2d_prepare_texture, > + texture2d_sub_resource_map, > + texture2d_sub_resource_unmap, > }; > Please keep the various sub_resource operations together. (I.e., keep texture_prepare_texture last.) You're probably also missing some wined3d_private.h changes here that ended up in the next patch. It doesn't make sense to introduce these without users, so what you'd want to do is e.g. first make the change for d3d10_texture2d_Map(), then for d3d10_texture2d_Unmap(), etc.

1 0

Re: [PATCH 2/7] wined3d: pass a wined3d_box to wined3d_surface_map
by Stefan Dösinger Sept. 15, 2015

Sept. 15, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:13 schrieb Riccardo Bortolato: > + hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect ? (const struct wined3d_box *)&box : NULL, flags); Why do you need the cast? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9x41AAoJEN0/YqbEcdMw5H4P/i9IrXL1PHd3pzoSmu2ObeSg rYWjMykbp0rh39JwXioBnMqbOCfneEjCSESHGqChNYQ4ZUHyMa6v8M0SOelvxlsA s9sQDs1YBRreXHTMlJSze4/jkHuOSFPCCiVueYLXsyoPunjER+KielzvICZ7lFYQ MQtHi6VwvUDiZJb7UaU3EeiUz2Drxq/Tki5OOgl+NS0rVQXRrecaA3qimPKEpbpI SkXChNulMWHM5q1cboxfP585R7SX12RnirNH0Wwx5kgv21gnvJGVB4eLirPNeKvA FnYAeGqo0ct3ruY9O77UMQFZTbAfn20Jv1EP4ZD0dAhUaUeSzPKQ9I68f+LYC5tG jiwZ7+8E/ReGWXRWcmHF3gnp3SumFl4RtQl8oz4jcqwoH42+xaaSMn5NDam4Hx0s sImgiqEG1ga7sCTOFUIL3q+0XkCpmXMwsjuBxxdZO1qRzSw9MlSgf1BpGsl3rJUb gHI4E+CsgHgUtP8ANyAPJBEbX87JEZ4SDycPwvgNIPQL84hRi0j+FvTJuJe26SN3 47qorsnjy9i/HrtTZXu613qhB07oMedyowWFRqI4EhRv8aKBUB6efzo8/LVHNU2v Sdfy3iI6d6Z+01sZa7nkdbAxeeASfEJ0tSKYN8ikRe0ahPhbRSFU0aD3/4+smQT6 EHW5Os4oDmiycqCxwogK =PePB -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/7] wined3d: store wined3d_texture and sub_resource_idx in d3d8, d3d9 and ddraw surfaces and volumes
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 14 September 2015 at 13:13, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index d12805f..d1eebbb 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -193,10 +193,13 @@ struct d3d9_volume > struct d3d9_resource resource; > struct wined3d_volume *wined3d_volume; > struct d3d9_texture *texture; > + struct wined3d_texture *wined3d_texture; > + UINT sub_resource_idx; I'd prefer "unsigned int", but it's not that important. We'll probably want "wined3d_texture" and "sub_resource_idx" before "wined3d_volume". > -void volume_init(struct d3d9_volume *volume, struct d3d9_texture *texture, > - struct wined3d_volume *wined3d_volume, const struct wined3d_parent_ops **parent_ops) DECLSPEC_HIDDEN; > +void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > + const struct wined3d_parent_ops **parent_ops, > + struct wined3d_texture *wined3d_texture, unsigned int sub_resource_idx) DECLSPEC_HIDDEN; Please keep "parent_ops" the last parameter. You don't need the wined3d_volume parameter here. Affects the device_parent calls as well. > @@ -5395,6 +5395,7 @@ HRESULT wined3d_surface_create(struct wined3d_texture *container, const struct w > struct wined3d_surface *object; > void *parent; > HRESULT hr; > + UINT sub_resource_idx = layer * container->level_count + level; This probably doesn't need its own variable. I think it makes sense to split this patch in two, one making the change for volumes, and one making the change for surfaces.

1 0

Re: [PATCH 8/8] d3d11/tests: Add basic test for ID3D11InputLayout.
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1277,4 +1334,5 @@ START_TEST(d3d11) > test_depthstencil_view_interfaces(); > test_create_rendertarget_view(); > test_create_shader_resource_view(); > + test_create_input_layout(); > } I don't think this needs its own test. There will be plenty of places that create input layouts once we start drawing things. If nothing else, d3d10core has the test_il_append_aligned() test that tests some more specific input layout things.

1 0

Re: [PATCH 3/8] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > There's an ugly check if *immediate_context is NULL. It will go away > when we have a stub interface for the immediate context. > --- That usually means the ordering of the patches isn't quite right. :) Although I suppose it's not too bad in this case, but you should at least add some kind of FIXME comment. > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Looking at the associated test, you may have misunderstood what I meant yesterday. If "swapchain_out" is NULL, you're creating a swapchain only to release it right away again. It may be the case that that's correct because of the side effects like the validation of swapchain_desc and potential window messages that end up being sent, but I suspect we should simply skip creating the swapchain.

1 0

regsvr32.exe tests
by Hugh McMaster Sept. 15, 2015

Sept. 15, 2015

Over the past few weeks I've been sending a number of patches for regsvr32.exe to the wine-patches mailing list. Those patches are the product of a new test suite written for regsvr32.exe. The good news is that all of the tests now pass on Wine. The bad news is that the test suite is not suitable for wine-patches because I haven't been able to produce the test DLLs at runtime. The PE header format is complicated and I'm not too sure what I'm doing. In the meantime, anyone who is interested in the regsvr32.exe tests can download the source and test DLLs from the link below. https://www.dropbox.com/sh/39sytyithd76x97/AAD-FntoMfEvhvrqAnWyW6QJa?dl=0 Any comments on the tests and/or help with the PE header issue etc. are welcome.

1 0

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).
by Jacek Caban Sept. 15, 2015

Sept. 15, 2015

Hi Dmitry, On 09/02/15 07:44, Dmitry Timoshkov wrote: > + if (member == DISPID_HTTPREQUEST_OPTION) Why can't we use standard, ITypeInfo-based implementation here? > + { > + VARIANT ret_value, option; > + UINT err_pos; > + > + if (!result) result = &ret_value; > + if (!arg_err) arg_err = &err_pos; > + > + VariantInit( &option ); > + VariantInit( result ); > + > + if (flags == DISPATCH_PROPERTYPUT) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > + if (FAILED(hr)) > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > + if (FAILED(hr)) > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + > + return S_OK; I don't think silently returning S_OK is right for not handled flags. Thanks, Jacek

2 9

Re: wined3d: Fix TRACE in shader_dump_decl_usage().
by Henri Verbeet Sept. 15, 2015

Sept. 15, 2015

On 15 September 2015 at 11:11, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > case WINED3D_SHADER_RESOURCE_TEXTURE_3D: > - TRACE("_volume"); > + TRACE("_3d"); I think the change makes sense, but it's not really a fix. We can essentially call this whatever we like. Originally this was based on the d3d9 naming where you have "dcl_volume". OpenGL and d3d10+ call these 3D textures.

1 0

Re: [PATCH] ntdll/tests: Skip RtlRandom tests on Windows 10.
by Austin English Sept. 15, 2015

Sept. 15, 2015

On Mon, Sep 14, 2015 at 12:24 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Windows 10 uses a different algorithm for RtlRandom. > All the tests currently fail and produce tons of spam. > (There's already a similar case for Windows Vista.) > --- > dlls/ntdll/tests/rtl.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 9a4ec48..f42e313 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -739,6 +739,16 @@ static void test_RtlRandom(void) > return; > } > > +/* > + * Windows 10 uses different algorithms, so skip the rest of the tests > + * until that is figured out. Trace output for the failures is about 23 MB! > + */ > + > + if (seed == 0x7fffffc3) { > + skip("Most likely running on Windows 10 which uses a different algorithm\n"); > + return; > + } > + > ok(result == result_expected, > "pRtlRandom(&seed (seed == 0)) returns %x, expected %x\n", > result, result_expected); > -- > 2.5.1 This should probably be win_skip() rather than skip(). -- -Austin

3 2

Re: [2/3] Use quotes around service names in net program.
by Nikolay Sivov Sept. 15, 2015

Sept. 15, 2015

On 13.09.2015 18:51, pelzflorian(a)pelzflorian.de wrote: Please update resource file only, the rest will be regenerated with appropriate fuzziness (e.g. Russian strings are done wrong, regarding quotation marks).

2 3

Re: [PATCH 4/7] wined3d: replace wined3d_{surface, volume}_(un)map with wined3d_texture_(un)map
by Stefan Dösinger Sept. 14, 2015

Sept. 14, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:14 schrieb Riccardo Bortolato: > -HRESULT __cdecl wined3d_surface_map(struct wined3d_surface *surface, > - struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > -void __cdecl wined3d_surface_preload(struct wined3d_surface *surface); The wined3d_surface_preload removal seems premature and should be in patch 7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9yCsAAoJEN0/YqbEcdMwSh0P/1OCyBpwswYeaCD40J6YfpQb 8eXAgQlsbbqWQen6Zw+d0W3ixqJsrUJfnZM6gQu2vBp80RQxSNjuifizy3pJgXzy eHAuEWATtFrkGiyPF6EWjheGW7uM7FRyYt4DRXHCu+W3QnYkbpT0YXw7FhtGsPo2 GP/NzctDeGLwe0qrGyFtrg5WxhOA7RqdGaWIsAeMrcTiUzcS9Hbc0leTfYIJOprL bu5scnmKKobtadAOgB5um9hBSXynQzKLg8zzd5NzQMdqnRFJ3QTdZfw7YBtRpX63 0V6yVFztJgErsibvvyIUpTvGQIqq2KmAMpoDMR3p9NYzPEeyvLStnmqmHn5vZ8ZH KyP35umA552xYFQvxy/aAjttSovkrul7dv9X+W6HYW/HqwwU+XrEgCFHPpEwfM4Z 35i6onuZtrm0tSYdloCkf1hFmzn5R6izUrNvduxf64J7aSNJ3sZ2hYh56gGgSgCC uyJU9kp7SRXy7gBjEnwY95DN1V27v6+LR/VPoi2u5yaM9zAc2mOjzUBErsJSviNq phGCtnDKP6i25ajkIjEcmB9nGq7KIUV7EvgjuGz4hv4jrYtES3WsZYbPfJQs/hai pmPtOeCft7vZLkH/ZfzCx00Wggs0JwloJb5fPxDw1WYKiaq2zjXvL6yHivVqaiGN GqngsuTeKGkated3sg4H =gUhb -----END PGP SIGNATURE-----

1 0

Re: [PATCH 05/10] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet Sept. 14, 2015

Sept. 14, 2015

On 14 September 2015 at 00:13, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Is "desc" validated or modified in this case? Otherwise you could return a lot earlier. The test doesn't really cover that. > + hr = D3D11CreateDevice(adapter, driver_type, swrast, flags, feature_levels, levels, sdk_version, > + &device, NULL, NULL); > + if (FAILED(hr)) > + { > + WARN("Failed to create a device, returning %#x.\n", hr); > + *device_out = NULL; > + return hr; > + } ... > + > + if (obtained_feature_level) > + *obtained_feature_level = ID3D11Device_GetFeatureLevel(device); > + > + if (immediate_context) > + ID3D11Device_GetImmediateContext(device, immediate_context); This seems odd. Why not just pass these to D3D11CreateDevice()? If you like you can do things like the D3D11CreateDevice() call inside the if. I.e., "if (FAILED(hr = D3D11CreateDevice(...)))". I tend to do that for newer code, older code usually has it on separate lines.

2 2

WineTestBot test coverage
by Francois Gouget Sept. 14, 2015

Sept. 14, 2015

When setting up the WineTestBot VMs I have tried to make it so we can compare their results across Windows versions so we know if a specific behavior is specific to a given Windows version or was introduced in a specific Windows version. At the same time I tried to diversify the Windows configurations to get better coverage of various locales, particularly when they involve right-to-left text or asian characters, but also to test other aspects like having multiple network cards, two disks, etc. While ideally the WineTestBot would be able to switch each VM between multiple configurations (through the use of snapshots), currently this is not supported. Thus we can only test as many configurations as we have VMs (and Windows licenses). As a result choices have to be made, the coverage is not complete and there may be room for improvement. For instance w7u is configured for Japanese because it's an asian language and I know we have developers who know Japanese. But it turns out a number of test failures are specific to Korean. Ideally we'd have both but there are only two VMs(*) that can be configured for non-English locales and the other one is configured to check for right-to-left issues (previously Arabic and now through Hebrew). Similarly all VMs run the tests with elevated privileges because that's what allows running the maximum number of tests. But this means tests are never tested in unprivileged accounts leading to a bunch of failures when that happens. So should we change the configuration of some of the WineTestBot VMs? Which aspects are the most important? An additional note is that I can relatively easily reconfigure a VM and then switch between that configuration and what we have now. So for instance I could switch the Japanese VM to Korean if a developer needs it to debug things, and then switch it back to Japanese when he's done. Between the timezone delays and WineTestBot's own, the latency would be around a day. So here is a summary of the available configurations. Let me know if there are changes to do: w2000pro IE 6 sp1, DirectX 9.0c, MSXML 4&6, VC 2005/8/10, IPX, AppleTalk, data CD wxppro IE 8, DirectX extras, MSXML 4, VC 2005/8/10, winpcap w2003std IE 8, .Net 2.0 SP2, 3.0 SP2, 3.5 SP2, 4, MSXML 4, VC 2005/8/10. wvista IE 9, .Net 3.5 SP1 & 4.5.1, RMP wvistau64 IE 8, Hebrew, tests on e:, DirectX extras, MSXML 4, VC 2005/10. winpcap w2008s64 IE 9, .Net 4.0, no sound, two network cards w7u IE 11, Japanese, .Net 3.5 & 4.5, VC 2012/13, data CD w7pro64 IE 11, .Net 4.5.1 w8 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w864 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w1064 Edge, DirectX extras Legend: - DirectX extras: This installs some dlls that are not installed by default, for DirectMusic and DirectPlay for instance. - AppleTalk: The AppleTalk network protocol. - IPX: The IPX network protocol. - RMP: The Reliable Multicast Protocol network protocol. Known holes: * No Windows 8 (only Windows 8.1). * No IE 7 configuration. * No IE 10 configuration. * No non-elevated or regular user tests. * Korean locale. Other locales? * No mixed locale (to ensure the tests check the right locale API). (*) Though the locale of the new Windows 10 VM is probably configurable too. So that would be 3 VMs. But do we want to add failures to a VM that already has a lot? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0