Re:cmd: /r is equivalent to /c
Concept of patch is fine (and we ought to support it), but I dont think this would work as coded (if (tolowerW(c)=='c'||'r') will always be true). Also, can you add a quick test for it (there's cmd.exe /c tests - just add a cmd.exe /r echo test worked). PS You might want to just hold off until the patch I submitted last night gets committed as well otherwise there will be merge conflicts (Change command line parsing away from argv/argc)
Re: [PATCH 1/3] hhctrl.ocx: Fix removing a window from the help list when window creation fails.
On 10/02/12 23:02, Erich E. Hoover wrote: If a cleanup occurs because HTML Help window creation fails then list_remove() causes a crash, since the window was never added to the window list. The attached patch fixes this issue, allowing safe reloading of files (needed for part 2). This looks like a hack. It would be better to have always valid list entry (if this really can't be added to the list earlier, you may always initialize it by list_init) or make sure to not call ReleaseHelpViewer before HHInfo is fully initialized. Jacek
Re: imm32: have IMM class return TRUE for WM_QUERYENDSESSION
Aric Stewart a...@codeweavers.com writes: resolves bug 31832 --- dlls/imm32/imm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Is there any reason why we are not simply calling DefWindowProc? -- Alexandre Julliard julli...@winehq.org
Re: wininet: Fixed failing test
Piotr Caban pi...@codeweavers.com wrote: -ok(ret, GetUrlCacheEntryInfoExW failed with error %d\n, GetLastError()); +ok(ret || broken(!ret) /* IE6 */, GetUrlCacheEntryInfoExW failed with error %d\n, GetLastError()); This kind of blanket test results coverage is broken from the start. -- Dmitry.
Re: [2/2] vbscript: Support vb* constants for message box return value
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=21979 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [1/2] vbscript: Support vb* constants for message box buttons
Hi Nikolay, On 10/03/12 13:34, Nikolay Sivov wrote: Support vb* constants for message box buttons How about using MB_* constants from winuser.h instead of hardcoding them here? Other than that, the patch looks good to me. Jacek
Re: [2/2] oledb32: Add support for IDBInitialize interface in IDataInitialize
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=21975 Your paranoid android. === WNT4WSSP6 (32 bit marshal) === marshal.c:66: Test failed: CoMarshalInterface failed with error 0x80040155 marshal.c:239: Test failed: CoUnmarshalInterface failed with error 0x8003001e marshal: unhandled exception c005 at 004165D0
Re: [1/2] vbscript: Support vb* constants for message box buttons
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=21978 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [1/2] vbscript: Support vb* constants for message box buttons
On 10/3/2012 13:54, Jacek Caban wrote: Hi Nikolay, On 10/03/12 13:34, Nikolay Sivov wrote: Support vb* constants for message box buttons How about using MB_* constants from winuser.h instead of hardcoding them here? Other than that, the patch looks good to me. Jacek Sure, that would be cleaner. I sent updated version, thanks.
Re: [1/2] vbscript: Support vb* constants for message box buttons (try2)
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=21980 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [2/2] vbscript: Support vb* constants for message box return value (try2)
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=21981 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: imm32: have IMM class return TRUE for WM_QUERYENDSESSION
Looking over my documentation it is explicit about many messages that cannot be passed to DefWndProc, but it looks like we can us it. I will revise the patch and send that. -aric On 10/3/12 4:31 AM, Alexandre Julliard wrote: Aric Stewart a...@codeweavers.com writes: resolves bug 31832 --- dlls/imm32/imm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Is there any reason why we are not simply calling DefWindowProc?
Re: AppDB: Could someone please block this Spammer (UCE)
Am 03.10.2012 05:01, schrieb Rosanne DiMesio: On Tue, 2 Oct 2012 23:48:22 +0200 newsletter [at] Schiermeier-Software newslet...@schiermeier-software.de wrote: Please Rosane, help us...! Thanks a lot! I'd love to, but if the AppDB has a way to ban users, I don't have access to it. I've already deleted the comments from the Office 2007 page (twice), and it looks like someone else deleted them from the Photoshop page. I tried deleting the spammer's account, and the system asked me if I really wanted to, but it didn't delete it even after I said yes. I'm not sure that would have helped anyway, as he could easily just create a new account. We really do need some sort of moderation for AppDB comments similar to what's on the forum. The spammer's display name is menujusukses, email is rian_barka...@ymail.com. The delete routines look good, can't tell why they don't work. I can't find a ban function... @Alexander: could you have a look at this problem, this user seems to spam some days now and Rosane can't delete him. Maybe we should forward wine-bugs to his e-mail address to spam back ;) -- Best Regards, André Hentschel
Re: [PATCH] rpcrt4: wait_async_request: return error if we received an error
On Tue, Oct 02, 2012 at 01:19:37PM +0200, Jacek Caban wrote:
Hi Marcus,
On 10/01/12 23:00, Marcus Meissner wrote:
Hi,
Various coverity issues complain about user-after-free scenarios,
all involving this code path.
I strongly think if call_ret signals error, we also need to return
an error condition to avoid the callers from proceeding as if nothing
happened.
Second reiteration with Jaceks comment applied
Sorry for not catching this later, I was concentrated on your comment
instead of the code, but the important thing is that true call_ret means
success (and wininet doing request asynchronously is signalled as an
error). It means that in this case we want to return RPC_S_OK. What is
the exact problem?
Ok, my fix was likely bad.
Coverity is spotting use-after-free scenarios.
CID 715805
rpcrt4_http_prepare_in_pipe()
/* prepare in pipe */
status = send_echo_request(in_request, async_data, cancel_event);
if (status != RPC_S_OK) return status;
... here it thinks async_data might be returned freed in the non-async case ...
memset(buffers_in, 0, sizeof(buffers_in));
buffers_in.dwStructSize = sizeof(buffers_in);
/* FIXME: get this from the registry */
buffers_in.dwBufferTotal = 1024 * 1024 * 1024; /* 1Gb */
prepare_async_request(async_data);
... but it is again referenced here ...
ret = HttpSendRequestExW(in_request, buffers_in, NULL, 0, 0);
status = wait_async_request(async_data, ret, cancel_event);
if (status != RPC_S_OK) return status;
send_echo_request() looks like:
static RPC_STATUS send_echo_request(HINTERNET req, RpcHttpAsyncData
*async_data, HANDLE cancel_event)
{
DWORD bytes_read;
BYTE buf[20];
BOOL ret;
RPC_STATUS status;
prepare_async_request(async_data);
ret = HttpSendRequestW(req, NULL, 0, NULL, 0);
status = wait_async_request(async_data, ret, cancel_event);
if (status != RPC_S_OK) return status;
status = rpcrt4_http_check_response(req);
if (status != RPC_S_OK) return status;
InternetReadFile(req, buf, sizeof(buf), bytes_read);
/* FIXME: do something with retrieved data */
return RPC_S_OK;
}
so with the bumped reference count via prepare_async_request I think it might
be safe here.
(and so is a coverity misdetection I think now)
Ciao, Marcus
Re: AppDB: Could someone please block this Spammer (UCE)
Hello Rosanne, sorry for misspelling your first name in my mail before. I tried deleting the spammer's account, and the system asked me if I really wanted to, but it didn't delete it even after I said yes. I'm not sure that would have helped anyway, as he could easily just create a new account. couldn't you simply reset the spammers password? So if his account is powned he will have to get a new one. We really do need some sort of moderation for AppDB comments similar to what's on the forum. In general this is a good idea. -- Regards Joerg Schiermeier Bielefeld/Germany
Re: AppDB: Could someone please block this Spammer (UCE)
Hello André, AH In the meantime you could change your preferences in the appdb (Send email notifications) Than I'm in peace - that's right. But this have a side-effect: I also will not be informed by AppDB if someone add a new test or a comment in my attended applications: the mails to remain an applications maintainer to do his work are also switched off. This isn't really what I want. -- Kindly regards Joerg Schiermeier Bielefeld/Germany
Re: AppDB: Could someone please block this Spammer (UCE)
On Wed, 3 Oct 2012 16:24:54 +0200 Joerg Schiermeier newslet...@schiermeier-software.de wrote: Hello André, AH In the meantime you could change your preferences in the appdb (Send email notifications) Than I'm in peace - that's right. But this have a side-effect: I also will not be informed by AppDB if someone add a new test or a comment in my attended applications: the mails to remain an applications maintainer to do his work are also switched off. This isn't really what I want. My Preferences screen has an option to Disable global e-mail notifications (only send for maintained apps), but I'm not sure if that's something only admins have. -- Rosanne DiMesio dime...@earthlink.net
Re: ImmIsUIMessageA/W
Great! Looking at the application I have that was requiring this i have found that by adding the IME window class it has actually corrected its behavior. You are correct to have removed that redirection and I will not submit a patch to re-add it as it is incorrect. thanks for the help! -aric On 10/2/12 5:34 PM, André Hentschel wrote: Am 02.10.2012 21:23, schrieb Aric Stewart: I have a proposed patch that I have tested with World of Tanks and it does not cause http://bugs.winehq.org/show_bug.cgi?id=27554 to reappear for me on either mac or Linux. Would you be able to test it and confirm that I am not reintroduction the issues? doesn't work here with WoT v0.6.4, after loading i get a black screen caused by a loop: $WINEDEBUG=imm WINEPREFIX=~/.winewot/ wine WorldOfTanks.exe err:menubuilder:init_xdg error looking up the desktop directory trace:imm:DllMain 0x7df3, 1, 0x1 fixme:win:EnumDisplayDevicesW ((null),0,0xeb0518,0x), stub! fixme:win:EnumDisplayDevicesW ((null),1,0xeb0518,0x), stub! trace:imm:DllMain 0x7e59, 1, (nil) trace:imm:ImmGetContext (nil) trace:imm:ImmGetContext (nil) fixme:win:EnumDisplayDevicesW ((null),0,0x32eafc,0x), stub! trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 3, (nil) trace:imm:DllMain 0x7df3, 2, (nil) fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:d3d:swapchain_init The application requested more than one back buffer, this is not properly supported. Please configure the application to use double buffering (1 back buffer) if possible. fixme:d3d:wined3d_swapchain_set_gamma_ramp Ignoring flags 0x1. trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) fixme:avrt:AvSetMmThreadCharacteristicsW (LAudio,0x4aaea24): stub trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) fixme:d3d9:Direct3DShaderValidatorCreate9 stub fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 3, (nil) ImportError: No module named BWAutoImport trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) fixme:d3d:resource_check_usage Unhandled usage flags 0x8. trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) trace:imm:DllMain 0x7df3, 2, (nil) fixme:win:EnumDisplayDevicesW ((null),0,0x32e940,0x), stub! fixme:d3d:resource_check_usage Unhandled usage flags 0x8. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. trace:imm:ImmIsUIMessageW ((nil), 200, 0, 25166336) trace:imm:ImmIsUIMessageW ((nil), ff, 0, 2024552) trace:imm:ImmIsUIMessageW ((nil), ff, 0, 2024552) fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of other threads trace:imm:ImmGetContext 0x20058 trace:imm:IMM_GetThreadData Thread Data Created trace:imm:IMM_GetImmHkl Seeking ime for keyboard 0x4070407 trace:imm:LoadDefaultWineIME Attempting to fall back to wine default IME trace:imm:ImeInquire trace:imm:ImeSelect 0x14970fd8 TRUE trace:imm:ImmGetDefaultIMEWnd Default is 0x20062 trace:imm:IMM_GetImmHkl Seeking ime for keyboard 0x4070407 trace:imm:ImmCreateContext Created context 0x14970fd8 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:ImmGetConversionStatus 0x14970fd8 0x32f024 0x32f028 trace:imm:ImmSetOpenStatus 0x14970fd8 1 trace:imm:IME_WindowProc Incoming Message 0x81 (0x, 0x0032ef6c) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Incoming Message 0x83 (0x, 0x0032edb4) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Non-standard message 0x83 trace:imm:IME_WindowProc Incoming Message 0x1 (0x, 0x0032ef6c) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Incoming Message 0xc (0x, 0x0032e2f0) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Non-standard message 0xc trace:imm:IME_WindowProc Incoming Message 0x5 (0x, 0x00010001) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Non-standard message 0x5 trace:imm:IME_WindowProc Incoming Message 0x3 (0x, 0x) trace:imm:ImmGetContext 0x20058 trace:imm:ImmGetContext returning 0x14970fd8 trace:imm:IME_WindowProc Non-standard message 0x3 trace:imm:ImmNotifyIME (0x14970fd8, 3, 0, 6) trace:imm:NotifyIME 0x14970fd8 3 0 6 trace:imm:NotifyIME IMC_SETOPENSTATUS trace:imm:ImmGetDefaultIMEWnd Default is 0x20062 trace:imm:IMM_GetImmHkl
Re: ImmIsUIMessageA/W
Am 03.10.2012 17:19, schrieb Aric Stewart: Great! Looking at the application I have that was requiring this i have found that by adding the IME window class it has actually corrected its behavior. You are correct to have removed that redirection and I will not submit a patch to re-add it as it is incorrect. thanks for the help! -aric Great, thanks for resolving this!
Re: [PATCH 2/2] vbscript: Added Right() implementation
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=21987 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH] rpcrt4: wait_async_request: return error if we received an error
On 10/03/12 14:57, Marcus Meissner wrote: On Tue, Oct 02, 2012 at 01:19:37PM +0200, Jacek Caban wrote: Hi Marcus, On 10/01/12 23:00, Marcus Meissner wrote: Hi, Various coverity issues complain about user-after-free scenarios, all involving this code path. I strongly think if call_ret signals error, we also need to return an error condition to avoid the callers from proceeding as if nothing happened. Second reiteration with Jaceks comment applied Sorry for not catching this later, I was concentrated on your comment instead of the code, but the important thing is that true call_ret means success (and wininet doing request asynchronously is signalled as an error). It means that in this case we want to return RPC_S_OK. What is the exact problem? Ok, my fix was likely bad. Coverity is spotting use-after-free scenarios. CID 715805 I restored my login in Coverity and looked at the report. It seems to be false positive. async_data is reference counted structure and we'll never free it in mentioned wait_async_request because we still store the reference in caller. Cheers, Jacek
Re: [PATCH] advapi32: avoid memory leaks (Coverity)
Marcus Meissner mar...@jet.franken.de writes:
@@ -530,8 +530,10 @@ static void test_enum_providers(void)
/* alloc provider to half the size required
* cbName holds the size required */
providerLen = cbName / 2;
- if (!(provider = LocalAlloc(LMEM_ZEROINIT, providerLen)))
+ if (!(provider = LocalAlloc(LMEM_ZEROINIT, providerLen))) {
+ LocalFree(pszProvName);
return;
+}
Actually, checking for allocation failures in tests is not useful, it's
not going to happen.
--
Alexandre Julliard
julli...@winehq.org
Re: AppDB: Could someone please block this Spammer (UCE)
Hello Rosanne, you wrote: RD My Preferences screen has an option to Disable global e-mail RD notifications (only send for maintained apps), but I'm not sure RD if that's something only admins have. I think you're right: in my prefs I only see 'Send email notifications' with 'yes' and 'no'. Maybe a reason to file a 'bug/missing function in AppDB' in wines Bugzilla? (Or a patch ;) Will do it later to hold this point in mind. Thanks for your respond. -- Kindly regards Joerg Schiermeier Bielefeld/Germany
Re: Overriding the check for ownership of a prefix
On 9/19/12 5:23 PM, Scott Ritchie wrote: So, I believe I have a legitimate use case for ignoring this, and want to know what sort of patch would go forward. Imagine a distro package containing a Windows game in the form of a read-only copy of an installed prefix (into, say, /opt). When the user launches the app (via desktop file) this in turn launches a script that does the following: 1) Makes a temporary folder 2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the read-only packaged prefix in /opt, mounted in the temporary folder 3) Runs the app with WINEPREFIX= the temp folder 4) When the app is finished, unmounts the temp folder This all works quite fine: new (or modified) files within the prefix get stored in ~/.appname, to be restored the next time the user runs the app. Distinct users can run the app simultaneously, as they each have their own prefix. Excess file-copying is avoided, as only the user-modified files need to be stored in the home folders. There is one major snag, however: unionfs displays the owner as root until the user has modified/copied it. This means Wine refuses to launch as the user with the root-owned prefix. Simply commenting out this part of the code makes Wine work fine, however I'd like to be able to have a proper solution. I have found a better solution: you can use standard FUSE options to mask the true owner such that it is always presented as the mounting user, even if the file is untouched.
Re: AppDB: Could someone please block this Spammer (UCE)
On Wednesday, October 3, 2012 at 17:13:21 Rosanne DiMesio wrote: My Preferences screen has an option to Disable global e-mail notifications (only send for maintained apps), but I'm not sure if that's something only admins have. I (just) filed this under the bug #31880 in wines Bugzilla. -- Kindly regards Joerg Schiermeier Bielefeld/Germany
Re: shell32/tests: Simplify shlexec's test_argify() and test_lpFile_parsed() and avoid numeric literals.
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=21998 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: shell32/tests: Write proper tests for CommandLineToArgvW(). (try2)
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=22000 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: shell32/tests: Write proper tests for CommandLineToArgvW(). (try2)
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=21999 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Help getting amd64 assembly patch into wine?
As you might know from watching too many of my patches
scroll by, I've been working on adding support
for OpenMP to wine. (A handful of games, and a lot
of serious apps, seem to use that api.) After getting
it nicely organized and cleaned up to the point where it
passed all the tests I could throw at it, I submitted it as
http://source.winehq.org/patches/data/90524,
Alexandre rejected the patch, saying it had multiple problems,
but declining to provide any further hints.
He suggested I find someone to work with to get it in...
so here I am, hat in hand, asking for help.
The patch adds support for OpenMP programs like this:
// Compile with cl test.c /openmp
#include omp.h
#include stdio.h
int main (int argc, char **argv)
{
#pragma omp parallel
{
printf(%d\n, omp_get_thread_num());
}
}
Later patches add support for other OpenMP constructs.
My patch doesn't actually parallelize the app, but it does let it run
rather than crash on unimplemented _vcomp_fork.
Visual C will happily provide an assembly listing of this
program showing how _vcomp_fork is called, so understanding
that interface well enough to pass simple tests wasn't hard.
The main challenge was figuring out how to get the variable
list of arguments off the stack, and then put them back onto
the stack when calling the provided function pointer.
This bit of varargs hackery can't be done in pure C as far as I
can tell, so I used assembly.
I started programming in machine language long ago,
so getting that working wasn't too hard once I
realized that's what was needed. Getting it to pass the
Alexandre test is another matter.
Alexandre did give feedback on one earlier iteration of
the patch, telling me I was re-inventing the wheel, so I
tossed my old assembly and copied the helper-calling code
nearly verbatim from call_method in oleaut32/typelib.c.
Maybe he objects to not passing copies of the arguments in
the floating point registers on amd64... but the arguments are
always pointers, so that shouldn't be needed.
I'm definitely not yet comfortable with the ASM_CFI stuff, so perhaps
there's a problem there, but I did at least verify that injecting
a fault into _test_vcomp_fork_worker5() still yielded a good stack
trace on both x86 and amd64 in winedbg.
There aren't many comments, and the ones I did add aren't the
greatest, but I doubt that's the issue.
Perhaps he objects to breaking up _vcomp_fork into three functions,
but I couldn't see any other way to write it without making later
patches like http://source.winehq.org/patches/data/90527
(and a future patch that adds actual multiple threads)
put more logic than seems wise into assembly.
So maybe it's none of the above. If someone can suggest
what I might be missing, I'd appreciate it. Even just It will break if...
or Better compare how this was done in... would be very helpful.
Thanks!
Re: [PATCH 1/2] ntoskrnl.exe: Implement IoGetCurrentProcess and KeGetCurrentThread.
Christian Costa titan.co...@gmail.com wrote:
PEPROCESS WINAPI IoGetCurrentProcess(void)
{
-FIXME(() stub\n);
-return NULL;
+TRACE(()\n);
+
+/* Return current process id since PEPROCESS is opaque and drivers
should not access the struct directly */
+return (PEPROCESS)PsGetCurrentProcessId();
}
The returned pointer is supposed to be passed to various other ntoskrnl APIs,
and it's needs to be a valid pointer to the kernel object. Besides many not
trivial kernel drivers (if not all) really dig into internal kernel structures.
Same for KeGetCurrentThread.
--
Dmitry.
Re: [PATCH 2/2] ntoskrnl.exe: Implement MmMapLockedPagesSpecifyCache MmUnmapLockedPages and improve MmUnlockPages stub.
Christian Costa titan.co...@gmail.com wrote: +/* Read memory from the client process memory */ +if (!ReadProcessMemory(process, (LPCVOID)((ULONG)(mdl-StartVa) + mdl-ByteOffset), (LPVOID)(((ULONG)mdl-MappedSystemVa) + mdl-ByteOffset), mdl-ByteCount, bytes)) This kind of casts is broken. -- Dmitry.
