Re: user32: implement support for HBMENU_POPUP_* magic menu bitmaps and use them to decorate the system menu
On Freitag 20 Februar 2009, Rein Klazes wrote:
Hi,
See subject.
Rein.
Hi,
mostly minor code style comments.
if( hMenu ) {
+ MENUINFO minfo;
+ MENUITEMINFOW miteminfo;
POPUPMENU* menu = MENU_GetMenu(hMenu);
menu-wFlags |= MF_SYSMENU | MF_POPUP;
SetMenuDefaultItem(hMenu, SC_CLOSE, FALSE);
+
+ minfo.cbSize = sizeof( MENUINFO);
+ minfo.dwStyle = MNS_CHECKORBMP;
+ minfo.fMask = MIM_STYLE;
+ SetMenuInfo( hMenu, minfo);
+
+ miteminfo.cbSize = sizeof( MENUITEMINFOW);
+ miteminfo.fMask = MIIM_BITMAP;
+ miteminfo.hbmpItem = HBMMENU_POPUP_CLOSE;
+ SetMenuItemInfoW( hMenu, SC_CLOSE, FALSE, miteminfo);
+ miteminfo.hbmpItem = HBMMENU_POPUP_RESTORE;
+ SetMenuItemInfoW( hMenu, SC_RESTORE, FALSE, miteminfo);
+ miteminfo.hbmpItem = HBMMENU_POPUP_MAXIMIZE;
+ SetMenuItemInfoW( hMenu, SC_MAXIMIZE, FALSE, miteminfo);
+ miteminfo.hbmpItem = HBMMENU_POPUP_MINIMIZE;
+ SetMenuItemInfoW( hMenu, SC_MINIMIZE, FALSE, miteminfo);
}
I think this part deserves a bit more spacing to be readable.
Something like the above looks better IMO.
Also there is some inconsistent spacing around the beginning and end ()/{}
which does not match the rest of the file.
+logfont.lfHeight = min( h, w) - 2 ;
+TextOutW( hdc, rect-left, rect-top, bmchr, 1);
double space after '=' and ','
case (INT_PTR)HBMMENU_POPUP_CLOSE:
+bmchr[0] = 0x72;
+break;
case (INT_PTR)HBMMENU_POPUP_RESTORE:
+bmchr[0] = 0x32;
+break;
case (INT_PTR)HBMMENU_POPUP_MAXIMIZE:
+bmchr[0] = 0x31;
+break;
case (INT_PTR)HBMMENU_POPUP_MINIMIZE:
+bmchr[0] = 0x30;
+break;
The constants seem to be equal to DFCS_CAPTION...
I just tried to use DrawFrameControl but it seems to always draw a border
around the images.
And i did not find the right parameters for not drawing a border.
It could save some code for font setup but i guess it is not usable for this :-(
+TRACE( height %d rect %s\n, logfont.lfHeight,
wine_dbgstr_rect( rect));
leftover from debugging or is it still needed?
Greetings Peter
Re: [resend2] gdi32/tests: Add a test for GdiGetCodePage().
On Sonntag 14 Dezember 2008, ByeongSik Jeon wrote:
http://bugs.winehq.org/show_bug.cgi?id=16325
2008-12-14 (Sun), 13:34 +0100, Paul Vriens wrote:
Could you turn the skip in this piece of code:
+if (!pGdiGetCodePage)
+{
+skip(GdiGetCodePage not available on this platform\n);
+return;
+}
into a win_skip? That way we fail if the function is not available in Wine.
I changed it to the trace().
Another thing I'm not sure about though is that in the for() loop you
don't do a DeleteObject( hfont ). Is that only needed at the end?
Thanks.
---
dlls/gdi32/tests/Makefile.in |2 +-
dlls/gdi32/tests/font.c | 153
++
2 files changed, 154 insertions(+), 1 deletions(-)
Hi,
some small style notes.
+CHARSETINFO csi;
+
+if ( ( ansi_assoc == -1 || oem_assoc == -1 )
+RegOpenKeyA ( HKEY_LOCAL_MACHINE, associated_charset, hkey) ==
ERROR_SUCCESS )
+{
+RegQueryInfoKeyA ( hkey, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, max_data_len, NULL, NULL );
+data = HeapAlloc ( GetProcessHeap(), 0, max_data_len );
+
please try to use similar spacing like other parts of the file
no space before and after '(' when calling a function.
+case MAC_CHARSET:
+acp = GetACP();
+cp = ( acp == 932 || acp == 936 || acp == 949 || acp == 950 )?
1252 : CP_ACP;
+break;
Please try to avoid trailing whitespace
+JOHAB_CHARSET,
+VISCII_CHARSET,
+TCVN_CHARSET,
+KOI8_CHARSET,
+ISO3_CHARSET,
+ISO4_CHARSET,
+ISO10_CHARSET,
+CELTIC_CHARSET,
also some trailing whitespace here.
Thanks for you patch.
Greetings Peter
Re: [1/2] richedit: Created initial tests for windowless richedit controls. (try 2)
On Samstag 08 November 2008, Dylan Smith wrote: (Ensured compiler independence by modifying byte code templates) The initial tests added simply call CreateTextServices, and query for the ITextServices interface, then cleans up. Since CreateTextServices needs an implementation of ITextHost to be given, this patch needed a stub implementation. This required wrappers for converting thiscall to stdcall which are now implementing by adapting a byte code wrapper template. Although byte code isn't portable across processors, this is only needed for x86 platforms so it is only meant to be compiler independent. In order to investigate what is happening in the tests, it is helpful to trace the calls to ITextHost methods by the richedit controls. I realized it would be too verbose to trace all these calls by default, so I wrapped them all with a check for winedebug 1, since normally winedebug is 0 or 1. --- dlls/riched20/tests/Makefile.in |3 +- dlls/riched20/tests/txtsrv.c| 593 +++ 2 files changed, 595 insertions(+), 1 deletions(-) create mode 100644 dlls/riched20/tests/txtsrv.c Hi, This page [1] seems to suggest memory returned from HeapAlloc is marked as not executable. Other tests (ntdll exception) are using VirtualAlloc() for dynamically created code. patch 1 +/* The following x86 code string converts between the thiscall and stdcall + * calling convetions. The thiscall calling convention places the This + * pointer in ecx on the x86 platform, and the stdcall calling convention + * pushes the This pointer on the stack as the first argument. + * + * The wrapper's code finishes by jumping to the real function. + * + * Byte codes are used so that a copy of it can be modified to use + * for each method in ITextHost. */ patch 2 -/* The following x86 code string converts between the thiscall and stdcall +/* The following x86 code strings convert between the thiscall and stdcall * calling convetions. The thiscall calling convention places the This Here you introduce comments that you seem to change in the second patch. Maybe use the right text in the first patch? Additionally the term code string sounds odd. Maybe replace that with The following x86 assembler code... or something similar? #define ITextServices_QueryInterface(p,a,b) (p)-lpVtbl-QueryInterface(p,a,b) #define ITextServices_AddRef(p) (p)-lpVtbl-AddRef(p) #define ITextServices_Release(p) (p)-lpVtbl-Release(p) -/*** ITextServices methods ***/ -#define ITextServices_TxSendMessage(p,a,b,c,d) (p)-lpVtbl-TxSendMessage(p,a,b,c,d) -#define ITextServices_TxDraw(p,a,b,c,d,e,f,g,h,i,j,k,l) (p)-lpVtbl-TxDraw(p,a,b,c,d,e,f,g,h,i,j,k,l) Why do you only move some of those #defines part of ITextServices and not the one part of IUnknown ? I do not know much about those #defines but this seems odd Maybe i am missing something but why do you need those thiscall wrappers? Wouldn't it be possible to use the DEFINE_THISCALL_WRAPPER and THISCALL macros like in txtserv.c? Greetings Peter [1] http://www.unixwiz.net/techtips/xp-sp2.html
Re: msvcrt: scanf fix a typo
On Samstag 20 September 2008, Paul Vriens wrote: James Hawkins wrote: On Fri, Sep 19, 2008 at 4:59 PM, Austin English [EMAIL PROTECTED] wrote: Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). I'm still positive the original author meant to use capital P. There's no point in adding yet another test for a number that is different by one digit. I have to agree with James here. The original author (Peter Oberndorfer) added the tests and an implementation of %p and %P. Commits: 02fb99e6b360a6f321f716b57df97ca79ec1b9f3 9e3a4652dafbcf1f3f957858a54f2149e91942b7 It was my intention to test lower and upper case %p. I used different number to make sure this is the result of the current scanf call not from another call above with the same expected result. adding ptr = (void*)0xdeadbeef; before each test would have been more explicit. Greetings Peter
Re: Most common winetest failures on wine
On Montag 19 Mai 2008, Jeremy White wrote: ntdll:info is a flaky test marked todo_wine that succeeds sometimes: info.c:822: Test succeeded inside todo block: Expected to read 0 bytes, got 0 Hardy seems to be the common variable for failures, and it seems as though an actual failure reading from location 0x1234 is the trigger. (The historically normal case, apparently, is that we succeed in doing the read). Yes wine normally allows you to read the memory even when it should fail (because it is reserved by the preloader? + ntdll:reserve_dos_area + kernel32:setup_dos_mem) - ptrace PTRACE_PEEKDATA succeeds But on ubuntu wine probably fails to reserve the low memory because of http://wiki.winehq.org/PreloaderPageZeroProblem - ptrace PTRACE_PEEKDATA fails to read the memory and the read count is 0. git-blame points at Peter as the last to touch this. I've attached a potential patch, hopefully it'll be wrong and force Peter to step up and fix it correctly grin. The fix disables the readcount test for all targets running wine. Another workaround would be to choose another userspace address which is not protected by the kernel (bigger than 65536) but still falling into the dos reserve area 0x11. I do not have ubuntu/mmap protection here, could you/somebody try with a address like 0x8. Additionally the standard 0xdeadbeef address won't work here as it results in a different error(STATUS_ACCESS_VIOLATION for kernel space addresses instead of STATUS_PARTIAL_COPY ?) Cheers, Jeremy Greetings Peter
Re: user32: correct the caption bar and it's buttons' sizes
On Mittwoch 13 Februar 2008, Divan Burger wrote:
What is the problem without the patch?
is the caption bar drawn too high 1 pixel?
I ask because i have a patch that restores the 1 pixel
high line between the caption bar and the client area
(and at the same time decreases the height of the caption bar)
see it attached
for the NC_DrawXXXButton functions:
you also need to update hittest calculation
else the wrong buttons are activated.
For example when you press the mouse down on the left side of the close
button, but maximize gets activated
case SM_CYCAPTION:
if (!spi_loaded[SPI_NONCLIENTMETRICS_IDX]) load_nonclient_metrics();
- return nonclient_metrics.iCaptionHeight + 1;
+ return nonclient_metrics.iCaptionHeight;
this breaks a test in sysparams.c:2416
ok_gsm( SM_CYCAPTION, ncm.iCaptionHeight+1);
and 5 other tests
Greetings Peter
From 62066e37c5a01155eff03b01af76010a521cd114 Mon Sep 17 00:00:00 2001
From: Peter Oberndorfer [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 17:22:39 +0100
Subject: [PATCH] fix caption bar being too high by 1 pixel
To: [EMAIL PROTECTED]
this problem was introduced in commit 567b6facab5623857b399c80c96db97d3344c8ac
Add support for drawing gradient captions.
---
dlls/user32/nonclient.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/user32/nonclient.c b/dlls/user32/nonclient.c
index 503f7c1..1cdcbf6 100644
--- a/dlls/user32/nonclient.c
+++ b/dlls/user32/nonclient.c
@@ -917,7 +917,7 @@ static void NC_DrawCaption( HDC hdc, RECT *rect, HWND hwnd, DWORD style,
r.bottom--;
SystemParametersInfoW (SPI_GETGRADIENTCAPTIONS, 0, gradient, 0);
-NC_DrawCaptionBar (hdc, rect, style, active, gradient);
+NC_DrawCaptionBar (hdc, r, style, active, gradient);
if ((style WS_SYSMENU) !(exStyle WS_EX_TOOLWINDOW)) {
if (NC_DrawSysButton (hwnd, hdc, FALSE))
--
1.5.4
Re: [PATCH] ntdll: remove bogus VALGRIND_DISCARD
On Sonntag 06 Januar 2008, Peter Oberndorfer wrote: VALGRIND_DISCARD is used to discard block description handles (which are created by VALGRIND_CREATE_BLOCK) but it was called with the return value of VALGRIND_MAKE_xxx macros which all return 0x dlls/ntdll/signal_i386.c uses this macros already without VALGRIND_DISCARD --- dlls/ntdll/heap.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Please don't apply this yet, it needs further research. The valgrind manual tells us in the Client Requests section that VALGRIND_MAKE_xxx functions return such a block handle [1], But looking at the implementation of valgrind/adding traces to valgind DISCARD request show it returns 0x ? Greetings Peter [1] valgrind manual Release 3.3.0 - 4.6. Client Requests * VALGRIND_MAKE_MEM_NOACCESS, VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DE These mark address ranges as completely inaccessible, accessible but containing undefined data, and accessible and containing defined data, respectively. Subsequent errors may have their faulting addresses described in terms of these blocks. _Returns a block handle_. Returns zero when not run on Valgrind. * VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE. This is just like VALGRIND_MAKE_MEM_DEFINED but only affects those bytes that are already addressable. * VALGRIND_DISCARD: At some point you may want Valgrind to stop reporting errors in terms of the blocks defined by the previous three macros. To do this, the above macros return a small-integer block handle. You can pass this block handle to VALGRIND_DISCARD. After doing so, Valgrind will no longer be able to relate addressing errors to the user-defined block associated with the handle. The permissions settings associated with the handle remain in place; this just affects how errors are reported, not whether they are reported. Returns 1 for an invalid handle and 0 for a valid handle (although passing invalid handles is harmless). Always returns 0 when not run on Valgrind.
Re: [PATCH] [2/2] winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUse
On Wednesday 26 September 2007, Peter Oberndorfer wrote: --- dlls/winhttp/main.c | 25 + dlls/winhttp/winhttp.spec |2 +- 2 files changed, 26 insertions(+), 1 deletions(-) There is a 'r' missing in the patch title. it should be: winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUser Greetings Peter
Re: [PATCH] fix small spelling mistakes
On Thursday 20 September 2007, Juan Lang wrote: Hi Peter, correct spelling of iff - if Just so you know, iff is a common abbreviation meaning if and only if. I don't think that's any clearer in the cases you modified, so I think your patch is fine, I just thought you (and others) might be interested. --Juan Hi, you are right, i never heard about using it as a abbreviation for if and only if. Maybe i should have tried a dictionary first before fixing it :-) Thanks telling me Greetings Peter
Re: tests: show summary and last executed test in case of a crash
On Tuesday 22 May 2007 22:06, Paul Vriens wrote: Peter Oberndorfer wrote: Some tests on http://test.winehq.org/data/ seem to crash silently. Hi, Remember that not all 'Crashes' on the mentioned site are real crashes. Most Vista tests I'm running have 'Crash' mentioned on those pages. The reason is that the generated results file is bigger than 1.5 MB and this means the file will only be sent partly. If you're talking about the 'failed' ones with no good data (as it looks from you're patch), ignore the above. Yes i'm talking about those. I did some work on the parser (dissect Perl-script) a few months ago. You're output will not be handled properly (from a first glance). A normal test looks like: a:b start filename cvs-version .. .. .. .. b: w tests executed (x marked as todo, y failure[s]), z skipped. a:b done (0) As you're new output doesn't result in the 'done' line the parser will not correctly use that information. Maybe another line should be added at the end of you're output: From what i have seen the lines with start filename cvs-version a:b done (0) are not output from the test itself, but wintetest which runs the tests. so they should still show up. But i havent verified this. The only problem i see now is that we can't set the exit code and rune winedbg. So how could we inform winetest that the test crashed so it can set a proper done status, that can be examined by dissect. Or dissect finds crashed tests by a certain string that is only output on a crash. Maybe you have a better idea? a:b done (some number not being 0 or 258) The 258 is used for tests that timeout (0 being for tests that have run without crashes or timeouts). Obviously the parser (in this case it's actually the gather Perl-script) has to be changed to accommodate this new number. Cheers, Paul. Greetings Peter
tests: show summary and last executed test in case of a crash
Some tests on http://test.winehq.org/data/ seem to crash silently.
This patch might be useful for debugging such crashes.
It prints out the last ok/trace that was executed before the crash,
the exception address and the type of the crash.
It also print out the summary that is normally printed at the end of the test
instead of exiting silently[1].
On wine it still executes winedbg for better debugging after dumping out the
info.
My concern now is that it requires a change to the parser which accepts the
test reports,
so those crashes are not lost.
And don't know much about this parser.
Suggestions, ideas anyone?
Greetings Peter
[1] example output:
file.c:1228:FileSize: 0
file.c:1229:Unknown2[0]: 0
Test crashed at B7D0DF47 with error c005
Last test before crash: file.c:1239
file: 19 tests executed (0 marked as todo, 3 failures), 0 skipped.
wine: Unhandled page fault on write access to 0x1234 at address 0xb7d0df47
(thread 0009), starting debugger...
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
...
diff --git a/include/wine/test.h b/include/wine/test.h
index ea79475..4d0b26c 100644
--- a/include/wine/test.h
+++ b/include/wine/test.h
@@ -369,6 +369,29 @@ static void list_tests(void)
for (test = winetest_testlist; test-name; test++) fprintf( stdout, %s\n, test-name );
}
+/* display summary and last executed test in case of a crash */
+static LONG CALLBACK unhandled_exception_filter(struct _EXCEPTION_POINTERS *except)
+{
+if (winetest_debug)
+{
+tls_data* data=get_tls_data();
+
+if(except != NULL)
+fprintf( stdout, Test crashed at %p with error %x\n, except-ExceptionRecord-ExceptionAddress,
+ except-ExceptionRecord-ExceptionCode );
+else
+fprintf( stdout, Test crashed at unknown address\n);
+
+fprintf( stdout, Last test before crash: %s:%d\n, data-current_file, data-current_line );
+
+fprintf( stdout, %s: %d tests executed (%d marked as todo, %d %s), %d skipped.\n,
+ current_test-name, successes + failures + todo_successes + todo_failures,
+ todo_successes, failures + todo_failures,
+ (failures + todo_failures != 1) ? failures : failure,
+ skipped );
+}
+return EXCEPTION_CONTINUE_SEARCH;
+}
/* Run a named test, and return exit status */
static int run_test( const char *name )
@@ -384,6 +407,9 @@ static int run_test( const char *name )
successes = failures = todo_successes = todo_failures = 0;
tls_index=TlsAlloc();
current_test = test;
+
+SetUnhandledExceptionFilter(unhandled_exception_filter);
+
test-func();
if (winetest_debug)
Re: Implement MsiBreak Feature - Bug 8243
On Thursday 03 May 2007 05:45, EA Durbin wrote:
Hi,
patch created by Anastasius Focht for Bug 8243.
+#include sys/types.h /* for getpid() */
+#include unistd.h/* for getpid() */
Do we really need to write out unix pid?
AFAIK Winedbg can attach to windows process IDs just fine.
+ if( MessageBoxW( NULL, dbgMsgW, CustomActionName, MB_OKCANCEL) ==
IDOK)
+ {
+ return TRUE;
+ }
nitpick:
maybe remove {} to be consistent with rest of file?
+if( IsMsiBreak( info-target))
+ DebugBreak();
extra nitpick:
maybe remove space before argument or place additional space before closing )
like foo( baz ); / foo(baz);
It also seems like the patch is line wrapped.
Greetings Peter
Re: (resend) Scroll window fix
On Tuesday 13 February 2007 14:38, Aric Stewart wrote:
finds the case where the scrolling amount exceeds the window but still
falls within the clipping rect. This generates an additional update
region that needs to be invalidated.
includes a test
Hi,
I think your patch has a problem.
It calls CombineRgn with the deleted Region hrgnClip.
I don't know if it impacts real world applications, but i just saw a warning
about a invalid handle
in my debug log.
Maybe moving DeleteObject below the if solves the problem?
I don't know...
@@ -870,6 +870,26 @@ INT WINAPI ScrollWindowEx( HWND hwnd, IN
CombineRgn( hrgnWinupd, hrgnWinupd, hrgnTemp, RGN_OR );
RedrawWindow( hwnd, NULL, hrgnTemp, rdw_flags);
DeleteObject( hrgnClip ); // deleted here
+
+ /* Catch the case where the scolling amount exceeds the size of the
+ * original window. This generated a second update area that is the
+ * location where the original scrolled content would end up.
+ * This second region is not returned by the ScrollDC and sets
+ * ScrollWindowEx apart from just a ScrollDC.
+ *
+ * This has been verified with testing on windows.
+ */
+ if (abs(dx) abs(rc.right - rc.left) ||
+ abs(dy) abs(rc.bottom - rc.top))
+ {
+ DeleteObject( hrgnTemp );
+ hrgnTemp = CreateRectRgn(rc.left + dx, rc.top + dy,
rc.right+dx, rc.bottom + dy);
+ CombineRgn( hrgnTemp, hrgnTemp, hrgnClip, RGN_AND );
// used here
+ CombineRgn( hrgnUpdate, hrgnUpdate, hrgnTemp, RGN_OR );
+
+ if( !bOwnRgn)
+ CombineRgn( hrgnWinupd, hrgnWinupd, hrgnTemp, RGN_OR );
+ }
}
DeleteObject( hrgnTemp );
Greetings Peter
Re: Unknown issue with test.winehq.org
On Thursday 01 March 2007 08:30, Paul Vriens wrote: Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: exception: 42 tests executed (0 marked as todo, 0 failures), 0 skipped. exception: 279 tests executed (0 marked as todo, 5 failures), 0 skipped. The first one triggers the 'end of this test' in dissect. The second one is thus not accepted as dissect expects a 'start' line (and a line in between actually). The question now is: should dissect handle these cases or is this particular test-case wrong? It's because some of the tests are run in a child process. dissect should probably handle it, ideally by reporting the sum of the test counts as the results for the whole test. So what's the difference between this one and for example the following ones running in child processes: kernel32:process start dlls/kernel32/tests/process.c 1.10 tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/process.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. process: 396 tests executed (0 marked as todo, 6 failures), 0 skipped. or: msvcrt:file start dlls/msvcrt/tests/file.c 1.45 tests/file.c: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. tests/file.c: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 361 tests executed (0 marked as todo, 0 failures), 0 skipped. or better yet: shell32:shellpath start dlls/shell32/tests/shellpath.c 1.16 tests/shellpath.c: 10 tests executed (0 marked as todo, 4 failures), 0 skipped. tests/shellpath.c: 4 tests executed (0 marked as todo, 0 failures), 0 skipped. shellpath: 452 tests executed (0 marked as todo, 0 failures), 0 skipped. Obviously the start of line is a filename for these ones, whereas the start of the line for the exception one is the test itself. Should we consolidate the above ones as well? I think yes, cause the shell32 example is reflected as 0 errors on test.winehq.org. Cheers, Paul. Hi, sorry for not replying earlier, i didn't check mail yesterday. If the problem is only the prefix of the test result line the following trivial patch will make the tests work again. Output is now: ... more traces exception.c:644:excpetion 0xc008 at firstchance=0 Eip=0x24000b, Eax=0xf00f00f0 tests/exception.c: 42 tests executed (22 marked as todo, 0 failures), 0 skipped. exception: 280 tests executed (13 marked as todo, 0 failures), 0 skipped. Will send to wine-patches. Sorry for breaking tests :-/ Greetings Peter diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c index 08ec9c6..9a70264 100644 --- a/dlls/ntdll/tests/exception.c +++ b/dlls/ntdll/tests/exception.c @@ -600,7 +600,7 @@ static void test_debugger(void) return; } -sprintf(cmdline, %s %s %s, my_argv[0], my_argv[1], debuggee); +sprintf(cmdline, %s %s %s, my_argv[0], tests/exception.c, debuggee); ok(CreateProcess(NULL, cmdline, NULL, NULL, FALSE, DEBUG_PROCESS, NULL, NULL, si, pi) != 0, error: %u\n, GetLastError());
Re: [PATCH 3/3] ntdll: fix up instruction pointer in context insideraise_exception
On Monday 19 February 2007 09:37, Dmitry Timoshkov wrote:
Peter Oberndorfer [EMAIL PROTECTED] wrote:
I'm not fully sure if the fixup also happens for other architectures
(i guess not)
so this patch is more a RFC
@@ -336,6 +336,10 @@ static NTSTATUS raise_exception( EXCEPTION_RECORD
*rec, CONTEXT *context, BOOL f
if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED)
return STATUS_SUCCESS;
+/* fix up instruction pointer in context for EXCEPTION_BREAKPOINT
*/
+if (rec-ExceptionCode == EXCEPTION_BREAKPOINT)
+GET_IP(context) = (DWORD_PTR)GET_IP(context) - 1;
Gary Nebbett's book Windows Nt/2000 Native API Reference in the section C
Exceptions and Debugging provides a pseudocode for KiDispatchException
(page 439, Example C.1), and it does exactly the same thing as the patch
above. *But* it does it as a very first thing after getting the context and
before sending the debugger event.
The strange thing is my testcase [patch 2/3] shows/(should show) that the
debugger gets a unmodified eip for a first chance exception
+ if (de.u.Exception.dwFirstChance)
+ {
+ /* debugger gets first chance exception with
unmodified ctx.Eip */
+ ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xb,
Eip at %x instead of 0x%x\n,
+ ctx.Eip, (DWORD)code_mem_address + 0xb);
and the modified one when the application did not handle the exception
+ else
+ {
+ /* debugger gets context after exception handler has
played with it */
+ /* ctx.Eip is the same value the exception handler got
*/
+ if (de.u.Exception.ExceptionRecord.ExceptionCode ==
EXCEPTION_BREAKPOINT)
+ {
+ todo_wine{
+ ok((DWORD)ctx.Eip == (DWORD)code_mem_address +
0xa, Eip at %x instead of 0x%x\n,
+ ctx.Eip, (DWORD)code_mem_address + 0xa);
+ }
i tested this testcase on XP and 2K
Unfortunetely i don't own that book :-(
Could you please verify in the pseudocode that the modified context gets sent
to the debugger,
and not some unmodified copy?
Or maybe they unfix the context again in the send_to_debugger function ;-)
Or the pseudo code is not fully correct.
Thanks,
Greetings Peter
ntdll: test that shows RtlRaiseException with EXCEPTION_BREAKPOINT mangles Eip of context
This test is supposed to show that the Eip field in the context is fixed up
somewhere inside RtlRaiseException
or NtRaiseException (test for NtRaiseException not included) for (only)
EXCEPTION_BREAKPOINT exception
For others context.Eip is not changed.
Since real exceptions on wine also take that path i guess it is best to
implement context modifing in there.
The next patches will show what is the value of context.Eip in a Vectored
exception handler
(I still have some problems with this patch)
After that i plan to wrap a debugger around the test to show that the debugger
gets a unmodified context
The ultimate goal is to fix the Handling of EXCEPTION_BREAKPOINT problem
Vitaliy Margolen reported
( http://bugs.winehq.org/show_bug.cgi?id=7063 )
Patch tested on XP/2k
Comments, suggestions?
Greetings Peter
---
dlls/ntdll/tests/exception.c | 85 ++
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c
index d18f3d2..8fbfee6 100644
--- a/dlls/ntdll/tests/exception.c
+++ b/dlls/ntdll/tests/exception.c
@@ -39,6 +39,7 @@
static struct _TEB * (WINAPI *pNtCurrentTeb)(void);
static NTSTATUS (WINAPI *pNtGetContextThread)(HANDLE,CONTEXT*);
static NTSTATUS (WINAPI *pNtSetContextThread)(HANDLE,CONTEXT*);
+static NTSTATUS (WINAPI *pRtlRaiseException)(EXCEPTION_RECORD *rec);
static void *code_mem;
/* Test various instruction combinations that cause a protection fault on the i386,
@@ -184,6 +185,79 @@ static void run_exception_test(const void *handler, const void* context,
pNtCurrentTeb()-Tib.ExceptionList = exc_frame.frame.Prev;
}
+static DWORD rtlraiseexception_handler( EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame,
+ CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher )
+{
+trace( exception: %08x flags:%x addr:%p context: Eip:%x\n,
+ rec-ExceptionCode, rec-ExceptionFlags, rec-ExceptionAddress, context-Eip );
+
+todo_wine {
+ok((DWORD)rec-ExceptionAddress == (DWORD)code_mem + 0xb, ExceptionAddress at %p instead of %x\n,
+ rec-ExceptionAddress, (DWORD)code_mem + 0xb);
+}
+
+/* check that context.Eip is fixed up only for EXCEPTION_BREAKPOINT
+ * even if raised by RtlRaiseException
+ */
+if(rec-ExceptionCode == EXCEPTION_BREAKPOINT)
+{
+todo_wine {
+ok((DWORD)context-Eip == (DWORD)code_mem + 0xa, Eip at %x instead of %x\n,
+ context-Eip, (DWORD)code_mem + 0xa);
+}
+}
+else
+{
+ok((DWORD)context-Eip == (DWORD)code_mem + 0xb, Eip at %x instead of %x\n,
+ context-Eip, (DWORD)code_mem + 0xb);
+}
+
+/* Eip in context is decreased by 1
+ * Increase it again, else execution will continue in the middle of a instruction */
+if(rec-ExceptionCode == EXCEPTION_BREAKPOINT ((DWORD)context-Eip == (DWORD)code_mem + 0xa))
+context-Eip += 1;
+return ExceptionContinueExecution;
+}
+
+
+static const BYTE call_one_arg_code[] = {
+0x8b, 0x44, 0x24, 0x08, /* mov 0x8(%esp),%eax */
+0x50, /* push %eax */
+0x8b, 0x44, 0x24, 0x08, /* mov 0x8(%esp),%eax */
+0xff, 0xd0, /* call *%eax */
+0x90, /* nop */
+0x90, /* nop */
+0x90, /* nop */
+0x90, /* nop */
+0xc3, /* ret */
+};
+
+
+static void run_rtlraiseexception_test(DWORD exceptioncode)
+{
+
+EXCEPTION_REGISTRATION_RECORD frame;
+EXCEPTION_RECORD record;
+
+void (*func)(void* function, EXCEPTION_RECORD* record) = code_mem;
+
+record.ExceptionCode = exceptioncode;
+record.ExceptionFlags = 0;
+record.ExceptionRecord = NULL;
+record.ExceptionAddress = NULL; // does not matter, copied return address
+record.NumberParameters = 0;
+
+frame.Handler = rtlraiseexception_handler;
+frame.Prev = pNtCurrentTeb()-Tib.ExceptionList;
+
+memcpy(code_mem, call_one_arg_code, sizeof(call_one_arg_code));
+
+pNtCurrentTeb()-Tib.ExceptionList = frame;
+func(pRtlRaiseException, record);
+pNtCurrentTeb()-Tib.ExceptionList = frame.Prev;
+}
+
+
static DWORD handler( EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame,
CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher )
{
@@ -391,6 +465,8 @@ static void test_exceptions(void)
pNtGetContextThread = (void *)GetProcAddress( GetModuleHandleA(ntdll.dll), NtGetContextThread );
pNtSetContextThread = (void *)GetProcAddress( GetModuleHandleA(ntdll.dll), NtSetContextThread );
+pRtlRaiseException = (void *)GetProcAddress( GetModuleHandleA(ntdll.dll), RtlRaiseException );
+
if (!pNtGetContextThread || !pNtSetContextThread)
{
trace( NtGetContextThread/NtSetContextThread not found, skipping tests\n );
@@ -400,6 +476,15 @@ static void
Re: scroll window fix
On Thursday 25 January 2007 18:56, Aric Stewart wrote: finds the case where the scrolling amount exceeds the window but still falls within the clipping rect. This generates an additional update region that needs to be invalidated. includes a test Hi, I can't argue about the correctness of the patch itself but it adds tabs and a few trailing spaces. Greetings Peter --- dlls/user32/painting.c | 21 + dlls/user32/tests/win.c |9 + 2 files changed, 30 insertions(+), 0 deletions(-)
Re: dbghelp: fix debuglink crash, accessing memory after munmap
On Sunday 21 January 2007 16:25, Eric Pouech wrote: Peter Oberndorfer a écrit : Winedbg would crash on my system when trying to set a breakpoint (loading the debug info from a .debug file) The problem is that hash_table_elt adds the symbols of the .debug file to the hashtable of the parent file. But at the time elf_new_public_symbols is run, the sections of the .debug file are already unmapped. In addition to that the symbols in .debug would be added 2 times (.so and .debug file) Changelog: dbghelp: fix debuglink crash, accessing memory after munmap I don't think it's the right fix IMO, we shouldn't call elf_new_public_symbols while processing the .gnu_link target, but in the parent call to elf_load_debug_from_map can you provide more information on the crash itself (which reference is lost to an unmapped section) The crash happens at elf_new_public_symbols while executing ELF32_ST_TYPE(ste-symp-st_info) == STT_FUNC ste-symp points to the unmapped section. But ste-symp-st_size and ste-symp-st_value will probably also produce problems... Also the comment in elf_hash_symtab says: * as we added in the ht_symtab pointers to the symbols themselves, * we cannot unmap yet the sections, it will be done when we're over * with this ELF file Wouldn't moving the elf_new_public_symbols also create the need to unmap sections from parent call? Do you want to unmap both files in one go? A+ Greetings Peter PS: If it matters i have gcc4.1.1 and .debug links for most of my system libraries
Re: user32: Restore old WM_SIZE handler in mdi child
On Monday 08 January 2007 11:31, Dmitry Timoshkov wrote:
Hello,
Hi,
this patch seems to cause http://bugs.winehq.org/show_bug.cgi?id=7190
Each time a MDI child window gets a WM_SIZE the left most menu entry
disapperars.
The problem is that MDI_RestoreFrameMenu is called for each WM_SIZE message,
that does not maximize the window, instead of only beeing called when window
goes from maximized to normal
And MDI_RestoreFrameMenu removes the left most menu entry,
in belief is the document icon of a maximized child.
What is the reason for restoring the old code?
Does the new code break some apps?
The attached patch, which reverts a part of the revert fixes the problem for
my test app(ollydbg)
But i guess it is totally wrong :-)
this patch restores (almost completely) an old WM_SIZE handler in mdi child,
including the comment /* do not change */.
Changelog:
user32: Restore old WM_SIZE handler in mdi child.
Greetings Peter
diff --git a/dlls/user32/mdi.c b/dlls/user32/mdi.c
index f8bb8f8..dace1e8 100644
--- a/dlls/user32/mdi.c
+++ b/dlls/user32/mdi.c
@@ -1518,7 +1518,7 @@ LRESULT WINAPI DefMDIChildProcW( HWND hwnd, UINT message,
/* do not change */
TRACE(current active %p, maximized %p\n, ci-hwndActiveChild, ci-hwndChildMaximized);
-if( ci-hwndActiveChild == hwnd wParam != SIZE_MAXIMIZED )
+if( ci-hwndChildMaximized == hwnd wParam != SIZE_MAXIMIZED )
{
HWND frame;
Re: [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download
On Wednesday 03 January 2007 02:48, Phil Costin wrote: This patch resets the SFLAG_GLDIRTY flag for a surface once the GL surface data has been refreshed in surface_download_data(). Thanks to Stefan Dösinger for his advice in IRC during the implementation of these 2 patches. diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c index 031d320..5cb9bf6 100644 --- a/dlls/wined3d/surface.c +++ b/dlls/wined3d/surface.c @@ -142,6 +142,8 @@ static void surface_download_data(IWineD } } } + /* No longer dirty */ + This-Flags = SFLAG_GLDIRTY; I think there is a ~ missing here, else everything but the dirty flag will be cleared. } } Greetings Peter
Re: comctl32: fix imagelist regression from comctl32: Remove Nx1 assumptions in ImageList_Read
On Sunday 10 December 2006 16:57, Peter Oberndorfer wrote: The patch comctl32: Remove Nx1 assumptions in ImageList_Read (e74b0ee9102470d1b866e94c54527b34806cf876) would produce black images on the toolbar of IDA Pro Demo after clicking one of the listviews on the right Changelog: comctl32: fix imagelist regression from comctl32: Remove Nx1 assumptions in ImageList_Read remove unused HBITMAP hbmColor It still leaks memory, when it fails to read the bitmap or the mask. I'll try to write a testcase to see what happens if one of them is missing. Greetings Peter
XRenderFindDisplay crash / user32 winex11 initialisation order problem
Hi,
today i wanted to create a test for CreateCompatibleDC so i created a exe with
this content [1]
just to find out it crashes wine inside XRenderFindDisplay [2]
The reason is that the CreateCompatibleDC call in gdi executes LoadLibrary
winex11.drv
which in turn also loads user32.dll, because winex11.drv links to it.
Then in DllMain user32 registers some builtin classes which causes it to call
into winex11.
But at this point DllMain of winex11 had no chance to execute and
XRenderQueryExtension gets passed a
NULL pointer which makes it unhappy.
Unfortunately i have no idea how to properly solve this problem :-(
* Use UserClientDllInitialize for initializing user32 stuff as the comment
above DllMain mentions it?
* I tried linking gdi32 to user32(windows seems to do that) and inserted a dummy
IsCharAlphaA('c'); to make sure it is *really* linked :-)
And it does not crash anymore, but i don't know if i break any assumptions with
that.
Also i think it is preferable to defer loading the driver until it is really
needed.
If you have a better idea of how to fix this please tell me.
Greetings Peter
1: simplified version, compile with winegcc foo.c -lgdi32
#include windows.h
int main(int argc, char ** argv){
CreateCompatibleDC(NULL);
}
2: see attachment
Backtrace:
=1 0x7e987b4d XRenderFindDisplay+0xbd() in libxrender.so.1 (0x0034f0f4)
2 0x7e9889bd XRenderQueryExtension+0x1d() in libxrender.so.1 (0x0034f104)
3 0x7ec510e3 X11DRV_XRender_Init+0x4f3()
[/home/kumbayo/src/wine-git_compile/dlls/winex11.drv/xrender.c:203] in winex11
(0x0034f184)
4 0x7ec25a08 X11DRV_CreateDC+0x138(hdc=0x198, pdev=0x156910, driver=0x34f210,
device=0x0, output=0x0, initData=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/winex11.drv/init.c:92] in winex11
(0x0034f1c4)
5 0x7edb41d0 CreateDCW+0x100(driver=is not available, device=0x0,
output=0x0, initData=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/gdi32/dc.c:646] in gdi32 (0x0034f474)
6 0x7e9d2b2f CreateIconFromResourceEx+0x45f(bits=0x7ea74648, cbSize=0x134,
bIcon=0x0, dwVersion=0x3, width=0x20, height=0x20, cFlag=0x8040)
[/home/kumbayo/src/wine-git_compile/dlls/user32/cursoricon.c:727] in user32
(0x0034f524)
7 0x7e9d34df CURSORICON_Load+0x34f(hInstance=0x7e9a, name=0x7f00,
width=0x20, height=0x20, colors=0x1, fCursor=0x1, loadflags=0x8040)
[/home/kumbayo/src/wine-git_compile/dlls/user32/cursoricon.c:995] in user32
(0x0034f584)
8 0x7e9d3a4d LoadImageW+0x42d(hinst=register not in topmost frame,
name=0x7f00, type=0x2, desiredx=0x20, desiredy=0x20, loadflags=is not
available) [/home/kumbayo/src/wine-git_compile/dlls/user32/cursoricon.c:2282]
in user32 (0x0034f634)
9 0x7e9d4186 LoadImageA+0x56(hinst=0x0, name=0x7f00, type=0x2, desiredx=0x0,
desiredy=0x0, loadflags=0x8040)
[/home/kumbayo/src/wine-git_compile/dlls/user32/cursoricon.c:2211] in user32
(0x0034f714)
10 0x7e9d4422 LoadCursorA+0x42(hInstance=0x0, name=0x7f00)
[/home/kumbayo/src/wine-git_compile/dlls/user32/cursoricon.c:1720] in user32
(0x0034f744)
11 0x7e9ca055 register_builtin+0x85(descr=register not in topmost frame)
[/home/kumbayo/src/wine-git_compile/dlls/user32/class.c:381] in user32
(0x0034f774)
12 0x7e9ca0ad CLASS_RegisterBuiltinClasses+0x1d()
[/home/kumbayo/src/wine-git_compile/dlls/user32/class.c:408] in user32
(0x0034f784)
13 0x7ea3e101 DllMain+0x181(inst=0x7e9a, reason=0x1, reserved=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/user32/user_main.c:229] in user32
(0x0034f804)
14 0x7ea50f35 __wine_spec_dll_entry+0xb5(inst=0x7e9a, reason=register
not in topmost frame, reserved=register not in topmost frame)
[/home/kumbayo/src/wine-git_compile/dlls/winecrt0/dll_entry.c:40] in user32
(0x0034f824)
15 0x7efb5845 call_dll_entry_point+0x15() in ntdll (0x0034f844)
16 0x7efb6939 MODULE_InitDLL+0x179(wm=0x13ee50, reason=0x1, lpReserved=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/ntdll/loader.c:831] in ntdll
(0x0034f8f4)
17 0x7efb6ded process_attach+0x12d(wm=register not in topmost frame,
lpReserved=0x0) [/home/kumbayo/src/wine-git_compile/dlls/ntdll/loader.c:901] in
ntdll (0x0034f934)
18 0x7efb6d32 process_attach+0x72(wm=register not in topmost frame,
lpReserved=0x0) [/home/kumbayo/src/wine-git_compile/dlls/ntdll/loader.c:893] in
ntdll (0x0034f974)
19 0x7efb8f37 LdrLoadDll+0x87(path_name=0x13ec70, flags=0x0,
libname=0x34fc10, hModule=0x34fbe4)
[/home/kumbayo/src/wine-git_compile/dlls/ntdll/loader.c:1807] in ntdll
(0x0034f9a4)
20 0x7ee9f45b load_library+0x5b(libname=0x34fc10, flags=register not in
topmost frame) [/home/kumbayo/src/wine-git_compile/dlls/kernel32/module.c:830]
in kernel32 (0x0034fbf4)
21 0x7ee9f65c LoadLibraryExW+0x4c(libnameW=register not in topmost frame,
hfile=0x0, flags=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/kernel32/module.c:886] in kernel32
(0x0034fc24)
22 0x7ee9f781 LoadLibraryExA+0x41(libname=0x34fd9c, hfile=0x0, flags=0x0)
[/home/kumbayo/src/wine-git_compile/dlls/kernel32/module.c:866] in
Problem with NtReadVirtualMemory and wine server connection
Hi,
throught a problem in winedbg i found out that NtReadVirtualMemory has a
problem, when reading into a invalid local buffer.
it uses wine_server_set_reply( req, buffer, size ); to read the data supplied
by the server directly into application memory of unknown state.
when the read call hits bad(non present/readonly ) memory it returns EFAULT
and the client dies with
wine client error:process id: read: Bad address
i see 3 ways to deal with this problem
1. allocate a temporary buffer in NtReadVirtualMemory, read server answer to
this buffer, and then inside a try / catch block copy to application memory
2. change server protocol so it is not as sensitive when read returns EFAULT
(i do not really like this idea)
3. just fix the bug in winedbg and wait until a real world app needs this
behavior. (of course i will send a patch for windbg even if one of the other
ways is choosen)
Any ideas?
Greetings Peter
PS: attached a testcase for NtReadVirtualMemory(testcase itself not tested on
windows, but tests were)
the test should probably also live in its own file, but i didn't want to
create a almost empty file
diff --git a/dlls/ntdll/tests/info.c b/dlls/ntdll/tests/info.c
index 72f3dd9..d8a44d0 100644
--- a/dlls/ntdll/tests/info.c
+++ b/dlls/ntdll/tests/info.c
@@ -22,6 +22,7 @@ #include ntdll_test.h
static NTSTATUS (WINAPI * pNtQuerySystemInformation)(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG);
static NTSTATUS (WINAPI * pNtQueryInformationProcess)(HANDLE, PROCESSINFOCLASS, PVOID, ULONG, PULONG);
+static NTSTATUS (WINAPI * pNtReadVirtualMemory)(HANDLE, const void*, void*, SIZE_T, SIZE_T*);
static HMODULE hntdll = 0;
@@ -49,6 +50,7 @@ static BOOL InitFunctionPtrs(void)
{
NTDLL_GET_PROC(NtQuerySystemInformation)
NTDLL_GET_PROC(NtQueryInformationProcess)
+ NTDLL_GET_PROC(NtReadVirtualMemory)
}
return TRUE;
}
@@ -755,6 +757,61 @@ static void test_query_process_handlecou
}
}
+
+static void test_readvirtualmemory()
+{
+HANDLE process;
+DWORD status;
+SIZE_T readcount;
+static const char teststring[] = test string;
+char buffer[12];
+
+process = OpenProcess(PROCESS_VM_READ, FALSE, GetCurrentProcessId());
+ok(process != 0, Expected to be able to open own process for reading memory\n);
+
+/* normal operation */
+status = pNtReadVirtualMemory(process, teststring, buffer, 12, readcount);
+ok( status == STATUS_SUCCESS, Expected STATUS_SUCCESS, got %08lx\n, status);
+ok( readcount == 12, Expected to read 12 bytes, got %ld\n,readcount);
+ok( strcmp(teststring, buffer) == 0, Expected read memory to be the same as original memory);
+
+/* no number of bytes */
+memset(buffer, 0, 12);
+status = pNtReadVirtualMemory(process, teststring, buffer, 12, NULL);
+ok( status == STATUS_SUCCESS, Expected STATUS_SUCCESS, got %08lx\n, status);
+ok( strcmp(teststring, buffer) == 0, Expected read memory to be the same as original memory);
+
+/* illegal remote address */
+todo_wine{
+status = pNtReadVirtualMemory(process, (void *) 0x1234, buffer, 12, readcount);
+ok( status == STATUS_PARTIAL_COPY, Expected STATUS_PARTIAL_COPY, got %08lx\n, status);
+ok( readcount == 0, Expected to read 0 bytes, got %ld\n,readcount);
+}
+
+/* 0 handle */
+status = pNtReadVirtualMemory(0, teststring, buffer, 12, readcount);
+ok( status == STATUS_INVALID_HANDLE, Expected STATUS_INVALID_HANDLE, got %08lx\n, status);
+ok( readcount == 0, Expected to read 0 bytes, got %ld\n,readcount);
+
+/* pseudo handle for current process*/
+memset(buffer, 0, 12);
+status = pNtReadVirtualMemory((HANDLE)-1, teststring, buffer, 12, readcount);
+ok( status == STATUS_SUCCESS, Expected STATUS_SUCCESS, got %08lx\n, status);
+ok( readcount == 12, Expected to read 12 bytes, got %ld\n,readcount);
+ok( strcmp(teststring, buffer) == 0, Expected read memory to be the same as original memory);
+
+/* this test currently crashes wine with wine client error:process id: read: Bad address
+ * because the reply from wine server is directly read into the buffer and that fails with EFAULT
+ */
+/* illegal local address */
+/*status = pNtReadVirtualMemory(process, teststring, (void *)0x1234, 12, readcount);
+ok( status == STATUS_ACCESS_VIOLATION, Expected STATUS_ACCESS_VIOLATION, got %08lx\n, status);
+ok( readcount == 0, Expected to read 0 bytes, got %ld\n,readcount);
+*/
+
+CloseHandle(process);
+}
+
START_TEST(info)
{
if(!InitFunctionPtrs())
@@ -832,5 +889,9 @@ START_TEST(info)
trace(Starting test_query_process_handlecount()\n);
test_query_process_handlecount();
+/* belongs into it's own file */
+trace(Starting test_readvirtualmemory()\n);
+test_readvirtualmemory();
+
FreeLibrary(hntdll);
}
Re: mapi32: Write-strings warnings fix
On Saturday 03 June 2006 16:33, Andrew Talbot wrote: Changelog: mapi32: Write-strings warnings fix. diff -urN a/dlls/mapi32/sendmail.c b/dlls/mapi32/sendmail.c --- a/dlls/mapi32/sendmail.c 2006-05-23 17:24:40.0 +0100 +++ b/dlls/mapi32/sendmail.c 2006-06-03 14:44:21.0 +0100 @@ -113,8 +113,8 @@ } if (message-nFileCount) FIXME(Ignoring attachments\n); -subject = message-lpszSubject ? message-lpszSubject : ; -body = message-lpszNoteText ? message-lpszNoteText : ; +subject = message-lpszSubject ? message-lpszSubject : NULL; +body = message-lpszNoteText ? message-lpszNoteText : NULL; I think this is wrong, as it makes the whole ? : construct unnecessary. (for non NULL it evaluates to message-lpszNoteText and for NULL it becomes NULL; TRACE( Subject: %s\n, debugstr_a(subject) ); TRACE( Body: %s\n, debugstr_a(body) ); Greetings Peter
Re: Possible regression in CVS wine
On Sunday 04 September 2005 20:41, Pavel Troller wrote: Hi! I've just upgraded wine on my son's computer by today's CVS. He tried some games and one of them stopped working. It's hind95 and the game bails out on an illegal instruction - outb, jumping into winedbg. Backtrace shows just 3 levels of game code itself, no dlls involved. I understand that user code cannot perform direct hardware I/O, but the game worked just before the upgrade (on wine about 1 month old). I don't know whether wine is normally intercepting and emulating these instructions, and the CVS version doesn't, or whether a new wine caused that another code path has been activated in the game code, leading to such a problem. There is also native w2k version of the game (hind.exe) but it still doesn't work in wine: it very sow renders the splash screen and then sits there and does nothing more. The game can be freely downloaded from www.abandonia.com; just search hind in the title page. There is probably a dynamic download URL used so I'm not posting it there. With regards, Pavel Troller Hi, I haven't tried to run the game but maybe the problem is that wine now defaults to behave like Win 2000[1] which does not allow privileged instructions. You could try to set windows version to 98 with winecfg Greetings Peter [1] Patch from 15.08.2005 that changed the default version: http://cvs.winehq.org/patch.py?id=19564
Re: wine/dlls/ntdll loadorder.c
On Thursday 28 July 2005 11:46, Alexandre Julliard wrote: Rein Klazes [EMAIL PROTECTED] writes: | trace:module:load_dll looking for Lcomm.dll in | LE:\\bin\\gt3\\GTWin;.;d:\\win98\\system;d:\\WIN98;d:\\windows;d:\\win |dows\\system;h:\\shared;r:\\x86\\Setup | trace:module:MODULE_GetLoadOrderW looking for | LE:\\bin\\gt3\\GTWin\\comm.dll trace:module:open_app_key searching | LE:\\bin\\gt3\\GTWin\\comm in | LSoftware\\Wine\\AppDefaults\\girotel.exe\\DllOverrides | trace:module:MODULE_GetLoadOrderW got hardcoded default b,n for | LE:\\bin\\gt3\\GTWin\\comm.dll trace:module:load_dll Trying built-in | LE:\\bin\\gt3\\GTWin\\comm.dll warn:module:load_dll Failed to load | module Lcomm.dll; status=c07b Are you sure you don't have an old symlink lying around? comm.drv used to be named comm.dll, but it was renamed about 2 years ago. Hi Same thing happens here with WinDbg 6.5.3.7 which comes with dbghelp.dll in app directory. Greetings Peter
Re: wine/dlls/ntdll loadorder.c
On Thursday 28 July 2005 23:14, Alexandre Julliard wrote: Peter Oberndorfer [EMAIL PROTECTED] writes: Same thing happens here with WinDbg 6.5.3.7 which comes with dbghelp.dll in app directory. If you mean it fails to load dbghelp completely then that's a bug. If it's loading the builtin dbghelp instead of the native then it's a feature g It's a bit of both :-) The dbghelp shipped with WinDbg has a SymSetParentWindow entry point which is not (yet) available in wine. So it catches fire when the function is called. Adding a SymSetParentWindow stub is easy but shouldn't it load the dbghelp.dll in the app dir? Or does dbghelp get some special treatment because it has ability to read other debug formats?) OllyDbg is another application that comes with newer dbghelp. I don' know if it is important but the dependency tree for windbg is: windbg -dbgeng.dll(native dll in app dir) -dbghelp windbg -dbghelp Greetings Peter
Re: Console problem
Michael Stefaniuc wrote: Hi, On Mon, Dec 22, 2003 at 08:11:28PM +0100, Peter Oberndorfer wrote: I'm trying to get the freeware version of IDA (console) working, but if you mean ida37fw? My experience is based on that one. I tried freeware version 4.1 It was previously avaliable at http://www.datarescue.be/downloadfreeware.htm but they stopped distributing it. It still can easily be found on the web as idafree.zip i run it in wine it just hangs. If i run it with winedbg it works fine. I found out that the problem is that AllocConsole is never called for the application if it is being run from wine. You can run it like this: wineconsole -- --backend=user IDA.EXE This will create the initial console too. If you want to change the settings of the wineconsole just right click on it. This will bring you IDA up and running (the time displayed in the upper right corner gets updated every second) but keyboard/mouse input does NOT work. This seems to be due to the emulated hardware interrupts not being dispatched. After some minutes i get err:int:TIMER_TimerProc DOS timer has been stuck for 60 seconds... The timer interrupt being int0 and having the highest priority it's blocking the processing of int1 (keyboard). From the trace i see that DOSVM_QueueEvent never signals the VM86 thread because there are always pending request with higher priority. As i didn't had too much time lately and my DOS skills aren't that good i didn't got to dig deeper into the problem. Using wineconsole -- --backend=user idaw.exe works perfectly beside special charachters used to draw frames appear as rectangles. Thanks for this tip. Maybe the problem you are experiencing only occours with the older version of IDA. bye michael greetings Peter
