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

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

Nov. 22, 2020

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

1 1

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

Sept. 28, 2018

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

5 6

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

June 14, 2018

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

5 4

Re: user32: Avoid -Wmisleading-indentation warnings and fix comments in comments in test_AppendMenu.
by Dmitry Timoshkov Aug. 11, 2016

Aug. 11, 2016

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > diff --git a/dlls/user32/tests/menu.c b/dlls/user32/tests/menu.c > index 33d8eb8..ea965cd 100644 > --- a/dlls/user32/tests/menu.c > +++ b/dlls/user32/tests/menu.c > @@ -3992,13 +3992,15 @@ static void test_AppendMenu(void) > mii.wID = 206; > ret = InsertMenuItemA(hmenu, 0, TRUE, &mii); > ok(ret, "InsertMenuItem failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 206, MF_SEPARATOR, MFS_GRAYED); > +} > mii.wID = 207; > ret = SetMenuItemInfoA(hmenu, 0, TRUE, &mii); > ok(ret, "SetMenuItemInfo failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 207, MF_SEPARATOR, MFS_GRAYED); > +} > DestroyMenu(hmenu); > > hbmp = CreateBitmap(1, 1, 1, 1, NULL); Please don't make the code look uglier than it already is. I'd personally argue that checking and forcing indentation rules by a C compiler is pretty disappointing and actually misleading. That warning should be turned off by default IMHO. -- Dmitry.

3 2

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

Student interested in GSoC 2016 implementing D3DX9 API idea
by Xu Zhao March 22, 2016

March 22, 2016

Hello Wine Community, First congrats that Wine Project get accepted into GSoC 2016 summer organization! I am currently a PhD student in University of Toronto and I am interested in the D3DX9 API implementation task. Mainly because I would like to see more games can run in wine because of my work! My research field is operating system so I am a pretty good C/CPP programmer. However I am not very familiar with DirectX related programming and hopefully I can get some help from the community, like where to start. I have read the wiki entry of D3DX9 API and want to get some help in selecting a reasonable sized API list, maybe someone can reply and provide some help? Thank you! Regards, - Xu -- Xu Zhao i(a)xuzhao.net

2 2

GSoC Idea: Tools - Winetest Scripting Interface
by Zhenbo Li March 15, 2016

March 15, 2016

Hello, I'm Zhenbo Li. I participated in GSoC twice. This year, I want to work on "Tools - Winetest Scripting Interface". After "make test", checking the output in stdout manually is horrible. As ok() macro is used quite widely, my patches should cause no surprise. That is to say, other developers need to read neither my patches nor the changelog to continue their jobs, although ok() macro and other tools for test have been changed. I think there will be two steps for the goal: 1. ok() macro ===================== int winetest_vok( int condition, const char *msg, __winetest_va_list args ) { tls_data* data=get_tls_data(); if (data->todo_level){...} else { if (!condition) { printf( "%s:%d: Test failed: ", data->current_file, data->current_line ); vprintf(msg, args); InterlockedIncrement(&failures); return 0; } else{.....} } } Instead of printing all the data to stderr, I think we can write a wrapper static void test_print(const char *s) { if(want_print_to_file) fprintf(file_handle, s); printf(s); } It needs some work to make sure that the file_handle is opened/closed successfully. With that, we can record the failed tests to a file, and developers don't need to find them in stdout anymore. 2. compare the results ======================= On the idea page, it says that any scripting language is acceptable. I prefer Python3. To make the code simple, I think editing runtest script is the best solution. Currently, our logic in Makefile is htmllocation.ok: ../../../tools/runtest $(RUNTESTFLAGS) -T ../../.. -M mshtml.dll -p mshtml_test.exe.so htmllocation && touch $@ And in runtest, we have exec $WINETEST_WRAPPER "$topobjdir/wine" "$program" "$@" I don't want to touch Makefile. Instead, I'm going to add some options for runtest. For example, one can use ../../../tools/runtest $(RUNTESTFLAGS) -new_option expected_errors_generated before -T ../../.. -M mshtml.dll -p mshtml_test.exe.so htmllocation And in runtest script, we can expected_errors_generated and new_errors_got, then tell that whether the test result has been changed. It should be easy for developers to write a script for git bisect or other circumstance. Problems ========= This approach seems to be quite simple, and there are some conditions can't be handled. For example void test_foo(sturct Data *d){ ret = foo(d); ok(ret, "foo(%s) is %d\n", data_to_str(d), ret); } struct Data list[]={a,b,c,d,e}; void test(){ for(i in list) test_foo(i); } I think we should not do too much "smart deduce" here, and don't hide what's happening to other developers. Maybe we can add another option for runtest script: --scrict=false This is my humble idea for Wine's GSoC 2016. If this project goes well, working on wine test suit will be much more satisfying(although still boring). I appreciate for your comment. With you a happy weekend. -- Have a nice day! Zhenbo Li

6 15

Attachments missing in new wiki
by Qian Hong March 11, 2016

March 11, 2016

Hi folks, Thanks for migrating the wiki to new site. Recently two different people ask me about attachments on https://wiki.winehq.org/WineConf2015, and I found they are missing, anyone knows what happen during the migration? Should we manually upload again? Is there backup for the attachments from old side? Thanks! -- Regards, Qian Hong - http://www.winehq.org

5 5

Re: [PATCH 2/3] user32: Added more dialog owner tests.
by Dmitry Timoshkov March 2, 2016

March 2, 2016

Hi Jacek, Jacek Caban <jacek(a)codeweavers.com> wrote: > + parent = CreateWindowExA(0, "TestParentClass", "Test parent", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (parent != 0, "Failed to create parent window\n"); > + > + child = CreateWindowExA(0, "TestWindowClass", "Test child", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (child != 0, "Failed to create child window\n"); > + > + child2 = CreateWindowExA(0, "SimpleWindowClass", "Test child2", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, > + 100, 100, 200, 200, child, 0, 0, NULL); > + ok (child2 != 0, "Failed to create child window\n"); > + > + SetParent(child, parent); > + SetFocus(child); Is that really required to use SetParent() instead of specifying correct parent in the CreateWindowEx call? > + flush_sequence(); > + DialogBoxA( 0, "TEST_DIALOG", child2, TestModalDlgProc2 ); > + ok_sequence(WmModalDialogSeq_2, "ModalDialog2", TRUE); Is this test supposed to show that actual dialog owner is parent window? If yes, then this theory is not tested at all. > + SetForegroundWindow(hdlg); > + > + { > + const struct message WmEndDialogSeq[] = { > + { WM_ENABLE, sent }, > + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, > + { HCBT_ACTIVATE, hook|wparam, (WPARAM)hchild }, > + { WM_NCACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > + { WM_ACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > + /* FIXME: Following two are optional because Wine sends WM_QUERYNEWPALETTE instead of WM_WINDOWPOSCHANGING */ > + { WM_WINDOWPOSCHANGING, sent|wparam|optional, SWP_NOSIZE|SWP_NOMOVE }, > + { WM_QUERYNEWPALETTE, sent|optional }, > + { WM_NCACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > + { WM_GETTEXT, sent|optional|defwinproc }, > + { WM_ACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > + { HCBT_SETFOCUS, hook|wparam, (WPARAM)hchild }, > + { WM_KILLFOCUS, sent|wparam, (WPARAM)hchild }, > + { WM_SETFOCUS, sent|defwinproc|wparam, (WPARAM)hdlg }, > + { 0 } > + }; > + > + flush_sequence(); > + EndDialog(hdlg, 0); > + ok_sequence(WmEndDialogSeq, "EndDialog", FALSE); > + } Please don't create fake embedded blocks. Also it would be really nice to send the tests first so it would be more clear when a todo_wine is removed with a subsequent patch in order to see whether the patch is actually related to the previously sent tests. -- Dmitry.

3 17

Re: [PATCH 1/3] winemac.drv: Fix our handling of bitmaps on the clipboard.
by Ken Thomases March 2, 2016

March 2, 2016

On Feb 26, 2016, at 3:55 AM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > dlls/winemac.drv/clipboard.c | 87 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 76 insertions(+), 11 deletions(-) Mostly looks good. One request, though: please move create_bitmap_from_dib() to above import_clipboard_data(), just to keep all of the import_* functions together. Also, do you happen to have or know of a convenient program to test this with? Thanks, Ken

1 1

The Wine Project has been accepted as a GSoC 2016 mentor organization!
by André Hentschel March 1, 2016

March 1, 2016

Hi, I'm a little late, but yes, we're accepted again!

2 2

Problems in winedbg.1, msiexec.1, winemaker.1
by esr＠thyrsus.com March 1, 2016

March 1, 2016

This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond Problems with winedbg.1: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- winedbg.1-unpatched 2014-06-02 09:40:08.604693388 -0400 +++ winedbg.1 2014-06-02 09:41:09.350110336 -0400 @@ -163,7 +163,7 @@ .IP \fBbreak\ \fIN\fR Adds a breakpoint at line \fIN\fR of current source file. .IP \fBbreak\fR -Adds a breakpoint at current \f$PC\fR address. +Adds a breakpoint at current \fB$PC\fR address. .IP \fBwatch\ *\ \fIN\fR Adds a watch command (on write) at address \fIN\fR (on 4 bytes). .IP \fBwatch\ \fIid\fR Problems with msiexec.1: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- msiexec.1-unpatched 2014-06-02 17:15:58.428528019 -0400 +++ msiexec.1 2014-06-02 17:18:59.360645276 -0400 @@ -24,25 +24,25 @@ \fR[\fBp\fR|\fBo\fR|\fBe\fR|\fBd\fR|\fBc\fR|\fBa\fR|\fBu\fR|\fBm\fR|\fBs\fR|\fBv\fR]\ \ \fR{\fIpackage\fR|\fIproductcode\fR} Repair an installation. Default options are \'omus\' -.IP "\flp\fR" +.IP "\fBlp\fR" Reinstall the file if it is missing. -.IP "\flo\fR" +.IP "\fBlo\fR" Reinstall the file if it is missing or if any older version is installed. -.IP "\fle\fR" +.IP "\fBle\fR" Reinstall the file if it is missing, or if the installed version is equal or older. -.IP "\fld\fR" +.IP "\fBld\fR" Reinstall the file if it is missing or a different version is installed. -.IP "\flc\fR" +.IP "\fBlc\fR" Reinstall the file if it is missing or the checksum does not match. -.IP "\fla\fR" +.IP "\fBla\fR" Reinstall all files. -.IP "\flu\fR" +.IP "\fBlu\fR" Rewrite all required user registry entries. -.IP "\flm\fR" +.IP "\fBlm\fR" Rewrite all required machine registry entries. -.IP "\fls\fR" +.IP "\fBls\fR" Overwrite any conflicting shortcuts. -.IP "\flv\fR" +.IP "\fBlv\fR" Recache the local installation package from the source installation package. .SH PATCHING .IP \fB/p\ \fR{\fIpatch\fR}\ \fR[\fIproperty\fR=\fIfoobar\fR] @@ -65,35 +65,35 @@ [\fBi\fR|\fBw\fR|\fBe\fR|\fBa\fR|\fBr\fR|\fBu\fR|\fBc\fR|\fBm\fR|\fBo\fR|\fBp\fR|\fBv\fR]\ [\fB+\fR|\fB!\fR]\ {\fIlogfile\fR} Enable logging to \fIlogfile\fR. Defaults are \'iwearmo\'. -.IP "\fl*\fR" +.IP "\fBl*\fR" Enable all logging options except \'v\' and \'x\'. -.IP "\fli\fR" +.IP "\fBli\fR" Log status messages. -.IP "\flw\fR" +.IP "\fBlw\fR" Log nonfatal warnings. -.IP "\fle\fR" +.IP "\fBle\fR" Log all error messages. -.IP "\fla\fR" +.IP "\fBla\fR" Log start of actions. -.IP "\flr\fR" +.IP "\fBlr\fR" Log action specifc records. -.IP "\flu\fR" +.IP "\fBlu\fR" Log user requests. -.IP "\flc\fR" +.IP "\fBlc\fR" Log initial UI parameters. -.IP "\flm\fR" +.IP "\fBlm\fR" Log out of memory errors. -.IP "\flo\fR" +.IP "\fBlo\fR" Log out of diskspace messages. -.IP "\flp \fR" +.IP "\fBlp \fR" Log terminal properties. -.IP "\flv \fR" +.IP "\fBlv \fR" Verbose logging. -.IP "\flx \fR" +.IP "\fBlx \fR" Log extra debugging messages. -.IP "\fl+ \fR" +.IP "\fBl+ \fR" Append logging to existing file. -.IP "\fl! \fR" +.IP "\fBl! \fR" Flush each line to log. .SH OTHER OPTIONS .IP \fB/h Problems with winemaker.1: Unbalanced group in command synopis. You probably forgot to open or close a [ ] or { } group properly. --- winemaker.1-unpatched 2014-06-02 09:52:02.517334795 -0400 +++ winemaker.1 2014-06-02 09:54:21.272566508 -0400 @@ -29,7 +29,6 @@ .br [ .BR "--generated-files " "] [ " "--nogenerated-files " "] -] .br [ .BR "--wine32 " "]

3 3

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.
by Ken Thomases March 1, 2016

March 1, 2016

On Feb 26, 2016, at 5:29 PM, Miklós Máté <mtmkls(a)gmail.com> wrote: > @@ -2320,6 +2322,7 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) > TRACE("(%p)\n", object); > > pglXDestroyPbuffer(gdi_display, object->drawable); > + pglXDestroyContext(gdi_display, object->tmp_context); I think you need to check if object->tmp_context is non-zero before calling glXDestroyContext() to avoid a GLXBadContext error. > + if (!object->tmp_context) { > + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + object->prev_context = prev_context; > + } else if (object->prev_context != prev_context) { > + pglXDestroyContext(gdi_display, object->tmp_context); > + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > + object->prev_context = prev_context; > + } Those two branches are mostly the same. This could be reduced to: if (!object->tmp_context || object->prev_context != prev_context) { if (object->tmp_context) pglXDestroyContext(gdi_display, object->tmp_context); object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); object->prev_context = prev_context; } Is it necessary, when a context is destroyed, to go through all wgl_pbuffer structs looking for any whose prev_context matches the one being destroyed and clear it? Otherwise, you risk having a stale reference that could be reused for a different context and not realize you need to recreate tmp_context. Of course, enumerating all of them in a thread-safe manner is going to require a lot of added infrastructure and complexity. -Ken

3 3

Re: [PATCH 6/6] d3d10core/tests: Port test_multiple_render_targets() from d3d11.
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20980 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/6] d3d10core/tests: Introduce check_texture_color().
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20979 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/6] d3d11/tests: Introduce check_texture_color().
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20978 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/6] d3d11/tests: Add test for multiple render targets.
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20977 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/6] d3d10core/tests: Port test_create_typeless_resource() from d3d11.
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20976 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: ole32: Do not open registry keys with no access rights.
by Sebastian Lackner Feb. 29, 2016

Feb. 29, 2016

On 29.02.2016 16:49, Thomas Faber wrote: > While simply opening a subkey (as done here) does not require any > access rights in particular, NtOpenKey with 0 desired access always > fails with STATUS_ACCESS_DENIED on Windows. > Consequently specifying a nonzero access is a prerequisite for some day > fixing Wine's NtOpenKey behavior in this regard. It would be nice to have tests for that in the wine source tree (marked with todo_wine, until all places which rely on it have been fixed).

2 1

Re: [PATCH v3] winex11.drv: Make the GL context current even if no drawables were given.
by Matteo Bruni Feb. 29, 2016

Feb. 29, 2016

2016-02-24 5:12 GMT+01:00 Charles Davis <cdavis5x(a)gmail.com>: > Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> > --- > Try 3: Fix an assignment I missed. (Thanks, Ken.) > > dlls/opengl32/tests/opengl.c | 2 +- > dlls/winex11.drv/opengl.c | 69 +++++++++++++++++++++++++------------------- > 2 files changed, 41 insertions(+), 30 deletions(-) > > diff --git a/dlls/opengl32/tests/opengl.c b/dlls/opengl32/tests/opengl.c > index e5e1507..c058c19 100644 > --- a/dlls/opengl32/tests/opengl.c > +++ b/dlls/opengl32/tests/opengl.c > @@ -975,7 +975,7 @@ static void test_opengl3(HDC hdc) > * expect drivers to ever offer it. > */ > res = wglMakeCurrent(0, gl3Ctx); > - ok(res == FALSE, "Wow, OpenGL 3.0 windowless rendering passed while it was expected not to!\n"); > + ok(res || broken(!res), "OpenGL 3.0 windowless rendering failed!\n"); That seems suspicious... AFAICS the comment right above this hunk is still valid (it is for current Nvidia drivers on Win7 at least), which probably means that this patch is not a good idea.

4 5

Re: [PATCH 2/3] user32: Added more dialog owner tests.
by Marvin Feb. 29, 2016

Feb. 29, 2016

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=20971 Your paranoid android. === w7u (32 bit msg) === msg.c:8926: Test failed: did not get expected count for minimum timeout (51 != ~100). === w7pro64 (32 bit msg) === msg.c:15473: Test failed: wrong status 00400040 === w1064 (32 bit msg) === msg.c:6417: Test failed: Update region shouldn't be empty msg.c:6651: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6653: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6423: Test failed: Regions are different msg.c:6423: Test failed: Regions are different msg.c:6423: Test failed: Regions are different

1 0

Re: [PATCH 1/2] include: add authz.h
by Alexandre Julliard Feb. 29, 2016

Feb. 29, 2016

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +typedef struct _AUTHZ_ACCESS_REPLY > +{ > + DWORD ResultListLength; > + DWORD *SaclEvaluationResults; > + DWORD *Error; > +} AUTHZ_ACCESS_REPLY, *PAUTHZ_ACCESS_REPLY; There's a field missing here. > +BOOL WINAPI AuthzInitializeResourceManager(DWORD flags, void *access_checker, > + void *compute_dyn_groups, void *free_dyn_groups, > + const WCHAR *managername, void *handle ); That's not the correct prototype. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v4 PATCH] comctl32/tooltip: Protect TTM_ADDTOOLW from invalid text pointers
by Alexandre Julliard Feb. 29, 2016

Feb. 29, 2016

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1041,6 +1041,9 @@ TOOLTIPS_AddToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > if (ti->cbSize >= TTTOOLINFOW_V2_SIZE && !ti->lpszText && isW) > return FALSE; > > + if(isW && ti->lpszText && IsBadReadPtr(ti->lpszText, sizeof(WCHAR))) > + return FALSE; You want IsBadStringPtrW, and this should most likely be merged with the check above it one way or another. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] d3d10core/tests: Test swapchain buffer cycling.
by Henri Verbeet Feb. 29, 2016

Feb. 29, 2016

On 24 February 2016 at 23:28, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Testing multisampling is not possible because only > DXGI_SWAP_EFFECT_DISCARD supports multisampled swapchains and it allows > only access to buffer 0. > > Not exactly test_flip from ddraw because we can't write to the end of > the chain... > > Plenty of todo_wine in here. The read-only part is missing and texturing > from swapchain buffers doesn't work either. > > foo > Is there a d3d11 version of this as well?

1 0

Re: xcopy/tests: Reset "current directory" of current process.
by Alexandre Julliard Feb. 29, 2016

Feb. 29, 2016

Jactry Zeng <jzeng(a)codeweavers.com> writes: > @@ -97,4 +99,5 @@ START_TEST(xcopy) > > DeleteFileA("xcopy1"); > RemoveDirectoryA("xcopytest"); > + SetCurrentDirectoryW(curdir); Restoring the directory at process exit is not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0