Re: [PATCH 3/4] shell32: Some events are sent twice in SHChangeNotify
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=7032 Your paranoid android. === W98SE (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called === WNT4WSSP6 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W2KPROSP4 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === WVISTAADM (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W2K8SE (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PRO (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PROX64 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PROX64 (64 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called
Re: loader: On Mac, reserve the process's original thread for the frameworks. (try 2)
On Nov 12, 2010, at 5:14 AM, Alexandre Julliard wrote: > Ken Thomases writes: > >> +/* This is a hack. We want to wait until the main thread has >> + * really exited in response to our signal. However, Mac OS X >> + * doesn't let us join the main thread for whatever reason. >> + * It results in a SIGBUS. So, we just sleep for a bit and hope >> + * it got enough time. */ >> +usleep(100); > > We need something more reliable than this. I can't think of what it might be. I can wait for an acknowledgment from the main thread that the source callback has fired but that doesn't get us any closer to knowing when it has actually exited. (Before I encountered the pthread_join bug, the callback was actually passing the main thread's pthread_t back to terminate_main_thread with appropriate synchronization. So, I'm not averse to having such two-way communication, but once I gave up on pthread_join, I backed all of that out as only giving false confidence.) The same applies to pthread cancellation cleanup handlers and thread-specific data destructors. They happen very late in the thread's lifetime, but don't let us know it's actually gone (such that execve will succeed). I'm open to suggestions. pthread_join is really the only correct tool for this job. Of course, any fix for pthread_join won't help. It will (obviously) come in some future version of Mac OS X, while the ENOTSUP from execve has already been solved in Snow Leopard. So, in reality, terminating the main thread is only necessary on Leopard and there won't be any fixes forthcoming for that version. I have been treating this as a best-effort sort of situation. Should the attempt to terminate the main thread fail, we'll just go ahead and attempt the exec, anyway. Either it will succeed or it won't. (For what it's worth, create_process has some work yet to do after terminate_main_thread returns before it attempts the exec. So, there's a bit more than just that usleep, not that that makes it any more of a sure thing.) I suppose we could put a loop around the exec call, such that we sleep and retry if it returns ENOTSUP. However, if terminate_main_thread was unsuccessful, or if ENOTSUP can occur for other reasons, that might be an infinite loop. Regards, Ken
Help with 'WineAPI' wiki
As I mentioned before, I am trying to establish a place where the Windows API can be discussed that is not under the control of Microsoft. While the name I have chosen is debatable, it is not beyond reason and conveys enough about its intended contents that it should not be too hard to find. It currently consists of two major pieces: * The Wine piece follows the distribution directory structure with pages for each directory and many of the files. * The API piece currently consists of an index of all the APIs I found in the .spec files. * Other projects that use the windows API can put the information specific to their project in directory trees similar to the one I have set up for Wine. I am having a few specific problems: * Some of the .spec files contain more information than can be displayed on a single Wiki page. This information has to be split up into a reasonable number of sub-pages and organized so the information needed can be found fairly easily. I can handle the technical aspects of setting up the pages, and have some idea of where the splits should be, but I am uncertain enough that I want advice. * This is the first Wiki I have had administrative responsibility for and I frankly do not know what I am doing. Advice and help with the administration of the Wiki and the project would help. * Some of the technical choices have been based on my technical limits. I am simply ignorant of possible alternatives. Again, I think advice would help. * I know some of the sections are just plain ugly. I am mostly concerned with getting accurate and current information into the Wiki at this point, but the presentation does need improvement and again, I think some advice would be helpful. * My dyslexia has bitten me more than once. Someone to review what I am doing might help. - Max
Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 6
On 11/9/10 12:49 PM, Charles Davis wrote: > What's wrong now? I still don't know what's wrong. Chip
Re: regedit: add a manpage
On Fri, Nov 12, 2010 at 7:29 PM, Alexandre Julliard wrote: > Austin English writes: > >> I wasn't worried about the patches being under my name. I'll email the >> author and ask him to submit them, but I'm not holding my breath, >> since the Debian wine package is very out of date and inactive. If I >> don't receive a response in a week or so, would it be okay to submit >> it under the original author's name? > > Only if there is clear evidence that the original author agreed to > distribute it under the LGPL. Sure, better safe than sorry. The Debian copyright file shows that the software is released under the LGPL: http://packages.debian.org/changelogs/pool/main/w/wine-unstable/wine-unstable_1.1.32-1/copyright and you can see when the manpage was added in the changelog: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284305 http://packages.debian.org/changelogs/pool/main/w/wine/wine_1.1.24-2/changelog.txt if that's not clear enough, I'll wait for a response from Francois. -- -Austin
Re: regedit: add a manpage
Austin English writes: > I wasn't worried about the patches being under my name. I'll email the > author and ask him to submit them, but I'm not holding my breath, > since the Debian wine package is very out of date and inactive. If I > don't receive a response in a week or so, would it be okay to submit > it under the original author's name? Only if there is clear evidence that the original author agreed to distribute it under the LGPL. -- Alexandre Julliard julli...@winehq.org
Re: regedit: add a manpage
On Fri, Nov 12, 2010 at 11:10 AM, Alexandre Julliard wrote: > Austin English writes: > >> While looking at the Debian Wine sources, I found they have manpages >> for several of our bulitin programs :-) > > Then you should ask them to submit patches. You can't just grab the > manpages and submit under your name. I wasn't worried about the patches being under my name. I'll email the author and ask him to submit them, but I'm not holding my breath, since the Debian wine package is very out of date and inactive. If I don't receive a response in a week or so, would it be okay to submit it under the original author's name? FWIW, The original author's name remains in the file, though I did make a few corrections. -- -Austin
re: d3d9: Improve CheckDeviceState stub to run Firefox 4 Beta 7
I think that's a clue that you need a better name than 'i'. Maybe 'fixme_shown'.
Re: [2/11] update Simplified Chinese translation: notepad
On 11/12/2010 02:26 PM, cheer_xiao wrote: Here is my update for the Simplified Chinese translation. I have "make"d all corresponding files to ensure that they don't get broken. Copyright info has been included (if not present). Hi, Most of your emails don't contain the actual patches. -- Cheers, Paul.
Re: [PATCH 1/4] shdocvw: Implement DocHostUIHandler::TranslateAccelerator.
Hi David,
On 11/12/10 8:49 AM, David Hedberg wrote:
---
dlls/shdocvw/dochost.c |9 +-
dlls/shdocvw/tests/webbrowser.c | 251 ++-
2 files changed, 253 insertions(+), 7 deletions(-)
diff --git a/dlls/shdocvw/tests/webbrowser.c b/dlls/shdocvw/tests/webbrowser.c
index babfe11..fd1c7f8 100644
--- a/dlls/shdocvw/tests/webbrowser.c
+++ b/dlls/shdocvw/tests/webbrowser.c
@@ -122,8 +122,12 @@ DEFINE_EXPECT(QueryStatus_SETPROGRESSTEXT);
DEFINE_EXPECT(QueryStatus_STOP);
DEFINE_EXPECT(DocHost_EnableModeless_TRUE);
DEFINE_EXPECT(DocHost_EnableModeless_FALSE);
+DEFINE_EXPECT(DocHost_TranslateAccelerator);
DEFINE_EXPECT(GetDropTarget);
DEFINE_EXPECT(TranslateUrl);
+DEFINE_EXPECT(ShowUI);
+DEFINE_EXPECT(HideUI);
+DEFINE_EXPECT(RequestUIActivate);
static const WCHAR wszItem[] = {'i','t','e','m',0};
static const WCHAR emptyW[] = {0};
@@ -133,6 +137,7 @@ static IWebBrowser2 *wb;
static HWND container_hwnd, shell_embedding_hwnd;
static BOOL is_downloading, is_first_load;
+static HRESULT hr_dochost_TranslateAccelerator = E_NOTIMPL;
static const char *current_url;
#define DWL_EXPECT_BEFORE_NAVIGATE 0x01
@@ -249,6 +254,10 @@ static HRESULT WINAPI
OleCommandTarget_Exec(IOleCommandTarget *iface, const GUID
{
if(!pguidCmdGroup) {
switch(nCmdID) {
+case OLECMDID_UPDATECOMMANDS:
+ok(nCmdexecopt == 2, "nCmdexecopts=%08x\n", nCmdexecopt);
+ok(pvaIn == NULL, "Got non-null pvaIn\n");
+break;
This should also use CHECK_EXPECT()
case OLECMDID_SETPROGRESSMAX:
CHECK_EXPECT2(Exec_SETPROGRESSMAX);
ok(nCmdexecopt == OLECMDEXECOPT_DONTPROMPTUSER,
"nCmdexecopts=%08x\n", nCmdexecopt);
@@ -1128,7 +1137,7 @@ static HRESULT WINAPI
InPlaceSite_OnInPlaceDeactivateEx(IOleInPlaceSiteEx *iface
static HRESULT WINAPI InPlaceSite_RequestUIActivate(IOleInPlaceSiteEx *iface)
{
-ok(0, "unexpected call\n");
+CHECK_EXPECT2(RequestUIActivate);
return S_OK;
}
@@ -1195,13 +1204,13 @@ static HRESULT WINAPI
DocHostUIHandler_ShowUI(IDocHostUIHandler2 *iface, DWORD d
IOleInPlaceActiveObject *pActiveObject, IOleCommandTarget
*pCommandTarget,
IOleInPlaceFrame *pFrame, IOleInPlaceUIWindow *pDoc)
{
-ok(0, "unexpected call\n");
+CHECK_EXPECT(ShowUI);
return E_NOTIMPL;
}
static HRESULT WINAPI DocHostUIHandler_HideUI(IDocHostUIHandler2 *iface)
{
-ok(0, "unexpected call\n");
+CHECK_EXPECT(HideUI);
return E_NOTIMPL;
}
@@ -1243,8 +1252,12 @@ static HRESULT WINAPI
DocHostUIHandler_ResizeBorder(IDocHostUIHandler2 *iface, L
static HRESULT WINAPI
DocHostUIHandler_TranslateAccelerator(IDocHostUIHandler2 *iface, LPMSG lpMsg,
const GUID *pguidCmdGroup, DWORD nCmdID)
{
-ok(0, "unexpected call\n");
-return E_NOTIMPL;
+CHECK_EXPECT(DocHost_TranslateAccelerator);
+ok(pguidCmdGroup != NULL, "Got NULL pguidCmdGroup.\n");
+if(pguidCmdGroup)
+ok(IsEqualGUID(pguidCmdGroup,&CGID_MSHTML), "Unexpected
pguidCmdGroup\n");
+ok(lpMsg != NULL, "Got NULL lpMsg.\n");
+return hr_dochost_TranslateAccelerator;
}
static HRESULT WINAPI DocHostUIHandler_GetOptionKeyPath(IDocHostUIHandler2
*iface,
@@ -2483,6 +2496,233 @@ static void test_QueryInterface(IUnknown *unk)
}
+static void translate_messages(void)
+{
+MSG msg;
+UINT i;
+for(i = 0; i< 100; i++) {
+while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
+TranslateMessage(&msg);
+DispatchMessage(&msg);
+}
+Sleep(5);
+}
+}
+static void test_TranslateAccelerator(IUnknown *unk)
+{
+IWebBrowser2 *pwb2;
+IOleObject *pobj;
+HRESULT hr;
+DWORD keycode;
+IDispatch *disp_html;
+VARIANT url;
+MSG msg_a = {
+container_hwnd,
+0, 0, 0,
+GetTickCount(),
+{5, 5}
+};
+
+is_downloading = TRUE;
+
+hr = IUnknown_QueryInterface(unk,&IID_IWebBrowser2, (void**)&pwb2);
+ok(hr == S_OK, "Got 0x%08x\n", hr);
+if(FAILED(hr)) {
+skip("Failed to get IWebBrowser2\n"); /* This should never happen */
+return;
+}
+
+disp_html = (void*)0xdeadbeef;
+hr = IWebBrowser2_get_Document(pwb2,&disp_html);
+todo_wine ok(hr == S_FALSE || broken(hr == S_OK) /*< IE7 */, "Got
0x%08x\n", hr);
+ok(disp_html == NULL, "Received doc.\n");
+if(disp_html != NULL)
+IDispatch_Release(disp_html);
+
+/* Activate */
+SET_EXPECT(GetContainer);
+SET_EXPECT(Site_GetWindow);
+SET_EXPECT(Invoke_AMBIENT_OFFLINEIFNOTCONNECTED);
+SET_EXPECT(Invoke_AMBIENT_SILENT);
+
+hr = IUnknown_QueryInterface(unk,&IID_IOleObject, (void**)&pobj);
+ok(hr == S_OK, "Got 0x%08x\n", hr);
+if(SUCCEEDED(hr)) {
+hr = IOleObject_SetClientSite(pobj,&ClientSite);
+ok(hr == S_OK, "SetClientSite failed: %08x\n", hr);
+
+IOleObject_Release(pobj);
+}
+
+CHECK_CALLED(GetC
Re: loader: On Mac, reserve the process's original thread for the frameworks. (try 2)
Ken Thomases writes:
> +{
> +CFRunLoopAddSource( CFRunLoopGetMain(), source,
> kCFRunLoopCommonModes );
> +CFRunLoopSourceSignal( source );
> +CFRunLoopWakeUp( CFRunLoopGetMain() );
> +CFRelease( source );
> +
> +/* This is a hack. We want to wait until the main thread has
> + * really exited in response to our signal. However, Mac OS X
> + * doesn't let us join the main thread for whatever reason.
> + * It results in a SIGBUS. So, we just sleep for a bit and hope
> + * it got enough time. */
> +usleep(100);
We need something more reliable than this.
(The pthread_join crash is a bug in libsystem, I filed a bug a while
back but haven't heard anything).
--
Alexandre Julliard
julli...@winehq.org
Re: regedit: add a manpage
Austin English writes: > While looking at the Debian Wine sources, I found they have manpages > for several of our bulitin programs :-) Then you should ask them to submit patches. You can't just grab the manpages and submit under your name. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/2] msvcrt: Added qsort_s implementation. (try 4)
"Vincas Miliūnas" writes:
> +/*
> + * Helper function for MSVCRT_qsort_s.
> + *
> + * Based on http://github.com/git/git/blob/master/compat/qsort.c
> + *
> + */
We already have a qsort in ntdll, I'd suggest to copy that (and/or merge
possible improvements into it). We don't need two implementations from
two different sources.
> +/*
> + * qsort_s (MSVCRT.@)
> + *
> + * Based on http://github.com/git/git/blob/master/compat/qsort.c
> + *
> + */
> +void CDECL MSVCRT_qsort_s(void *b, size_t n, size_t s,
> +_QSORT_S_COMPARE_FN cmp, void *context)
> +{
> +const size_t size = n * s;
You probably want to check for overflow.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 4/4] shdocvw: Implement InPlaceActiveObject::TranslateAccelerator.
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=7011 Your paranoid android. === WVISTAADM (32 bit webbrowser) === webbrowser.c:1308: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP === W2K8SE (32 bit webbrowser) === webbrowser.c:1308: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP webbrowser.c:1308: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP webbrowser.c:301: Test failed: unexpected nsCmdID 28 === W7PRO (32 bit webbrowser) === webbrowser.c:1308: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP
Re: [PATCH] console: fix output for console handles opened with GENERIC_WRITE access
this has already been discussed on wine-devel a couple of days ago
the "right" fix is either to fix WriteConsole so that it doesn't require
read access (actually FILE_READ_PROPERTIES), or to grant this access user
side
so the fix in the server will be rejected
A+
2010/11/12 Martin Wilck
>
> Writing to a console handle obtained with a requested access mode
> GENERIC_WRITE
> produces no output. This happens because get_console_mode() requires
> FILE_READ_PROPERTIES access on the handle, which a handle created with
> GENERIC_WRITE doesn't have.
>
> This affects many Microsoft console applications, e.g. nmake and cl from
> VC++
> express 2005.
>
> It can be tested with the following minimal test program (compiled with
> VC 2005 & run with native mscvr80):
>
> int main(void)
> {
>_cprintf("Hi.\n");
>return 0;
> }
>
> This behaves as follows:
>
> trace:console:OpenConsoleW (L"CONOUT$", 0x4000, 0, 3)
> 0009: open_console( from=0001, access=4000, attributes=,
> share=3 )
> 0009: open_console() = 0 { handle=0028 }
> trace:console:WriteConsoleW 0x2b L"H" 1 0x33fb78 (nil)
> 0009: get_console_mode( handle=0028 )
> 0009: get_console_mode() = ACCESS_DENIED { mode=0, is_bare=0 }
>
> Because of the ACCESS_DENIED, this program produces no output on current
> wine.
> This patch fixies this with a new map_access() function for the console.
>
> Signed-off-by: Martin Wilck
> ---
> server/console.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
>
>
--
--
Eric Pouech
Re: [PATCH 3/4] shdocvw: Implement ControlSite::TranslateAccelerator.
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=7010 Your paranoid android. === WVISTAADM (32 bit webbrowser) === webbrowser.c:1301: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP === W7PRO (32 bit webbrowser) === webbrowser.c:1301: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP
Re: [PATCH 1/4] shdocvw: Implement DocHostUIHandler::TranslateAccelerator.
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=7009 Your paranoid android. === WVISTAADM (32 bit webbrowser) === webbrowser.c:1219: Test failed: unexpected call UpdateUI webbrowser.c:238: Test failed: unexpected call QueryStatus_STOP === W2K8SE (32 bit webbrowser) === webbrowser.c:1219: Test failed: unexpected call UpdateUI webbrowser.c:238: Test failed: unexpected call QueryStatus_STOP webbrowser.c:1219: Test failed: unexpected call UpdateUI webbrowser.c:238: Test failed: unexpected call QueryStatus_STOP webbrowser.c:298: Test failed: unexpected nsCmdID 28 === W7PRO (32 bit webbrowser) === webbrowser.c:1219: Test failed: unexpected call UpdateUI webbrowser.c:238: Test failed: unexpected call QueryStatus_STOP === W7PROX64 (32 bit webbrowser) === webbrowser.c:1219: Test failed: unexpected call UpdateUI webbrowser.c:238: Test failed: unexpected call QueryStatus_STOP
