August 2008 - Wine-devel - list.winehq.org

Re: dplayx tests hanging
by Dan Kegel 10 Aug '08

10 Aug '08

On Sun, Aug 10, 2008 at 11:42 AM, Ismael Barros <razielmine(a)gmail.com> wrote: > You probably have installed in your wine prefix a windows native > dpwsockx.dll, and dplay gets that one instead of wine's builtin > dpwsockx. Seems to be (perhaps I did winetricks directx9). Removing ~/.wine seems to have helped. Don't know if that explains the two timeout reports on wine at test.winehq.org, but it seems likely. Sorry for not trying a clean .wine before writing. - Dan

1 0

Re: [6/11] ole32 : basic inprocess handler implentation
by Rob Shearman 10 Aug '08

10 Aug '08

2008/8/7 <f.dorin(a)free.fr>: > diff --git a/dlls/ole32/proxystub_obj.c b/dlls/ole32/proxystub_obj.c > new file mode 100644 > index 0000000..c229ad2 > --- /dev/null > +++ b/dlls/ole32/proxystub_obj.c > ... > +HRESULT __RPC_STUB IStorage_OpenStream_Stub( > + IStorage* This, > + LPCOLESTR pwcsName, > + unsigned long cbReserved1, > + byte *reserved1, > + DWORD grfMode, > + DWORD reserved2, > + IStream **ppstm) > +{ > + TRACE("(%p)->(%s, %d, %p, %x, %x, %p)\n", This, debugstr_w(pwcsName), (int)cbReserved1, reserved1, grfMode, reserved2, ppstm); > + return IStorage_OpenStream(This, pwcsName, reserved1, grfMode, reserved2, ppstm); > +} These should go into usrmarshal.c. However, Dan Hipschman as already done some work in this area so you might want to search for his patches on generating proxy/stub code for oleidl.idl and objidl.idl so that you don't do any more work than you have to. -- Rob Shearman

2 1

Re: [1/11] ole32 : basic inprocess handler implentation
by Rob Shearman 10 Aug '08

10 Aug '08

Hi François, I appreciate the work you've put into this and the other patches. However, I have a few comments: 2008/8/7 <f.dorin(a)free.fr>: > @@ -78,4 +83,11 @@ ole2nls.spec.o: ole2nls.spec version16.res > version16.res: version16.rc > $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc > > +objidl_p.c: ../../include/objidl.idl > + $(WIDL) -p ../../include/objidl.idl > + > +oleidl_p.c: ../../include/oleidl.idl > + $(WIDL) -p ../../include/oleidl.idl > + sed -i '14i#include "winuser.h"' oleidl_p.c > + Custom make rules, such as these, are discouraged as they are a pain to maintain because they need to be changed all over the source tree instead of just in Make.rules.in. In this case they should be unnecessary as you can simply create IDL files in the ole32 directory (c.f. dlls/oleaut32/oleaut32_oaidl.idl) that include each of these (and in the second case, add the necessary include file). Also, it's a moot point but I don't think "sed -i" is portable. -- Rob Shearman

1 0

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 8:27 PM (PNT) wrote additionally in reply to Question: Why are EM_FORMATRANGE Tests 'To Do' > >> Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? > >That's the theory :) The test don't run without error on my XP system, so YMMV. Then I should end up with errors on my WindowsXP system that match yours. I don't have time tonight to do so, but my find time tomorrow to run them. James McKenzie

2 1

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 6:41 PM wrote about Question: Why are EM_FORMATRANGE Tests 'To Do' in reply to James McKenzie's question on this subject. > >Hi James, > >> Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? > >todo_wine tests are always run, whether or not the todo_wine flag is >there. The only difference is how the results are interpreted: if >running on Wine (which the standalone tests assume they are not), the >test is assumed to fail, and an error reported if the test does not >fail as expected on Wine. If not running on Wine, they run as normal. Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? James McKenzie

2 1

Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? Thank you. James McKenzie

2 1

Networking problems with IDU Verwaltung software
by Werner LEMBERG 09 Aug '08

09 Aug '08

[wine 1.1.2] [openSuSE 10.2, kernel 2.6.21-rc6] Folks, I try to make run a German software bundle called `IDU Verwaltung'. It seems to work, however, I can't make it to connect to a PostgreSQL database. I have enabled PostgreSQL access in my firewall. Interestingly, I couldn't find information how to debug networking problems with wine. Any links? Whatever, here my problem report. I tried on wine-users first, but the responses weren't really encouraging. I've executed WINEDEBUG=warn+all wine Idu_Verwaltung.exe 2> ~/winelog.warnall [within a fresh .wine, not installing any vcredist_x86.exe bundle -- doing this doesn't solve the `actctx' problem which is listed below, BTW] Doing cat winelog.warnall \ | grep -v 'c000003[45]' \ | grep -v 'not found' \ | grep -v 'case-insensitive' \ | grep -i -v 'failed to load' \ | grep -v 'cannot open' \ | grep -v 'no-exec' \ | grep -v 'Invalid handle' \ | grep -v 'font' \ | grep -v 'vkey' \ | grep -v 'keysyms' \ | grep -v 'Heap' \ | grep -v 'Bitmap' \ | grep -v 'GetDC' gives warn:sync:SetNamedPipeHandleState stub: 0x24 0x7edca5a8/2 (nil) (nil) warn:msvcrt:msvcrt_init_console :Console handle Initialisation FAILED! warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name dnsTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name txTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name dnsTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name txTimeout warn:mixer:getcomponenttype Unknown mixer name Capture Mux, probably harmless warn:mixer:getcomponenttype Unknown mixer name Capture Mux, probably harmless warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:actctx:lookup_manifest_file no matching file for L"x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.*.*_*.manife fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" warn:module:process_attach Initialization of L"MSVCR80.dll" failed warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=460001 lp=00030046 warn:file:CreateFileW Unable to create file L"\\\\.\\Z:" (status c0000022) warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=420001 lp=00060042 warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=4c0001 lp=0009004c warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:profile:PROFILE_FlushFile No current profile! The only messages related to networking are those winspool things which doesn't say anything to me. Any idea how to proceed? Werner PS: In case you still have any FreeType issues in Wine, ask me :-)

7 13

Re: Make RegisterDeviceNotificationW behave likeRegisterDeviceNotificationA
by Martin Profittlich 09 Aug '08

09 Aug '08

Dmitry Timoshkov wrote: >"Zachary Goldberg" <zgold550 at gmail.com> wrote: > >> Your patch is more likely to be accepted if it comes with a test which >> works on windows, didnt pass in wine before but passes now and >> demonstrates why the new behavior is correct. > > There is no need for a test since that's not really an implementation > but just a better stub which follows existing code. So is there anything I should do now? Or just wait to see what happens? As for writing a test, I don't think that's possible. The affected apps don't crash inside that function but shortly afterwards. It's just that the crash is affected by the result of RegisterDeviceNotificationW. Wouldn't it also be more consistent, if *A and *W did the same thing? Martin -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

2 1

Re: [1/11] ole32 : basic inprocess handler implentation
by Detlef Riekenberg 09 Aug '08

09 Aug '08

On Do, 2008-08-07 at 15:45 +0200, f.dorin(a)free.fr wrote: > This patch modifies the Makefile.in file to include some new file to be compile - You must use your real name - Wine must compile after every Patch. You need to add the changes for Makefile.in, when you add a file - Why do you need to use sed for winuser.h? When the input for widl is correct and the output of widl is wrong, then widl must be fixed instead. - You forgot the License-Header in the new files. Wine is LGPL. -- quote -- 2.1 of the License, or (at your option) any later version. -- quote -- - The subject is not very precise. You should use the description, that is already in your Mail. Example for [4/11]: "Main core file for inprocess handler implementation" - Some Patches are large, please try to split it. - Some lines in your Patches are very long, please try to split them. - Do not use C++ style comments - Wine is using 4 Space for indention. The only exception is to stay with the indention of File, when you touch that File - No Idea, if the change in 8/11 is acceptable, but you should a comment in the code, when you make such a change. - A Hack, to workaround a bug in widl will not be accepted. Widl must be fixed instead. - Unrelated to the fact, that the Hack in 10/11 will not be accepted, you must make sure, not add spaces at the end of a Line. - When you change the imlementation, that fix a test, then both changes must be in the same Patch Thanks for helping Wine -- By by ... Detlef

1 0

Re: taskmgr [try 4]: Converted some functions and variables to Unicode [1/7]
by Nikolay Sivov 09 Aug '08

09 Aug '08

Vladimir Pankratov wrote: > static void TaskManager_OnMenuSelect(HWND hWnd, UINT nItemID, UINT nFlags, HMENU hSysMenu) > { > - TCHAR str[100]; > + WCHAR wstr[256]; > + WCHAR wszEmptyStr[] = {' ',0}; > > - _tcscpy(str, TEXT("")); > - if (LoadString(hInst, nItemID, str, 100)) { > - /* load appropriate string */ > - LPTSTR lpsz = str; > - /* first newline terminates actual string */ > - lpsz = _tcschr(lpsz, '\n'); > - if (lpsz != NULL) > - *lpsz = '\0'; > - } > - SendMessage(hStatusWnd, SB_SETTEXT, 0, (LPARAM)str); > + strcpyW(wstr, wszEmptyStr); > + LoadStringW(hInst, nItemID, wstr, sizeof(wstr)/sizeof(WCHAR)); > + SendMessageW(hStatusWnd, SB_SETTEXTW, 0, (LPARAM)wstr); > } > > static void TaskManager_OnViewUpdateSpeedHigh(void) You really need a single space string passed as message parameter? If not - WCHAR wszEmptyStr[] = {0} - should be enough. And maybe it's better to initialize wstr to empty instead of using another variable.

1 0