Re: urlmon: Fix handling of mailto URIs in CoInternetCombineUrlEx.
Hi Hans,
On 03/27/13 10:43, Hans Leidekker wrote:
---
dlls/urlmon/tests/uri.c | 63
+++
dlls/urlmon/uri.c | 15 ---
2 files changed, 69 insertions(+), 9 deletions(-)
diff --git a/dlls/urlmon/tests/uri.c b/dlls/urlmon/tests/uri.c
index e5faa81..29bd859 100644
--- a/dlls/urlmon/tests/uri.c
+++ b/dlls/urlmon/tests/uri.c
@@ -7005,8 +7005,61 @@ static const uri_combine_test uri_combine_tests[] = {
{URL_SCHEME_FILE,S_OK},
{URLZONE_INVALID,E_NOTIMPL}
}
+},
+{ http://winehq.org,0,
+mailto://,0,
+0,S_OK,FALSE,
You are changing parts that are not combining-specific. Since the
relative URI is absolute in this case, there is not much happening other
than parsing the URI during combining. Those tests are fine, but please
add also tests for CreateUri, see uri_tests array. This should be
straightforward based on tests you already wrote.
diff --git a/dlls/urlmon/uri.c b/dlls/urlmon/uri.c
index 0f6ee31..c6b5166 100644
--- a/dlls/urlmon/uri.c
+++ b/dlls/urlmon/uri.c
@@ -422,7 +422,7 @@ static inline BOOL is_hierarchical_uri(const WCHAR **ptr,
const parse_data *data
else if(is_hierarchical_scheme(data-scheme_type) (*ptr)[0] == '\\'
(*ptr)[1] == '\\') {
*ptr += 2;
return TRUE;
-} else if(check_hierarchical(ptr))
+} else if(data-scheme_type != URL_SCHEME_MAILTO
check_hierarchical(ptr))
return TRUE;
*ptr = start;
@@ -2980,6 +2980,9 @@ static BOOL canonicalize_path_opaque(const parse_data
*data, Uri *uri, DWORD fla
const BOOL known_scheme = data-scheme_type != URL_SCHEME_UNKNOWN;
const BOOL is_file = data-scheme_type == URL_SCHEME_FILE;
const BOOL is_mk = data-scheme_type == URL_SCHEME_MK;
+const BOOL is_javascript = data-scheme_type == URL_SCHEME_JAVASCRIPT;
+const BOOL is_mailto = data-scheme_type == URL_SCHEME_MAILTO;
+DWORD offset = 0;
if(!data-path) {
uri-path_start = -1;
@@ -2996,7 +2999,7 @@ static BOOL canonicalize_path_opaque(const parse_data
*data, Uri *uri, DWORD fla
}
/* For javascript: URIs, simply copy path part without any
canonicalization */
-if(data-scheme_type == URL_SCHEME_JAVASCRIPT) {
+if(is_javascript) {
if(!computeOnly)
memcpy(uri-canon_uri+uri-canon_len, data-path,
data-path_len*sizeof(WCHAR));
uri-path_len = data-path_len;
@@ -3007,7 +3010,11 @@ static BOOL canonicalize_path_opaque(const parse_data
*data, Uri *uri, DWORD fla
/* Windows doesn't allow a // to appear after the scheme
* of a URI, if it's an opaque URI.
*/
-if(data-scheme *(data-path) == '/' *(data-path+1) == '/') {
+if (is_mailto *(data-path) == '/' *(data-path+1) == '/') {
+if (!*(data-path+2)) uri-path_start = -1;
+offset += 2;
I think this should be done in parsing phrase, not during canonicalization.
Jacek
Re: [PATCH 1/3] msvcr90: Forward some functions directly to ntdll
Piotr Caban pi...@codeweavers.com writes: These functions are currently forwarded from msvcr90 to msvcrt which forwards to ntdll. Naver LINE is crashing while trying to call them. Does it work if you remove the forward in msvcrt instead? That would be a better fix. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/3] msvcr90: Forward some functions directly to ntdll
On 03/27/13 12:13, Alexandre Julliard wrote: Piotr Caban pi...@codeweavers.com writes: These functions are currently forwarded from msvcr90 to msvcrt which forwards to ntdll. Naver LINE is crashing while trying to call them. Does it work if you remove the forward in msvcrt instead? That would be a better fix. Yes, I'll send a fixed version.
Re: advapi32: Do not terminate a regular program if it calls StartServiceCtrlDispatcher.
Alexander Morozov amoro...@etersoft.ru writes:
@@ -592,7 +586,26 @@ BOOL WINAPI StartServiceCtrlDispatcherA( const
SERVICE_TABLE_ENTRYA *servent )
services[i] = info;
}
-service_run_main_thread();
+disp = HeapAlloc( GetProcessHeap(), 0, sizeof(*disp) );
+
+if (!(disp-manager = OpenSCManagerW( NULL, NULL, SC_MANAGER_CONNECT )))
+{
+ERR(failed to open service manager error %u\n, GetLastError());
+HeapFree( GetProcessHeap(), 0, disp );
+return FALSE;
+}
+
+disp-pipe = service_open_pipe();
+if (disp-pipe == INVALID_HANDLE_VALUE)
+{
+WARN(failed to create control pipe error %u\n, GetLastError());
+CloseServiceHandle( disp-manager );
+HeapFree( GetProcessHeap(), 0, disp );
+SetLastError( ERROR_FAILED_SERVICE_CONTROLLER_CONNECT );
+return FALSE;
+}
+
+service_run_main_thread( disp );
There's no reason to duplicate that code, just do it in
service_run_main_thread instead.
--
Alexandre Julliard
julli...@winehq.org
Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution
On Mar 27, 2013, at 6:41 AM, Hugh McMaster wrote: This patch modifies the dlls/kernel32 Makefile.in to (1) compile a new source file (screensize.c) (patch 3/3) and (2) add -lX11 to the ExtraDllFlags line. This approach is untenable. Kernel32 can't be made to depend on X11. It has to still work when X11 isn't available. Also, X11 is just one possible graphics/windowing system that Wine can use, so it's not always the right authority to consult about screen size. Eric Pouech suggested in the other thread to calculate the console window size in wineconsole, at which point you can use user32 and SystemParametersInfo(). Finally, your patch series is broken in the sense that each patch in the series must still be able to compile. You introduce a dependency on screensize.c in the first patch but don't actually provide that source file until the third. -Ken
Re: Wiki is down
On Mon, 25 Mar 2013, Dimi Paun wrote: Should be up now, the RAID controller on the box died. We'll be moving it to a better box soon, stay tuned. Do you know what's up with this message? Status of sending notification mails: [en] fracting: Connection to mailserver 'mail.lattica.com' failed: (101, 'Network is unreachable') Note that it was present before the RAID card trouble so it's not caused by your recent changes. See also bug 33231 - Wiki: Trouble sending notification emails http://bugs.winehq.org/show_bug.cgi?id=33231 -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Re: Wiki is down
Thanks for the bug report, it should be fixed now. Dimi. On Wed, Mar 27, 2013 at 12:57 PM, Francois Gouget fgou...@free.fr wrote: On Mon, 25 Mar 2013, Dimi Paun wrote: Should be up now, the RAID controller on the box died. We'll be moving it to a better box soon, stay tuned. Do you know what's up with this message? Status of sending notification mails: [en] fracting: Connection to mailserver 'mail.lattica.com' failed: (101, 'Network is unreachable') Note that it was present before the RAID card trouble so it's not caused by your recent changes. See also bug 33231 - Wiki: Trouble sending notification emails http://bugs.winehq.org/show_bug.cgi?id=33231 -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY -- Dimi Paun d...@lattica.com Lattica, Inc.
Re: tools/wine.inf: add HKLM\\System\\CurrentControlSet\\Services\\Eventlog\\Application registry key
Austin English austinengl...@gmail.com writes: Fixes http://bugs.winehq.org/show_bug.cgi?id=22026 It breaks the tests: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so eventlog.c touch eventlog.ok eventlog.c:524: Tests skipped: We don't have a backup eventlog to work with eventlog.c:457: Tests skipped: No records in the 'Application' log eventlog.c:835: Test failed: Expected 1 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 2 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 3 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 4 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 5 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 6 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 7 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 8 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 9 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 10 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:858: Test failed: Expected 10 records, got 0 eventlog.c:863: Tests skipped: No events were written to the eventlog eventlog.c:1086: Test failed: Expected an eventlog file eventlog.c:1113: Test succeeded inside todo block: Could not delete the registry tree : 0 eventlog.c:1120: Test succeeded inside todo block: Expected MoveFileEx to succeed: 1 make: *** [eventlog.ok] Error 24 -- Alexandre Julliard julli...@winehq.org
Re: d3dx9 [patch 1/2, try 3]: Implement D3DXSHEvalSphericalLight
Nozomi Kodama nozomi.kod...@yahoo.com writes: From 3d331ffa908f69ca58686b4601effbb16d89d1da Mon Sep 17 00:00:00 2001 From: nozomi.kodama nozomi.kod...@yahoo.com Date: Thu, 14 Mar 2013 18:34:48 -1000 Subject: d3dx9: Implement D3DXSHEvalSphericalLight It fails on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so ../../../../wine/dlls/d3dx9_36/tests/math.c touch math.ok math.c:2930: Test failed: Red: case 1, order 5: expected[20] = 0.000529, received 0.000529 math.c:2939: Test failed: Green: case 1, order 5: expected[20] = 0.000809, received 0.000809 math.c:2949: Test failed: Blue: case 1, order 5: expected[20] = 0.001089, received 0.001089 math.c:2930: Test failed: Red: case 1, order 6: expected[20] = 0.000529, received 0.000529 math.c:2939: Test failed: Green: case 1, order 6: expected[20] = 0.000809, received 0.000809 math.c:2949: Test failed: Blue: case 1, order 6: expected[20] = 0.001089, received 0.001089 math.c:2930: Test failed: Red: case 2, order 5: expected[20] = -0.000715, received -0.000714 math.c:2939: Test failed: Green: case 2, order 5: expected[20] = -0.001093, received -0.001093 math.c:2949: Test failed: Blue: case 2, order 5: expected[20] = -0.001471, received -0.001471 math.c:2930: Test failed: Red: case 2, order 6: expected[20] = -0.000715, received -0.000714 math.c:2939: Test failed: Green: case 2, order 6: expected[20] = -0.001093, received -0.001093 math.c:2949: Test failed: Blue: case 2, order 6: expected[20] = -0.001471, received -0.001471 make: *** [math.ok] Error 12 -- Alexandre Julliard julli...@winehq.org
RE: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution
-Original Message- From: Ken Thomases [mailto:k...@codeweavers.com] Sent: Wednesday, 27 March 2013 11:25 PM To: Hugh McMaster Cc: Wine Developers Subject: Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution On Mar 27, 2013, at 6:41 AM, Hugh McMaster wrote: This patch modifies the dlls/kernel32 Makefile.in to (1) compile a new source file (screensize.c) (patch 3/3) and (2) add -lX11 to the ExtraDllFlags line. Ken Thomases wrote: This approach is untenable. Kernel32 can't be made to depend on X11. It has to still work when X11 isn't available. Also, X11 is just one possible graphics/windowing system that Wine can use, so it's not always the right authority to consult about screen size. A fair point. I hadn't considered that windowing systems such as XFree86 were still in use. I'm too used to using distributions running X11. Eric Pouech suggested in the other thread to calculate the console window size in wineconsole, at which point you can use user32 and SystemParametersInfo(). (Discussion continued in other thread). Finally, your patch series is broken in the sense that each patch in the series must still be able to compile. You introduce a dependency on screensize.c in the first patch but don't actually provide that source file until the third. So patches are applied one by one and then tested? I thought patches in a series were applied at the same time. Hugh
Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution
On Mar 27, 2013, at 6:08 PM, Hugh McMaster wrote: Ken Thomases wrote: This approach is untenable. Kernel32 can't be made to depend on X11. It has to still work when X11 isn't available. Also, X11 is just one possible graphics/windowing system that Wine can use, so it's not always the right authority to consult about screen size. A fair point. I hadn't considered that windowing systems such as XFree86 were still in use. I'm too used to using distributions running X11. More to the point, Wine doesn't necessarily use any variant of the X Window System. On Mac OS X, it can use the Mac driver. Other drivers are being investigated. Finally, your patch series is broken in the sense that each patch in the series must still be able to compile. You introduce a dependency on screensize.c in the first patch but don't actually provide that source file until the third. So patches are applied one by one and then tested? Yes. I thought patches in a series were applied at the same time. No. A series is used to indicate that later patches can't be applied before the earlier ones. That is, for example, patch 2 requires that patch 1 already was applied before it can be successfully applied. Successfully applied means all of: the patch applies, Wine builds, and tests succeed (at least as well as before). Regards, Ken
RE: Linker error when improving GetLargestConsoleWindowSize
-Original Message-
From: Eric Pouech [mailto:eric.pou...@orange.fr]
Sent: Wednesday, 27 March 2013 8:54 AM
To: wine-devel@winehq.org
Subject: Re: Linker error when improving GetLargestConsoleWindowSize
Ken Thomases wrote:
This won't be able to work. The linker error is telling you, effectively,
that you're not importing user32. However, kernel32 can't import user32.
Kernel32 is at a lower level than user32. And a console program especially
can't rely on user32 being loaded and initialized to satisfy the request
you're making. Regards, Ken
Eric Pouech wrote:
actually the correct fix would be to transfer this computation to
wineconsole (which already imports user32), but thats' not a really trivial
task
So, if wineconsole imports user32 to run console programs, that explains why a
generic program using SystemParametersInfo or GetSystemMetrics is able to
compile and run correctly, yes? For example:
---
#include windows.h
#include winuser.h
#include stdio.h
main(void)
{
RECT workarea;
SystemParametersInfo(SPI_GETWORKAREA, 0, workarea, 0);
int screen_x = workarea.right;
int screen_y = workarea.bottom;
printf(Your screen resolution is %d x %d pixels.\n, screen_x, screen_y);
}
---
Anyway, if I understand you correctly, the computations would need to be moved
to programs/wineconsole (wineconsole.c).
Hugh
Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed
Aric Stewart a...@codeweavers.com wrote: Worked out with testing on Japanese windows XP. Resolves issues with keystrokes and accelerators in menus when the IME is active. You should really start adding the tests and base your patches on test results instead of some sort of speculation. -- Dmitry.
