Re: [PATCH 3/3] dinput: Combine ASCII and Unicode device create callbacks. Add tests.
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 http://testbot.winehq.org/JobDetails.pl?Key=8419 Your paranoid android. === WNT4WSSP6 (32 bit device) === device.c:164: Test failed: DirectInputCreate() failed: 80040154
Re: New winetricks 20110117-alpha: new verbs dxdiag, firefox4, ut3, hegemonygold_demo, dxdiagn, pngfilt; new svn repo, download url
On 01/17/2011 03:14 PM, Rosanne DiMesio wrote: > On Mon, 17 Jan 2011 12:33:28 -0700 > Vitaliy Margolen wrote: > >> Isn't that exactly why we marked all other scripts like this a "third party >> unsupported tools"? If you moving the same direction, then winetricks will >> fall into the same category - if you using it, ask Dan, don't bother asking >> people on forum, filing bugs, etc. >> > > We already treat winetricks like that. I know I'm constantly telling users to > reinstall to a clean wineprefix with no winetricks. The winetricks wiki page > tells users explicitly not to report bugs here if they have used winetricks > to install native dlls, and has a link to winezeug to report bugs in > winetricks itself. I don't see any of that changing. > > That said, I do think winetricks has become bloated. JMHO. > Bloat is really just an interface problem. It's still only a few kilobytes of shell script. -Scott
Re: Working implementation of the ping
On Thu, 02 Dec 2010 22:09:39 +0300, Devaev Maxim wrote: The implementation uses a library icmp.dll. Non-root user in Linux can not work with icmp, special permission is required capabilities. I made it so that in case of error simulates the ping delay. Why this patch is not accepted in upstream?
Re: [PATCH] sdfmlsdkf
On Tue, Jan 18, 2011 at 12:39 PM, Eric Pouech wrote: I think you messed up the patch subject ;-). -- -Austin
Re: today's git does not compile
> It's not wine's fault, and you're not missing any dependencies; the >> new version of gcc is probably buggy, and the bug is triggered by >> something inside wine. > >If you've compiled Wine before and are re-using object files from an >old gcc it's possible that there is a conflict between the object >files from before and the object files with your new version of gcc. >So, you could try a "make clean" and then compile again. > >Erich Hoover >ehoo...@mines.edu I tried "make distclean" and also tried a new wine-git download... so far nothing. On with the flags test.
Re: today's git does not compile
On Tue, Jan 18, 2011 at 12:04 PM, Erich Hoover wrote: > On Tue, Jan 18, 2011 at 12:55 PM, Dan Kegel wrote: >> ... >> It's not wine's fault, and you're not missing any dependencies; the >> new version of gcc is probably buggy, and the bug is triggered by >> something inside wine. > > If you've compiled Wine before and are re-using object files from an > old gcc it's possible that there is a conflict between the object > files from before and the object files with your new version of gcc. > So, you could try a "make clean" and then compile again. While "make clean" is good advice in general, and Susan should do that before doing the -O1 rebuild, I have a feeling the current crash doesn't involve reading any old .o files. - Dan
Re: today's git does not compile
On Tue, Jan 18, 2011 at 12:55 PM, Dan Kegel wrote: > ... > It's not wine's fault, and you're not missing any dependencies; the > new version of gcc is probably buggy, and the bug is triggered by > something inside wine. If you've compiled Wine before and are re-using object files from an old gcc it's possible that there is a conflict between the object files from before and the object files with your new version of gcc. So, you could try a "make clean" and then compile again. Erich Hoover ehoo...@mines.edu
re: today's git does not compile
Susan wrote: > I have the latest version of Natty Narwhal > gcc (Ubuntu/Linaro 4.5.2-1ubuntu6) 4.5.2 >... >gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ >-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >-Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits >-Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE >-D_FORTIFY_SOURCE=0 -o pen.o pen.c >pen.c: In function ‘X11DRV_SelectPen’: >pen.c:31:12: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. It's not wine's fault, and you're not missing any dependencies; the new version of gcc is probably buggy, and the bug is triggered by something inside wine. Try switching from -O2 to -O1 with configure CFLAGS="-g -O1" and rebuild. Does that help? Regardless of whether that gets you past the problem, please file a bug in launchpad against gcc-4.5. https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/693686 and https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/690194 are similar bugs you could use as examples. Ideally they'd want you to run with -save-temps and give them a copy of pen.i.
Re: today's git does not compile
On 1/18/11 12:10 PM, Susan Cragin wrote: > pen.c:31:12: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. Looks like you've hit a compiler bug. Do what the error message says, and report this to the GCC guys. Chip
today's git does not compile
Could there be a new dependency that isn't summoned by build-dep? Or is it me? I have the latest version of Natty Narwhal gcc (Ubuntu/Linaro 4.5.2-1ubuntu6) 4.5.2 gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o pen.o pen.c pen.c: In function ‘X11DRV_SelectPen’: pen.c:31:12: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[1]: *** [pen.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winex11.drv' make: *** [dlls/winex11.drv] Error 2 susan@ubuntu:~/wine$ cd
Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.
On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban wrote:
> ...
> I'm not sure what you mean by "hijack the IOleCommandTarget". All we do is
> implementing client's IOleCommandTarget. It's something different from
> document's one.
I understand that, but apparently the native implementation (testing on the
test bot WXPPROSP3) sends the command to the client IOleCommandTarget
instead of the document IOleCommandTarget (at least under the conditions of
the webbrowser tests). That is what I mean by hijacking, the command is
going to the "wrong" target. My guess would be that there is some sort of
priority mechanism, though I have no idea how it would work (except maybe
"if there's a client/container then send to that target, else send to the
document target). I've attached a test where I disabled the
client/container, and you can see that it then gets passed through
(QueryStatusWB will return success instead of passing through the client
target and returning failure):
https://testbot.winehq.org/JobDetails.pl?Key=8408
Erich Hoover
ehoo...@mines.edu
diff --git a/dlls/shdocvw/tests/webbrowser.c b/dlls/shdocvw/tests/webbrowser.c
index afde2e1..6f91d44 100644
--- a/dlls/shdocvw/tests/webbrowser.c
+++ b/dlls/shdocvw/tests/webbrowser.c
@@ -886,7 +886,14 @@ static HRESULT WINAPI ClientSite_GetContainer(IOleClientSite *iface, IOleContain
ok(ppContainer != NULL, "ppContainer == NULL\n");
if(ppContainer)
+{
+*ppContainer = NULL;
+
+return E_NOINTERFACE;
+}
+/*
*ppContainer = &OleContainer;
+*/
return S_OK;
}
@@ -2397,6 +2404,30 @@ static void test_Navigate2(IUnknown *unk)
test_ready_state(READYSTATE_LOADING);
}
+static void test_ExecWB(IUnknown *unk)
+{
+IWebBrowser2 *webbrowser;
+enum OLECMDF status;
+HRESULT hres;
+
+hres = IUnknown_QueryInterface(unk, &IID_IWebBrowser2, (void**)&webbrowser);
+ok(hres == S_OK, "QueryInterface(IID_IWebBrowser) failed: %08x\n", hres);
+if(FAILED(hres))
+return;
+
+/* Test a safe operation that exists as both a high-numbered MSHTML id and an OLECMDID */
+status = 0;
+hres = IWebBrowser2_QueryStatusWB(webbrowser, OLECMDID_STOP, &status);
+todo_wine ok(hres == S_OK, "ExecWB failed: %08x\n", hres);
+todo_wine ok(status & OLECMDF_ENABLED, "ExecWB OLECMDID_STOP not enabled: %08x\n", status);
+status = OLECMDF_ENABLED;
+hres = IWebBrowser2_QueryStatusWB(webbrowser, IDM_STOP, &status);
+todo_wine ok(hres == S_OK, "ExecWB failed: %08x\n", hres);
+todo_wine ok(!(status & OLECMDF_ENABLED), "ExecWB IDM_STOP enabled: %08x\n", status);
+
+IWebBrowser2_Release(webbrowser);
+}
+
static void test_download(DWORD flags)
{
MSG msg;
@@ -2875,6 +2906,8 @@ static void test_WebBrowser(BOOL do_download)
test_DoVerb(unk);
test_olecmd(unk, FALSE);
test_Navigate2(unk);
+test_ExecWB(unk);
+return;
if(do_download) {
IDispatch *doc, *doc2;
diff --git a/dlls/shdocvw/webbrowser.c b/dlls/shdocvw/webbrowser.c
index 1a0e189..3c40254 100644
--- a/dlls/shdocvw/webbrowser.c
+++ b/dlls/shdocvw/webbrowser.c
@@ -788,8 +788,21 @@ static HRESULT WINAPI WebBrowser_ExecWB(IWebBrowser2 *iface, OLECMDID cmdID,
OLECMDEXECOPT cmdexecopt, VARIANT *pvaIn, VARIANT *pvaOut)
{
WebBrowser *This = impl_from_IWebBrowser2(iface);
-FIXME("(%p)->(%d %d %s %p)\n", This, cmdID, cmdexecopt, debugstr_variant(pvaIn), pvaOut);
-return E_NOTIMPL;
+IOleCommandTarget* target;
+HRESULT hres;
+
+TRACE("(%p)->(%d %d %s %p)\n", This, cmdID, cmdexecopt, debugstr_variant(pvaIn), pvaOut);
+
+if(!This->doc_host.document)
+return E_FAIL;
+
+hres = IUnknown_QueryInterface(This->doc_host.document, &IID_IOleCommandTarget, (LPVOID*)&target);
+if(FAILED(hres))
+return hres;
+hres = IOleCommandTarget_Exec(target, NULL, cmdID, cmdexecopt, pvaIn, pvaOut);
+IOleCommandTarget_Release(target);
+
+return hres;
}
static HRESULT WINAPI WebBrowser_ShowBrowserBar(IWebBrowser2 *iface, VARIANT *pvaClsid,
Re: [2/2] msi/tests: More tests for publishing and unpublishing assemblies.
Hans Leidekker writes: > --- > dlls/msi/tests/action.c | 84 +- > 1 files changed, 82 insertions(+), 2 deletions(-) This breaks subsequent tests: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so install.c && touch install.ok install.c:4251: Test failed: File not installed install.c:4280: Test failed: File not installed install.c:4283: Test failed: File not installed install.c:4286: Test failed: File not installed install.c:4292: Test failed: File not installed install.c:4624: Tests skipped: Run in interactive mode to run source path tests. install.c:4774: Test failed: Expected ERROR_UNKNOWN_PRODUCT, got 0 wine: Unhandled page fault on read access to 0x at address 0x68875090 (thread 0040), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x68875090). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68875090 ESP:0032e7f0 EBP:0032f098 EFLAGS:00010246( R- -- I Z- -P- ) EAX: EBX:688d1710 ECX:00110064 EDX: ESI:001752c0 EDI:001752e4 Stack dump: 0x0032e7f0: 0012da08 688c1840 000c 0032ee54 0x0032e800: 0134 00c8 0002 0032 0x0032e810: 00c8 0002 00174c30 0x0032e820: 0006 0001 00174c42 0x0032e830: 0004 00174ae0 000c 00174c38 0x0032e840: 000b 688c1840 001749a0 00172cc0 Backtrace: =>0 0x68875090 ready_media+0x300(package=0x1742b8, file=0x1736c8, mi=0x1752c0) [/home/julliard/wine/wine/dlls/msi/../../include/winbase.h:2280] in msi (0x0032f118) 1 0x68866333 ACTION_InstallFiles+0x212(package=0x1742b8) [/home/julliard/wine/wine/dlls/msi/files.c:245] in msi (0x0032f168) 2 0x6883005f ACTION_HandleStandardAction+0xae(package=, action="InstallFiles", rc=0x32f19c) [/home/julliard/wine/wine/dlls/msi/action.c:7315] in msi (0x0032f1b8) 3 0x68831e8f ACTION_PerformAction+0x3e(package=0x1742b8, action="InstallFiles", script=0x) [/home/julliard/wine/wine/dlls/msi/action.c:7338] in msi (0x0032f208) 4 0x68833e8f ITERATE_Actions+0x1de(row=0x16f070, param=0x1742b8) [/home/julliard/wine/wine/dlls/msi/action.c:1009] in msi (0x0032f268) 5 0x688853a0 MSI_IterateRecords+0x6f(view=0x130790, count=0x0(nil), func=0x68833cb0, param=0x1742b8) [/home/julliard/wine/wine/dlls/msi/msiquery.c:193] in msi (0x0032f2b8) 6 0x6882f1d3 ACTION_ProcessExecSequence+0x102(package=0x1742b8, UIran=) [/home/julliard/wine/wine/dlls/msi/action.c:1094] in msi (0x0032f328) 7 0x6883e2e7 MSI_InstallPackage+0x476(package=0x1742b8, szPackagePath="msitest.msi", szCommandLine="INSTALLLEVEL=10 PROPVAR=42") [/home/julliard/wine/wine/dlls/msi/action.c:7517] in msi (0x0032f378) 8 0x6887b563 MsiInstallProductW+0x82(szPackagePath="msitest.msi", szCommandLine="INSTALLLEVEL=10 PROPVAR=42") [/home/julliard/wine/wine/dlls/msi/msi.c:243] in msi (0x0032f3c8) 9 0x68880901 MsiInstallProductA+0x180(szPackagePath="msitest.msi", szCommandLine="INSTALLLEVEL=10 PROPVAR=42") [/home/julliard/wine/wine/dlls/msi/msi.c:218] in msi (0x0032f788) 10 0x686e0523 test_MsiConfigureProductEx+0x3e2() [/home/julliard/wine/wine/dlls/msi/tests/install.c:4778] in msi_test (0x0032fd38) 11 0x686ee4b1 func_install+0x3a50() [/home/julliard/wine/wine/dlls/msi/tests/install.c:6419] in msi_test (0x0032fd88) 12 0x687adc0e run_test+0x15d(name=) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:556] in msi_test (0x0032fe48) 13 0x687ade07 main+0x156(argc=, argv=) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:624] in msi_test (0x0032fe90) 14 0x687ae98c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x0032fea8) 15 0x7b858dac call_process_entry+0xb() in kernel32 (0x0032fee8) 16 0x7b85b61b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fef8) 17 0x7bc73150 call_thread_func+0xb() in ntdll (0x0032ffc8) 18 0x7bc73320 call_thread_entry_point+0x6f(entry=0x7b85b5c0, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2475] in ntdll (0x0032ffe8) 19 0x7bc4dd2a start_process+0x29(kernel_start=0x7b85b5c0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2606] in ntdll (0x) 0x68875090 ready_media+0x300 [/home/julliard/wine/wine/dlls/msi/../../include/winbase.h:2280] in msi: movzwl 0x0(%edx,%eax,1),%ecx 2280while ((*p++ = *src++)); -- Alexandre Julliard julli...@winehq.org
Re: [4/4] shdocvw: Implement basic back/forward history support (resend)
Hi Owen, On 1/18/11 1:35 AM, Owen Rudge wrote: This resend removes a superfluous function. Parts 1-3 are unaffected. --- dlls/shdocvw/dochost.c|1 + dlls/shdocvw/ie.c |6 +--- dlls/shdocvw/iexplore.c | 12 +++- dlls/shdocvw/navigate.c | 66 + dlls/shdocvw/resource.h |2 + dlls/shdocvw/shdocvw.h| 12 dlls/shdocvw/webbrowser.c |6 +--- 7 files changed, 95 insertions(+), 10 deletions(-) First of all, tests please. Navigation history is more complicated than your approach. The most important thing is that documents reporting DOCHOST_DOCCANNAVIGATE are handling navigation themselves. HTMLDocument, about which we care the most, is such document. It means that most of the work should be done in mshtml and shdocvw should only notify mshtml about navigation back/forward. diff --git a/dlls/shdocvw/iexplore.c b/dlls/shdocvw/iexplore.c index 3b652cb..cac04a3 100644 --- a/dlls/shdocvw/iexplore.c +++ b/dlls/shdocvw/iexplore.c This part is fine can be a separated patch. Jacek
Re: [PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.
On 1/17/11 9:28 PM, Erich Hoover wrote: On Sun, Jan 16, 2011 at 1:01 PM, Jacek Caban wrote: Please write a test case for this. MSDN seems wrong in this case. It indicates in one place that we should use CGID_MSHTML as group GUID, and NULL in the other. The test should make it clean, which version is true. I've looked into trying to do this test case and I'm at a bit of a loss. It appears that whatever I try to do the "webbrowser" tests hijack the IOleCommandTarget, so I'm not really testing what the "real" target does. It instead calls the test-specific OleCommandTarget_QueryStatus, though that test does not report any error on the ever-so-significant line: ok(!pguidCmdGroup, "pguidCmdGroup != MULL\n"); I'm not sure what you mean by "hijack the IOleCommandTarget". All we do is implementing client's IOleCommandTarget. It's something different from document's one. On a side note, do I need to resend the other two patches in that set? They are not dependent on this patch. Probably yes. Jacek
