June 2008 - Wine-Devel - list.winehq.org

Coverity reported buffer overrun error in "winebuild: Add support for 16-bit exe modules."
by Dan Kegel June 28, 2008

June 28, 2008

Coverity complains that http://source.winehq.org/git/wine.git/?a=commitdiff;h=0c214a7091af8efe39ffd… introduced a buffer overrun in winebuild. It looks like somebody forgot to dynamically grow an array? Here's the report. Can somebody familiar with the code (or with a little time on their hands) have a look? Thanks... - Dan CID: 682 Checker: OVERRUN_DYNAMIC (help) File: base/src/wine/tools/winebuild/spec16.c Function: BuildSpec16File Description: Overrun of dynamic array "(spec)->ordinals" of size 4 at position 4 with index variable "(i * 4)" 524 /******************************************************************* 525 * BuildSpec16File 526 * 527 * Build a Win16 assembly file from a spec file. 528 */ 529 void BuildSpec16File( DLLSPEC *spec ) 530 { 531 ORDDEF **typelist; 532 ORDDEF *entry_point = NULL; 533 int i, j, nb_funcs; 534 char header_name[256]; 535 536 /* File header */ 537 538 output_standard_file_header(); 539 540 if (!spec->file_name) 541 { 542 char *p; 543 spec->file_name = xstrdup( output_file_name ); 544 if ((p = strrchr( spec->file_name, '.' ))) *p = 0; 545 } 546 if (!spec->dll_name) /* set default name from file name */ 547 { 548 char *p; 549 spec->dll_name = xstrdup( spec->file_name ); 550 if ((p = strrchr( spec->dll_name, '.' ))) *p = 0; 551 } 552 553 /* store the main entry point as ordinal 0 */ 554 555 if (!spec->ordinals) 556 { Event buffer_alloc: Called allocating function "xmalloc" which allocated 4 bytes dictated by parameter 0 [model] Event var_assign: Assigned "(spec)->ordinals" to storage allocated by "xmalloc" Also see events: [var_assign][overrun-local] 557 spec->ordinals = xmalloc( sizeof(spec->ordinals[0]) ); 558 spec->ordinals[0] = NULL; 559 } At conditional (1): "(spec)->init_func != 0" taking true path At conditional (2): "(spec)->characteristics & 8192 == 0" taking true path 560 if (spec->init_func && !(spec->characteristics & IMAGE_FILE_DLL)) 561 { 562 entry_point = xmalloc( sizeof(*entry_point) ); 563 entry_point->type = TYPE_PASCAL; 564 entry_point->ordinal = 0; 565 entry_point->lineno = 0; 566 entry_point->flags = FLAG_REGISTER; 567 entry_point->name = NULL; 568 entry_point->link_name = xstrdup( spec->init_func ); 569 entry_point->export_name = NULL; 570 entry_point->u.func.arg_types[0] = 0; At conditional (3): "*((spec)->ordinals + 0) == 0" taking true path 571 assert( !spec->ordinals[0] ); 572 spec->ordinals[0] = entry_point; 573 } 574 575 /* Build sorted list of all argument types, without duplicates */ 576 577 typelist = xmalloc( (spec->limit + 1) * sizeof(*typelist) ); 578 At conditional (4): "i <= (spec)->limit" taking true path At conditional (6): "i <= (spec)->limit" taking true path At conditional (8): "i <= (spec)->limit" taking true path At conditional (10): "i <= (spec)->limit" taking true path At conditional (13): "i <= (spec)->limit" taking true path At conditional (16): "i <= (spec)->limit" taking false path 579 for (i = nb_funcs = 0; i <= spec->limit; i++) 580 { 581 ORDDEF *odp = spec->ordinals[i]; At conditional (5): "odp == 0" taking true path At conditional (7): "odp == 0" taking true path At conditional (9): "odp == 0" taking true path At conditional (11): "odp == 0" taking false path At conditional (14): "odp == 0" taking false path 582 if (!odp) continue; At conditional (12): "is_function != 0" taking false path At conditional (15): "is_function != 0" taking true path 583 if (is_function( odp )) typelist[nb_funcs++] = odp; 584 } 585 586 nb_funcs = sort_func_list( typelist, nb_funcs, callfrom16_type_compare ); 587 588 /* Output the module structure */ 589 590 sprintf( header_name, "__wine_spec_%s_dos_header", make_c_identifier(spec->dll_name) ); 591 output( "\n/* module data */\n\n" ); 592 output( "\t.data\n" ); 593 output( "\t.align %d\n", get_alignment(4) ); 594 output( "%s:\n", header_name ); 595 output( "\t%s 0x%04x\n", get_asm_short_keyword(), /* e_magic */ 596 IMAGE_DOS_SIGNATURE ); 597 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_cblp */ 598 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_cp */ 599 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_crlc */ 600 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_cparhdr */ 601 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_minalloc */ 602 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_maxalloc */ 603 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_ss */ 604 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_sp */ 605 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_csum */ 606 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_ip */ 607 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_cs */ 608 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_lfarlc */ 609 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_ovno */ 610 output( "\t%s 0,0,0,0\n", get_asm_short_keyword() ); /* e_res */ 611 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_oemid */ 612 output( "\t%s 0\n", get_asm_short_keyword() ); /* e_oeminfo */ 613 output( "\t%s 0,0,0,0,0,0,0,0,0,0\n", get_asm_short_keyword() ); /* e_res2 */ 614 output( "\t.long .L__wine_spec_ne_header-%s\n", header_name ); /* e_lfanew */ 615 616 output( ".L__wine_spec_ne_header:\n" ); 617 output( "\t%s 0x%04x\n", get_asm_short_keyword(), /* ne_magic */ 618 IMAGE_OS2_SIGNATURE ); 619 output( "\t.byte 0\n" ); /* ne_ver */ 620 output( "\t.byte 0\n" ); /* ne_rev */ 621 output( "\t%s .L__wine_spec_ne_enttab-.L__wine_spec_ne_header\n", /* ne_enttab */ 622 get_asm_short_keyword() ); 623 output( "\t%s .L__wine_spec_ne_enttab_end-.L__wine_spec_ne_enttab\n", /* ne_cbenttab */ 624 get_asm_short_keyword() ); 625 output( "\t.long 0\n" ); /* ne_crc */ At conditional (17): "(spec)->characteristics & 8192 != 0" taking false path 626 output( "\t%s 0x%04x\n", get_asm_short_keyword(), /* ne_flags */ 627 NE_FFLAGS_SINGLEDATA | 628 ((spec->characteristics & IMAGE_FILE_DLL) ? NE_FFLAGS_LIBMODULE : 0) ); 629 output( "\t%s 2\n", get_asm_short_keyword() ); /* ne_autodata */ 630 output( "\t%s %u\n", get_asm_short_keyword(), spec->heap_size ); /* ne_heap */ 631 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_stack */ At conditional (18): "entry_point == 0" taking false path 632 if (!entry_point) output( "\t.long 0\n" ); /* ne_csip */ 633 else output( "\t%s .L__wine_%s_0-.L__wine_spec_code_segment,1\n", 634 get_asm_short_keyword(), make_c_identifier(spec->dll_name) ); 635 output( "\t%s 0,2\n", get_asm_short_keyword() ); /* ne_sssp */ 636 output( "\t%s 2\n", get_asm_short_keyword() ); /* ne_cseg */ 637 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_cmod */ 638 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_cbnrestab */ 639 output( "\t%s .L__wine_spec_ne_segtab-.L__wine_spec_ne_header\n", /* ne_segtab */ 640 get_asm_short_keyword() ); 641 output( "\t%s .L__wine_spec_ne_rsrctab-.L__wine_spec_ne_header\n", /* ne_rsrctab */ 642 get_asm_short_keyword() ); 643 output( "\t%s .L__wine_spec_ne_restab-.L__wine_spec_ne_header\n", /* ne_restab */ 644 get_asm_short_keyword() ); 645 output( "\t%s .L__wine_spec_ne_modtab-.L__wine_spec_ne_header\n", /* ne_modtab */ 646 get_asm_short_keyword() ); 647 output( "\t%s .L__wine_spec_ne_imptab-.L__wine_spec_ne_header\n", /* ne_imptab */ 648 get_asm_short_keyword() ); 649 output( "\t.long 0\n" ); /* ne_nrestab */ 650 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_cmovent */ 651 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_align */ 652 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_cres */ 653 output( "\t.byte 0x%02x\n", NE_OSFLAGS_WINDOWS ); /* ne_exetyp */ 654 output( "\t.byte 0x%02x\n", NE_AFLAGS_FASTLOAD ); /* ne_flagsothers */ 655 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_pretthunks */ 656 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_psegrefbytes */ 657 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_swaparea */ 658 output( "\t%s 0\n", get_asm_short_keyword() ); /* ne_expver */ 659 660 /* segment table */ 661 662 output( "\n.L__wine_spec_ne_segtab:\n" ); 663 664 /* code segment entry */ 665 666 output( "\t%s .L__wine_spec_code_segment-%s\n", /* filepos */ 667 get_asm_short_keyword(), header_name ); 668 output( "\t%s .L__wine_spec_code_segment_end-.L__wine_spec_code_segment\n", /* size */ 669 get_asm_short_keyword() ); 670 output( "\t%s 0x%04x\n", get_asm_short_keyword(), NE_SEGFLAGS_32BIT ); /* flags */ 671 output( "\t%s .L__wine_spec_code_segment_end-.L__wine_spec_code_segment\n", /* minsize */ 672 get_asm_short_keyword() ); 673 674 /* data segment entry */ 675 676 output( "\t%s .L__wine_spec_data_segment-%s\n", /* filepos */ 677 get_asm_short_keyword(), header_name ); 678 output( "\t%s .L__wine_spec_data_segment_end-.L__wine_spec_data_segment\n", /* size */ 679 get_asm_short_keyword() ); 680 output( "\t%s 0x%04x\n", get_asm_short_keyword(), NE_SEGFLAGS_DATA ); /* flags */ 681 output( "\t%s .L__wine_spec_data_segment_end-.L__wine_spec_data_segment\n", /* minsize */ 682 get_asm_short_keyword() ); 683 684 /* resource directory */ 685 686 output_res16_directory( spec, header_name ); 687 688 /* resident names table */ 689 690 output( "\n\t.align %d\n", get_alignment(2) ); 691 output( ".L__wine_spec_ne_restab:\n" ); 692 output_resident_name( spec->dll_name, 0 ); At conditional (19): "i <= (spec)->limit" taking true path 693 for (i = 1; i <= spec->limit; i++) 694 { Event overrun-local: Overrun of dynamic array "(spec)->ordinals" of size 4 at position 4 with index variable "(i * 4)" Also see events: [buffer_alloc][var_assign] 695 ORDDEF *odp = spec->ordinals[i];

3 2

.pdb files for wine's gecko?
by Dan Kegel June 28, 2008

June 28, 2008

Hey Jacek, are .pdb files matching Wine's gecko available? Courtesy of John Reiser I now have a valgrind that can look at .pdb files for symbols, so I might be able to get you good backtraces for valgrind errors involving gecko if I had the right .pdb files. Thanks, Dan

1 0

Re: setupapi: Stub for SetupLogFile [resend]
by James Hawkins June 28, 2008

June 28, 2008

2008/6/28 Vitaly Perov <vitperov(a)etersoft.ru>: > Changelog: > - setupapi: Stub for SetupLogFile > + FIXME("(%p,'%s','%s','%s',%d,'%s','%s','%s',%d):stub\n", FileLogHandle, debugstr_w(LogSectionName), debugstr_w(SourceFileName), debugstr_w(TargetFileName), Checksum, debugstr_w(DiskTagfile), debugstr_w(DiskDescription), debugstr_w(OtherInfo), Flags); This line is more than 3 times the maximum length allowed for lines. The maximum length for lines is 80 columns, and while you can change that by, say, +-10 or so, it certainly shouldn't be 256 columns long. -- James Hawkins

1 0

Re: Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside opengl, code
by Roderick Colenbrander June 28, 2008

June 28, 2008

Hi, I don't think we want to go this way. First of all we want to emulate win32 opengl. If windows does this we MIGHT have to do something like this. Second all opengl calls hit ENTER_GL / LEAVE_GL and these few extra calls affect performance. Personally I think that when you are hitting such an X11 lock exception that there is just a bug somewhere in wine. E.g. in case of a Direct3D app a piece of wined3d not doing proper locking. The same can be the case for plain opengl apps where a call might not have called wine_tsx11_unlock. Regards, Roderick Colenbrander > From 31327546fc30520c80433fc964d7bd3ba4f80fa9 Mon Sep 17 00:00:00 2001 > From: Massimo Del Fedele <max(a)veneto.com> > Date: Sat, 28 Jun 2008 12:00:17 +0200 > Subject: Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside > opengl > code > > --- > dlls/opengl32/opengl_ext.h | 8 ++++++-- > dlls/opengl32/wgl.c | 6 ++++++ > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/dlls/opengl32/opengl_ext.h b/dlls/opengl32/opengl_ext.h > index 8ae7c2f..9892351 100644 > --- a/dlls/opengl32/opengl_ext.h > +++ b/dlls/opengl32/opengl_ext.h > @@ -40,6 +40,9 @@ > #define WINAPI __stdcall > #define APIENTRY WINAPI > > +#include "wine/library.h" > +#include "wine/exception.h" > + > /* X11 locking */ > > extern void (*wine_tsx11_lock_ptr)(void); > @@ -47,8 +50,9 @@ extern void (*wine_tsx11_unlock_ptr)(void); > > /* As GLX relies on X, this is needed */ > void enter_gl(void); > -#define ENTER_GL() enter_gl() > -#define LEAVE_GL() wine_tsx11_unlock_ptr() > +void CALLBACK leave_gl(BOOL); > +#define ENTER_GL() enter_gl(); __TRY { > +#define LEAVE_GL() } __FINALLY(leave_gl) > > > typedef struct { > diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c > index 6fbdeb4..7e31e20 100644 > --- a/dlls/opengl32/wgl.c > +++ b/dlls/opengl32/wgl.c > @@ -114,6 +114,12 @@ void enter_gl(void) > return; > } > > +void CALLBACK leave_gl(BOOL dummy) > +{ > + wine_tsx11_unlock_ptr(); > + return; > +} > + > const GLubyte * WINAPI wine_glGetString( GLenum name ); > > /*********************************************************************** > -- > 1.5.4.3 > > > -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: gdiplus benefits from valgrind testing when running DNS 9.0
by Susan Cragin June 28, 2008

June 28, 2008

-----Original Message----- >From: Nikolay Sivov <bunglehead(a)gmail.com> >Sent: Jun 28, 2008 9:23 AM >To: Susan Cragin <susancragin(a)earthlink.net> >Cc: Wine Developers <wine-devel(a)winehq.org> >Subject: Re: gdiplus benefits from valgrind testing when running DNS 9.0 > >Susan Cragin wrote: >> -----Original Message----- >> >>> From: Nikolay Sivov <bunglehead(a)gmail.com> >>> Sent: Jun 28, 2008 8:44 AM >>> To: Susan Cragin <susancragin(a)earthlink.net> >>> Subject: Re: gdiplus benefits from valgrind testing when running DNS 9.0 >>> >>> Susan Cragin wrote: >>> >>>> Whoops. Forgot one thing. >>>> When trying to run the program again, after the install, the following error prevents it from running again. >>>> >>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting >>>> fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> >>>>> From: Susan Cragin <susancragin(a)earthlink.net> >>>>> Sent: Jun 28, 2008 8:27 AM >>>>> To: Wine Developers List <wine-devel(a)winehq.org> >>>>> Subject: gdiplus benefits from valgrind testing when running DNS 9.0 >>>>> >>>>> I tried installing and running Dragon NaturallySpeaking 9.0 yesterday with wine's gdiplus. >>>>> wine-1.1.0 >>>>> >>>>> The program installed well, and training worked, too. Recognition during training was fast enough to keep up. Running it worked up to a point, but when it finally crashed I was trying something that doesn't always work anyway. >>>>> >>>>> Here are the install gdiplus warnings: >>>>> >>>>> fixme:gdiplus:GdipSetLinePresetBlend not implemented >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=7c80a46c, edge=2081853302, rc=(589886,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> fixme:shell:SHAppBarMessage msg=2, data={cb=36, hwnd=0x60058, callback=7c1520e1, edge=1, rc=(0,0)-(800,28), lparam=ffffffec}: stub >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> err:ntdll:RtlpWaitForCriticalSection section 0xcc3bb8 "?" wait timed out in thread 00dd, blocked by 005e, retrying (60 sec) >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf41c, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>>>> >>>>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf470, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> fixme:oleacc:AccessibleObjectFromWindow 0x1009a 0 {618736e0-3c3d-11cf-810c-00aa00389b71} 0x33f17c >>>>> >>>>> ------------------------------- >>>>> Here are the run warnings: >>>>> ------------------------------- >>>>> >>>>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>>>> >>>>> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting >>>>> >>>>> >>>>> err:ntdll:RtlpWaitForCriticalSection section 0x7bc932c4 "loader.c: loader_section" wait timed out in thread 00dd, blocked by 003a, retrying (60 sec) >>>>> >>>>> This next one eventually crashed the program. >>>>> >>>>> >>> I think I could fill this gap (GdipCreateLineBrushFromRectWithAngleI) >>> next week. There's nothing to stop this, I mean any >>> others unimplemented features of GDI+. >>> >> >> Let me clarify as well as I am able why I sent this message, because I am not a developer, just a tester, and I know you are not familiar with Dragon NaturallySpeaking. >> A couple of weeks ago, non-native gdiplus was essential to training the DNS 9.0 voice model. Training was so slow between speech and recognition that training wouldn't complete. That is no longer the case. The recognition model works fast enough to complete training. In fact, it works very fast. >> >Sounds good. So you think performance increases actually due gdiplus >changes? As for me I don't think so To be honest, I don't know because I'm not a programmer. I usually filter my findings through Dan Kegel. But I can tell you that training didn't complete last week, due to gdi problems, and it completes now. And the errors I see that led to the eventual program crash appear to be gdi errors.

1 0

Re: gdiplus benefits from valgrind testing when running DNS 9.0
by Susan Cragin June 28, 2008

June 28, 2008

-----Original Message----- >From: Nikolay Sivov <bunglehead(a)gmail.com> >Sent: Jun 28, 2008 8:44 AM >To: Susan Cragin <susancragin(a)earthlink.net> >Subject: Re: gdiplus benefits from valgrind testing when running DNS 9.0 > >Susan Cragin wrote: >> Whoops. Forgot one thing. >> When trying to run the program again, after the install, the following error prevents it from running again. >> >> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting >> fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set >> >> >> >> -----Original Message----- >> >>> From: Susan Cragin <susancragin(a)earthlink.net> >>> Sent: Jun 28, 2008 8:27 AM >>> To: Wine Developers List <wine-devel(a)winehq.org> >>> Subject: gdiplus benefits from valgrind testing when running DNS 9.0 >>> >>> I tried installing and running Dragon NaturallySpeaking 9.0 yesterday with wine's gdiplus. >>> wine-1.1.0 >>> >>> The program installed well, and training worked, too. Recognition during training was fast enough to keep up. Running it worked up to a point, but when it finally crashed I was trying something that doesn't always work anyway. >>> >>> Here are the install gdiplus warnings: >>> >>> fixme:gdiplus:GdipSetLinePresetBlend not implemented >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=7c80a46c, edge=2081853302, rc=(589886,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> fixme:shell:SHAppBarMessage msg=2, data={cb=36, hwnd=0x60058, callback=7c1520e1, edge=1, rc=(0,0)-(800,28), lparam=ffffffec}: stub >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> err:ntdll:RtlpWaitForCriticalSection section 0xcc3bb8 "?" wait timed out in thread 00dd, blocked by 005e, retrying (60 sec) >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf41c, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>> >>> fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf470, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> fixme:oleacc:AccessibleObjectFromWindow 0x1009a 0 {618736e0-3c3d-11cf-810c-00aa00389b71} 0x33f17c >>> >>> ------------------------------- >>> Here are the run warnings: >>> ------------------------------- >>> >>> fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub >>> >>> wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting >>> >>> >>> err:ntdll:RtlpWaitForCriticalSection section 0x7bc932c4 "loader.c: loader_section" wait timed out in thread 00dd, blocked by 003a, retrying (60 sec) >>> >>> This next one eventually crashed the program. >>> >I think I could fill this gap (GdipCreateLineBrushFromRectWithAngleI) >next week. There's nothing to stop this, I mean any >others unimplemented features of GDI+. Let me clarify as well as I am able why I sent this message, because I am not a developer, just a tester, and I know you are not familiar with Dragon NaturallySpeaking. A couple of weeks ago, non-native gdiplus was essential to training the DNS 9.0 voice model. Training was so slow between speech and recognition that training wouldn't complete. That is no longer the case. The recognition model works fast enough to complete training. In fact, it works very fast.

2 1

gdiplus benefits from valgrind testing when running DNS 9.0
by Susan Cragin June 28, 2008

June 28, 2008

I tried installing and running Dragon NaturallySpeaking 9.0 yesterday with wine's gdiplus. wine-1.1.0 The program installed well, and training worked, too. Recognition during training was fast enough to keep up. Running it worked up to a point, but when it finally crashed I was trying something that doesn't always work anyway. Here are the install gdiplus warnings: fixme:gdiplus:GdipSetLinePresetBlend not implemented fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=7c80a46c, edge=2081853302, rc=(589886,13361216)-(2081853346,13361216), lparam=cc00b0}: stub fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub fixme:shell:SHAppBarMessage msg=2, data={cb=36, hwnd=0x60058, callback=7c1520e1, edge=1, rc=(0,0)-(800,28), lparam=ffffffec}: stub fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub err:ntdll:RtlpWaitForCriticalSection section 0xcc3bb8 "?" wait timed out in thread 00dd, blocked by 005e, retrying (60 sec) fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf41c, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf470, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub fixme:oleacc:AccessibleObjectFromWindow 0x1009a 0 {618736e0-3c3d-11cf-810c-00aa00389b71} 0x33f17c ------------------------------- Here are the run warnings: ------------------------------- fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting err:ntdll:RtlpWaitForCriticalSection section 0x7bc932c4 "loader.c: loader_section" wait timed out in thread 00dd, blocked by 003a, retrying (60 sec) This next one eventually crashed the program.

2 1

Re: gdiplus benefits from valgrind testing when running DNS 9.0
by Susan Cragin June 28, 2008

June 28, 2008

Whoops. Forgot one thing. When trying to run the program again, after the install, the following error prevents it from running again. fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting fixme:dbghelp:dump_system_info fill in CPU vendorID and feature set -----Original Message----- >From: Susan Cragin <susancragin(a)earthlink.net> >Sent: Jun 28, 2008 8:27 AM >To: Wine Developers List <wine-devel(a)winehq.org> >Subject: gdiplus benefits from valgrind testing when running DNS 9.0 > >I tried installing and running Dragon NaturallySpeaking 9.0 yesterday with wine's gdiplus. >wine-1.1.0 > >The program installed well, and training worked, too. Recognition during training was fast enough to keep up. Running it worked up to a point, but when it finally crashed I was trying something that doesn't always work anyway. > >Here are the install gdiplus warnings: > >fixme:gdiplus:GdipSetLinePresetBlend not implemented > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=7c80a46c, edge=2081853302, rc=(589886,13361216)-(2081853346,13361216), lparam=cc00b0}: stub > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >fixme:shell:SHAppBarMessage msg=2, data={cb=36, hwnd=0x60058, callback=7c1520e1, edge=1, rc=(0,0)-(800,28), lparam=ffffffec}: stub > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >err:ntdll:RtlpWaitForCriticalSection section 0xcc3bb8 "?" wait timed out in thread 00dd, blocked by 005e, retrying (60 sec) > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf41c, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub > >fixme:shell:SHAppBarMessage msg=6, data={cb=36, hwnd=0x60058, callback=cbf470, edge=2081853302, rc=(1638456,13361216)-(2081853346,13361216), lparam=cc00b0}: stub > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >fixme:oleacc:AccessibleObjectFromWindow 0x1009a 0 {618736e0-3c3d-11cf-810c-00aa00389b71} 0x33f17c > >------------------------------- >Here are the run warnings: >------------------------------- > >fixme:gdiplus:GdipCreateHBITMAPFromBitmap stub > >wine: Call from 0x7b845630 to unimplemented function gdiplus.dll.GdipCreateLineBrushFromRectWithAngleI, aborting > > >err:ntdll:RtlpWaitForCriticalSection section 0x7bc932c4 "loader.c: loader_section" wait timed out in thread 00dd, blocked by 003a, retrying (60 sec) > >This next one eventually crashed the program. > > > > > >

1 0

Re: README: Add Russian translation (4th try)
by Andrey Turkin June 28, 2008

June 28, 2008

Hi Vladimir, There are a few punctuation issues still left. >Wine это программа >реализует вызовы Windows API >используя >В директории содержащей >решения проблем, прочтите extra comma here? >операционные системы перечисленные выше >У FreeBSD 6.3 есть патч разрешающий comma missed, and "позволяющий" seems to be better here >гарантирует > что >Убедитесь что, опции comma in wrong place >особенностей файловой системы необходимые некоторым comma missing >убедиться что, у вас comma in wrong place >Вероятно это лучшая начальная точка sounds weird >Вы так же можете отправлять should be "также" Vladimir Pankratov wrote: > Hello. > > Corrected some wrong strings. > Added README.ru file. > > Thanks fo help. >

1 0

new valgrind errors in riched20
by Dan Kegel June 28, 2008

June 28, 2008

Seem to be four or so new valgrind warnings in riched20 today, probably due to Dylan's changes (though my cat may have been sufing to friskies.com and affected the results, who knows): http://kegel.com/wine/valgrind/logs-2008-06-27/vg-riched20_editor-diff.txt + Invalid read of size 4 + at ME_AddUndoItem (undo.c:59) + by ME_SetParaFormat (para.c:362) + by ME_PlayUndoItem (undo.c:288) + by ME_Undo (undo.c:360) + by RichEditWndProc_common (editor.c:2067) + by RichEditWndProcA (editor.c:3386) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_call_window (winproc.c:2207) + by call_window_proc (message.c:1639) + by send_message (message.c:2463) + by SendMessageA (message.c:2608) + by test_EM_SETUNDOLIMIT (editor.c:2238) + by func_editor (editor.c:4581) + by run_test (test.h:449) + by main (test.h:498) ... + Conditional jump or move depends on uninitialised value(s) + at test_EM_AUTOURLDETECT (editor.c:1719) + by func_editor (editor.c:4600) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a client request + at mark_block_uninitialized (heap.c:164) + by RtlAllocateHeap (heap.c:1239) + by heap_alloc (editor.h:28) + by RichEditWndProc_common (editor.c:2573) + by RichEditWndProcA (editor.c:3386) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_call_window (winproc.c:2207) + by call_window_proc (message.c:1639) + by send_message (message.c:2463) + by SendMessageA (message.c:2608) + by test_EM_AUTOURLDETECT (editor.c:1705) + by func_editor (editor.c:4600) + by run_test (test.h:449) + by main (test.h:498) ... + Invalid write of size 4 + at ME_AddUndoItem (undo.c:62) + by ME_InternalDeleteText (caret.c:322) + by ME_PlayUndoItem (undo.c:308) + by ME_Undo (undo.c:360) + by RichEditWndProc_common (editor.c:2067) + by RichEditWndProcW (editor.c:3381) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:1011) + by WINPROC_call_window (winproc.c:2209) + by call_window_proc (message.c:1639) + by send_message (message.c:2463) + by SendMessageA (message.c:2608) + by test_undo_coalescing (editor.c:4398) + by func_editor (editor.c:4602) + by run_test (test.h:449) + by main (test.h:498) ... + Conditional jump or move depends on uninitialised value(s) + at ME_AddUndoItem (undo.c:59) + by ME_InternalDeleteText (caret.c:322) + by ME_PlayUndoItem (undo.c:308) + by ME_Undo (undo.c:360) + by RichEditWndProc_common (editor.c:2067) + by RichEditWndProcW (editor.c:3381) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:1011) + by WINPROC_call_window (winproc.c:2209) + by call_window_proc (message.c:1639) + by send_message (message.c:2463) + by SendMessageA (message.c:2608) + by test_undo_coalescing (editor.c:4398) + by func_editor (editor.c:4602) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a client request + at mark_block_uninitialized (heap.c:164) + by RtlAllocateHeap (heap.c:1239) + by heap_alloc (editor.h:28) + by ME_MakeStringN (string.c:46) + by ME_InternalDeleteText (caret.c:326) + by ME_PlayUndoItem (undo.c:308) + by ME_Undo (undo.c:360) + by RichEditWndProc_common (editor.c:2067) + by RichEditWndProcW (editor.c:3381) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:1011) + by WINPROC_call_window (winproc.c:2209) + by call_window_proc (message.c:1639) + by send_message (message.c:2463) + by SendMessageA (message.c:2608) + by test_undo_coalescing (editor.c:4398) + by func_editor (editor.c:4602) + by run_test (test.h:449) + by main (test.h:498)

2 1

new valgrind errors in gdiplus
by Dan Kegel June 28, 2008

June 28, 2008

Nikolai, your changes in http://source.winehq.org/git/wine.git/?a=commit;h=629761acde13283e0dfc6c42c… seem to have two valgrind errors, http://kegel.com/wine/valgrind/logs-2008-06-27/vg-gdiplus_graphicspath-diff… + Conditional jump or move depends on uninitialised value(s) + at GdipAddPathPolygon (graphicspath.c:353) + by test_polygon (graphicspath.c:608) + by func_graphicspath (graphicspath.c:692) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_polygon (graphicspath.c:589) ... + Conditional jump or move depends on uninitialised value(s) + at GdipAddPathPolygon (graphicspath.c:353) + by test_polygon (graphicspath.c:611) + by func_graphicspath (graphicspath.c:692) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_polygon (graphicspath.c:589) Could you have a look?

2 1

new valgrind errors in qedit / quartz
by Dan Kegel June 28, 2008

June 28, 2008

Hi Maarten, your recent changes may have triggered new valgrind warnings in qedit, could you have a look? http://kegel.com/wine/valgrind/logs-2008-06-27/vg-qedit_mediadet-diff.txt + Conditional jump or move depends on uninitialised value(s) + at FilterGraph2_RemoveFilter (filtergraph.c:463) + by FilterGraphInner_Release (filtergraph.c:295) + by Filtergraph_Release (filtergraph.c:5354) + by FilterGraph2_Release (filtergraph.c:341) + by MD_cleanup (mediadet.c:54) + by MediaDet_Release (mediadet.c:76) + by test_mediadet (mediadet.c:224) + by func_mediadet (mediadet.c:307) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a client request + at mark_block_uninitialized (heap.c:164) + by RtlAllocateHeap (heap.c:1239) + by IMalloc_fnAlloc (ifs.c:186) + by CoTaskMemAlloc (ifs.c:562) + by AsyncReader_create (filesource.c:346) + by DSCF_CreateInstance (main.c:129) + by CoCreateInstance (compobj.c:2408) + by FilterGraph2_AddSourceFilter (filtergraph.c:1499) + by MediaDet_put_Filename (mediadet.c:446) + by test_mediadet (mediadet.c:149) + by func_mediadet (mediadet.c:307) + by run_test (test.h:449) + by main (test.h:498) ... + Conditional jump or move depends on uninitialised value(s) + at FilterGraph2_RemoveFilter (filtergraph.c:465) + by FilterGraphInner_Release (filtergraph.c:295) + by Filtergraph_Release (filtergraph.c:5354) ...

1 0

Re: Downgrade lack of libxslt from configure warning to notice (RESEND)
by Steven Edwards June 28, 2008

June 28, 2008

On Fri, Jun 27, 2008 at 6:24 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Looking that libxslt only seems to be used by msxml3, I am wondering > whether this really is worth a warning? msi depends on msxml3 for some features. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Menu entries?
by Warren Dumortier June 28, 2008

June 28, 2008

Hi! What would you think of adding an entry in the wine menu to: 1) Launch wine reboot 2)Kill all wine processes This would be nice, imo. Also adding a error dialog when a program crashes or when a dll is missing would be nice. Kind regards, warren

3 2

Leveraging a win32 codebase with a native Linux app and Wine
by Michel Jacques June 27, 2008

June 27, 2008

Hello, I would like to reuse a large codebase composed of many win32 dlls within a NATIVE Linux app. I have tested with winelib but it seems that the only way to do this is to use a recompiled win32 app in combination with my recompiled win32 dlls. Is there a way to reuse my recompiled win32 dlls (.so) directly within a native Linux app just as I would use regualr Linux dynamic libraries (.so) ? Thanks, Michel J.

2 1

Re: README: Add Russian translation (3rd try)
by Nikolay Sivov June 27, 2008

June 27, 2008

Vladimir Pankratov wrote: > Hello. > > I corrected punctuation and some sentences. > > Changelog: > Added README.ru file. > > Thanks for help. You may think I'm terrorizing you but I just want to get it better :). Something more: > Другие операционные системы которые поддерживают нити ядра могут поддерживаться в будущем. "системы, которые поддерживают нити ядра, могут" > Убедитесь что опции USER_LDT, SYSVSHM, SYSVSEM и SYSVMSG > включены в вашем ядре. "Убедитесь, что"

2 1

Should this be updated?
by martti June 27, 2008

June 27, 2008

*2.12. *When will Wine be finished? * * Large software projects are never finished, only released. In any case Wine is chasing a moving target since every new release of Windows contains new API calls or variations on the existing ones. Because Wine is being developed mainly by a single company (CodeWeavers) and volunteers, it is difficult to predict when it will be ready for general release. But due to the much increased interest by other companies in porting apps via Wine, Wine development is constantly getting more and more active. *Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005.*

1 0

Re: richedit: Implemented EM_STOPGROUPTYPING, fixed undo grouping (with tests)
by Alex Villacís Lasso June 27, 2008

June 27, 2008

Dylan Smith escribió: > EM_STOPGROUPTYPING simply ends the undo coalescing transaction. The > remarks for this message on MSDN explains what events stops group > typing, which led me to adding the delete key to the actions that stop > group typing. > > The tests that are included with this patch verify the correctness of > the changes. > > This patch depends on a previous patch I submitted, which has an email > subject "[6/44] richedit: Implemented undo coalescing to group typing > events", and was submitted on June 17. > --- > dlls/riched20/editor.c | 12 ++++++++++-- > dlls/riched20/tests/editor.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 50 insertions(+), 2 deletions(-) > This patch has the corresponding test. Could you please send a patch (one or more) that would test the behaviors fixed by the previous patches? This will make it more likely for AJ to accept the patches, and will also prevent someone (such as myself) from accidentally breaking fixed behavior with further changes. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

3 3

Re: Gdiplus [1/3] Improve accuracy in calculating height
by Huw Davies June 27, 2008

June 27, 2008

On Fri, Jun 27, 2008 at 10:16:41AM -0400, Adam Petaccia wrote: > The previous patch I sent incorrectly calculated font-height. Now its > correctly calculated using points_per_inch and the user's DPI setting. > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 86a3223..85df905 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -34,6 +34,7 @@ WINE_DEFAULT_DEBUG_CHANNEL (gdiplus); > #include "gdiplus_private.h" > > static const REAL mm_per_pixel = 25.4; > +static const REAL points_per_inch = 1/72; > I know there are several definitions of a point, but none are this big! points_per_inch should be around 72. > @@ -50,7 +51,7 @@ static inline REAL get_dpi (void) > > static inline REAL point_to_pixel (REAL point) > { > - return point * 1.5; > + return point * (get_dpi() * points_per_inch); And this then becomes points * get_dpi() / points_per_inch; [Hint check the units: pixels (aka dots) = points * (dots / inch) / (points / inch) ] Huw. -- Huw Davies huw(a)codeweavers.com

3 3

yes I am trying to get feedback before I put it...
by celticht32＠aol.com June 27, 2008

June 27, 2008

on the patch list... The first patch is for a bug I tracked down in context.c that is causing some of the behavior that wine is having with the ATI graphics driver. The second patch? was something I noticed in the code as well that looked a little off which also relates to the way iPixel shaders are init in the d3d code. So I came on here to get some feedback first before taking it to the patch group as something. This was to start getting my feet wet before I took up potentially some development task or the like. not sure about why the mailer is replacing spaces with ? that I do not know... Chris Ahrendt

3 2

Re: inetmib1(1/5): Make table searching function into a generic helper, and use it to search all tables for instances (resend)
by Alexandre Julliard June 27, 2008

June 27, 2008

"Juan Lang" <juan.lang(a)gmail.com> writes: > Hi, these remaining five patches ended up on the cutting room floor. > Did this cause a test failure, or is there something else I missed? Yes, the tests fail: ../../../tools/runtest -q -P wine -M inetmib1.dll -T ../../.. -p inetmib1_test.exe.so main.c && touch main.ok main.c:190: Test failed: expected 7, got 1 main.c:196: Test failed: expected 7, got 1 main.c:202: Test failed: expected 7, got 1 main.c:190: Test failed: expected 8, got 2 main.c:196: Test failed: expected 8, got 2 main.c:202: Test failed: expected 8, got 2 main.c:190: Test failed: expected 9, got 3 main.c:196: Test failed: expected 9, got 3 main.c:202: Test failed: expected 9, got 3 main.c:190: Test failed: expected 10, got 4 main.c:196: Test failed: expected 10, got 4 main.c:202: Test failed: expected 10, got 4 main.c:190: Test failed: expected 11, got 5 main.c:196: Test failed: expected 11, got 5 main.c:202: Test failed: expected 11, got 5 etc... -- Alexandre Julliard julliard(a)winehq.org

1 0

in response to Alistair
by Christopher J. Ahrendt June 27, 2008

June 27, 2008

is the path getting passed in? OR is it in an ini file that is read... Either way you could parse the first few characters for the usual windows / dos format and branch that way....

3 2

re: Ok guys...
by Dan Kegel June 27, 2008

June 27, 2008

Your subject line was confusing; what's this about? Your patches seem malformed, they come across with question marks for tabs, e.g. --- context.c??? 2008-06-26 13:52:57.000000000 -0400 +++ context.c.patch1??? 2008-06-26 15:19:15.000000000 -0400 @@ -145,9 +145,7 @@ static int WineD3D_ChoosePixelFormat(IWi ? ???? DepthStencilFormat = WINED3DFMT_D24S8; ? -??? if(DepthStencilFormat) { -??????? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); -??? } +??? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); Perhaps you should resend, using a proper subject line, attaching one patch per message, and providing a good description of what each patch does. If you expect the patches to be applied, they need to go to wine-patches, not wine-devel.

3 3

gdiplus/graphicspath test crashes
by Paul Vriens June 27, 2008

June 27, 2008

Hi, I've noticed that the mentioned tests crashes when run via Paul Millar's winetest executable. Compiling myself and running the test works fine. Any one else seeing this? -- Cheers, Paul.

3 5

Re: README: Add Russian translation (2nd try)
by Nikolay Sivov June 27, 2008

June 27, 2008

Vladimir Pankratov wrote: > Hello. > > Changelog: > Added README.ru file. > Corrected some errors and fixed text formatting (as I think) since > last patch. > Thanks. Further suggestions: > Wine это программа которая позволяет запускать программы Microsoft > Windows (включая DOS, Windows 3.x и Win32) на Unix. Она состоит из > программы загрузки которая загружает и выполняет программы Microsoft > Windows,и библиотеки (Winelib) которая реализует вызовы Windows API > используя их Unix или X11 эквиваленты. Библиотека также может быть > использована для переноса кода Win32 в исполняемые файлы Unix. Lots of punctuation here. Such as: - "программа, которая" - "программы загрузки, которая" - "библиотеки (Winelib), которая" It's better to say: "портирования кода Win32 в среду Unix." > Каждый раз когда вы компилируете исходный код, рекомендуется использовать > Wine Installer для компоновки и установки Wine. The same: - "Каждый раз, когда" > Для того чтобы скомпилировать и запустить Wine, необходимо одно из следующих: - "Компиляция и запуск Wine поддерживается в следующих операционных системах:" > Linux версии 2.0.36 или выше > FreeBSD 7.0 или позже Choose a single. I think "или выше" is better. > Хорошо иметь текущую версию ядра You're right)..But it's better to say: - "Лучше использовать текущую версию ядра 2.4.х или 2.6.х" > Лучше всего компоновать Wine с инструментами GNU - "компоновать Wine инструментами GNU" > Внимание : установка gas *НЕ* обеспечивает что gcc будет его использовать. - "Внимание : установка gas *НЕ* гарантирует, что gcc будет его использовать." > Перекомпилируйте gcc после установки gas или слинковать cc, > as and ld to the gnu tools is said to be necessary. What's that? > NetBSD: > Будьте уверены что опции USER_LDT, SYSVSHM, SYSVSEM, и SYSVMSG > включены в вашем ядре. - "Убедитесь, что опции" - "SYSVSEM и SYSVMSG" > Мало проблем с совместимостью было получено используя файлы доступные через Samba. I think this should be paraphrased. > Конфигурационный скрипт выведет список дополнительных библиотек которые не были > найдены в вашей системе. - "дополнительных библиотек, которые" > На 64-битных платформах вы должны быть уверены что у вас установлены 32-битные > версии этих библиотек; смотрите http://wiki.winehq.org/WineOn64bit > для деталей. - "вы должны убедитсья, что"; - "за более подробной информацией обратитесь к http://wiki.winehq.org/WineOn64bit." > Затем введите "make clean", и пропачтите релиз: - "пропачьте" > Сначала не забудьте удалить любые конфликтные предыдущие установки Wine. Words missed. > Посетите Службу подержки на http://www.winehq.org/ дополнительных сведений. Something missed too. > wine notepad (using the search Path as specified in > wine notepad.exe the config file to locate the file) Untranslated part here. > Wine еще не завершен, поэтому некоторые программы могут вызывать ошибку. - "Wine находится в состоянии разработки, поэтому некоторые программы могут вызывать ошибку." > Во время ошибки вы будете направлены в отладчик для того чтобы вы могли > исследовать и решить проблему. - "в отладчик для того, чтобы вы могли" I think all main problems are here. Maybe some further revise is needed after commit so feel free to improve it please.

1 0

Re: msxml3: Added xml Input Callbacks to support loading files from aWine windows drive (try 2)
by Alistair Leslie-Hughes June 27, 2008

June 27, 2008

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:g3t5ej$qs7$1(a)ger.gmane.org... > +/* Support for loading xml files from a Wine Windows drive */ > +static int wineXmlMatchCallback (char const * filename) > +{ > + BSTR sFilename = bstr_from_xmlChar( (xmlChar*)filename); > + BSTR sColon = bstr_from_xmlChar( (xmlChar*)":"); > + int nRet = 0; > + > + TRACE("%s\n", debugstr_w(sFilename)); > + > + /* > + * We will deal with loading XML files from the file system > + * We only care about files that linux cannot find. > + * e.g. C:,D: etc > + */ > + if(iswalpha(sFilename[0]) && sFilename[1] == sColon[0]) > + nRet = 1; > + Hi, The file detection is what is causing this patch not to be accepted. For reference http://bugs.winehq.org/show_bug.cgi?id=11325 - Summary: This script attempts to load a script from disk with a windows path (Z:\blah\rooms\room1.xml), and libxml doesnt understand how to use load this file. During startup, libxml attempts to load its DTD's from the /etc/ directory, (it uses the format file:///etc/xml/DTD.xml), and we dont want to handle these files, but we do want to handle windows paths. What method can I use to detected a windows path verses a unix path? Best Regards Alistair Leslie-Hughes

1 0

Re: gdiplus: font.c: ensure to release resources
by Huw Davies June 26, 2008

June 26, 2008

Joris Huizer wrote: > A modified patch, taking hints into account from Huw Davies > You need to select out the hfont before deleting it. So the SelectObject should look like hfont_old = SelectObject(hdc, hfont); then after the GetTextMetrics do DeleteObject(SelectObject(hdc, hfont_old)) (then you don't need the two sets of DeleteObject) Huw.

2 1

Ok guys...
by celticht32＠aol.com June 26, 2008

June 26, 2008

Thank you so much for being patient and showing me how to do this.. with much help from everyone here is what the results are : Patch 1 : File : wine-1.0/dlls/wined3d/context.c --- context.c??? 2008-06-26 13:52:57.000000000 -0400 +++ context.c.patch1??? 2008-06-26 15:19:15.000000000 -0400 @@ -145,9 +145,7 @@ static int WineD3D_ChoosePixelFormat(IWi ? ???? DepthStencilFormat = WINED3DFMT_D24S8; ? -??? if(DepthStencilFormat) { -??????? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); -??? } +??? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); ? ???? /* Find a pixel format which EXACTLY matches our requirements (except for depth) */ ???? for(i=0; i<nCfgs; i++) { Patch 2: File: wine-1.0/dlls/wined3d/context.c --- context.c??? 2008-06-26 13:52:57.000000000 -0400 +++ context.c.patch2??? 2008-06-26 15:37:25.000000000 -0400 @@ -120,7 +120,9 @@ static int WineD3D_ChoosePixelFormat(IWi ???? int i = 0; ???? int nCfgs = This->adapter->nCfgs; ???? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; - +??? PIXELFORMATDESCRIPTOR pfd; +??? BOOL exactDepthMatch = TRUE; +??????????? ???? TRACE("ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d, pbuffer=%d, findCompatible=%d\n", ?????????? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat), auxBuffers, numSamples, pbuffer, findCompatible); ? @@ -151,7 +153,6 @@ static int WineD3D_ChoosePixelFormat(IWi ? ???? /* Find a pixel format which EXACTLY matches our requirements (except for depth) */ ???? for(i=0; i<nCfgs; i++) { -??????? BOOL exactDepthMatch = TRUE; ???????? cfgs = &This->adapter->cfgs[i]; ? ???????? /* For now only accept RGBA formats. Perhaps some day we will @@ -180,13 +181,7 @@ static int WineD3D_ChoosePixelFormat(IWi ???????? if(cfgs->alphaSize != alphaBits) ???????????? continue; ? -??????? /* We try to locate a format which matches our requirements exactly. In case of -???????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ -??????? if(cfgs->depthSize < depthBits) -??????????? continue; -??????? else if(cfgs->depthSize > depthBits) -??????????? exactDepthMatch = FALSE; - +??????? ???????? /* In all cases make sure the number of stencil bits matches our requirements ????????? * even when we don't need stencil because it could affect performance EXCEPT ????????? * on cards which don't offer depth formats without stencil like the i915 drivers @@ -198,6 +193,13 @@ static int WineD3D_ChoosePixelFormat(IWi ???????? if(cfgs->numSamples != numSamples) ???????????? continue; ? +?????? /* We try to locate a format which matches our requirements exactly. In case of +???????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ +??????? if(cfgs->depthSize < depthBits) +??????????? continue; +??????? else if(cfgs->depthSize > depthBits) +??????????? exactDepthMatch = FALSE; + ???????? /* When we have passed all the checks then we have found a format which matches our ????????? * requirements. Note that we only check for a limit number of capabilities right now, ????????? * so there can easily be a dozen of pixel formats which appear to be the 'same' but @@ -216,12 +218,8 @@ static int WineD3D_ChoosePixelFormat(IWi ???????? } ???? } ? -??? /* When findCompatible is set and no suitable format was found, let ChoosePixelFormat choose a pixel format in order not to crash. */ -??? if(!iPixelFormat && !findCompatible) { -??????? ERR("Can't find a suitable iPixelFormat\n"); -??????? return FALSE; -??? } else if(!iPixelFormat) { -??????? PIXELFORMATDESCRIPTOR pfd; +??? if(!iPixelFormat) { + ? ???????? TRACE("Falling back to ChoosePixelFormat as we weren't able to find an exactly matching pixel format\n"); ???????? /* PixelFormat selection */ Chris Ahrendt P.S. THANKS everyone.. so now comments please? <G>

1 0

ok lets try this yet again
by celticht32＠aol.com June 26, 2008

June 26, 2008

I am sorry everyone for the spam =) been awhile since I developed stuff, been so used to designing things? =) here in all its glorry is the diff -u context.c context.c.new > diff.txt file I couldnt get the -c option to work so here is just the -u --- context.c??? 2008-06-26 13:52:57.000000000 -0400 +++ context.c.change??? 2008-06-26 14:32:48.000000000 -0400 @@ -116,13 +116,12 @@ ???? int iPixelFormat=0; ???? short redBits, greenBits, blueBits, alphaBits, colorBits; ???? short depthBits=0, stencilBits=0; - ???? int i = 0; ???? int nCfgs = This->adapter->nCfgs; -??? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; ? -??? TRACE("ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d, pbuffer=%d, findCompatible=%d\n", -????????? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat), auxBuffers, numSamples, pbuffer, findCompatible); +??? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; +??? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */?? +??? PIXELFORMATDESCRIPTOR pfd;???? /*Changed june 23,08 */ ? ???? if(!getColorBits(ColorFormat, &redBits, &greenBits, &blueBits, &alphaBits, &colorBits)) { ???????? ERR("Unable to get color bits for format %s (%#x)!\n", debug_d3dformat(ColorFormat), ColorFormat); @@ -145,84 +144,91 @@ ? ???? DepthStencilFormat = WINED3DFMT_D24S8; ? -??? if(DepthStencilFormat) { -??????? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); -??? } +/* Changed Section June 24,08 */ + +#if 0 +??? if(DepthStencilFormat) +????? {???????????????????? +??? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); +??? } +#endif + +/* Just call getDepthStencilBits as the above IF will always in this case be true */ + +??? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); ? ???? /* Find a pixel format which EXACTLY matches our requirements (except for depth) */ -??? for(i=0; i<nCfgs; i++) { -??????? BOOL exactDepthMatch = TRUE; +??? for(i=0; i<nCfgs; i++) +????? { ???????? cfgs = &This->adapter->cfgs[i]; - +??????????????????? ???????? /* For now only accept RGBA formats. Perhaps some day we will ????????? * allow floating point formats for pbuffers. */ ???????? if(cfgs->iPixelType != WGL_TYPE_RGBA_ARB) -??????????? continue; +?????????? continue; ? ???????? /* In window mode (!pbuffer) we need a window drawable format and double buffering. */ ???????? if(!pbuffer && !(cfgs->windowDrawable && cfgs->doubleBuffer)) -??????????? continue; +?????????? continue; ? -??????? /* We like to have aux buffers in backbuffer mode */ +?????? /* We like to have aux buffers in backbuffer mode */ ???????? if(auxBuffers && !cfgs->auxBuffers) -??????????? continue; +?????????? continue; ? ???????? /* In pbuffer-mode we need a pbuffer-capable format but we don't want double buffering */ ???????? if(pbuffer && (!cfgs->pbufferDrawable || cfgs->doubleBuffer)) -??????????? continue; +???????????? continue; ? -??????? if(cfgs->redSize != redBits) -??????????? continue; -??????? if(cfgs->greenSize != greenBits) -??????????? continue; -??????? if(cfgs->blueSize != blueBits) -??????????? continue; -??????? if(cfgs->alphaSize != alphaBits) -??????????? continue; - -??????? /* We try to locate a format which matches our requirements exactly. In case of -???????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ -??????? if(cfgs->depthSize < depthBits) -??????????? continue; -??????? else if(cfgs->depthSize > depthBits) -??????????? exactDepthMatch = FALSE; +??????? if ((cfgs->redSize != redBits) || (cfgs->greenSize != greenBits) || (cfgs->blueSize != blueBits) || (cfgs->alphaSize != alphaBits)) +???????????? continue; ? ???????? /* In all cases make sure the number of stencil bits matches our requirements ????????? * even when we don't need stencil because it could affect performance EXCEPT ????????? * on cards which don't offer depth formats without stencil like the i915 drivers ????????? * on Linux. */ -??????? if(stencilBits != cfgs->stencilSize && !(This->adapter->brokenStencil && stencilBits <= cfgs->stencilSize)) -??????????? continue; +??????? if((stencilBits != cfgs->stencilSize) && !((This->adapter->brokenStencil && stencilBits) <= cfgs->stencilSize)) +???????????? continue; ? ???????? /* Check multisampling support */ ???????? if(cfgs->numSamples != numSamples) -??????????? continue; +???????????? continue; ? -??????? /* When we have passed all the checks then we have found a format which matches our -???????? * requirements. Note that we only check for a limit number of capabilities right now, -???????? * so there can easily be a dozen of pixel formats which appear to be the 'same' but -???????? * can still differ in things like multisampling, stereo, SRGB and other flags. -???????? */ +??????? /* We try to locate a format which matches our requirements exactly. In case of +???????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ +???????? if (cfgs->depthSize !=? depthBits) +??????????? continue; ? ???????? /* Exit the loop as we have found a format :) */ -??????? if(exactDepthMatch) { +??????? if (exactDepthMatch) +?????????? { +??????????? TRACE("Exact Depth Match\n"); ???????????? iPixelFormat = cfgs->iPixelFormat; ???????????? break; -??????? } else if(!iPixelFormat) { +?????????? } +??????? if (!iPixelFormat) +????????? { ???????????? /* In the end we might end up with a format which doesn't exactly match our depth ????????????? * requirements. Accept the first format we found because formats with higher iPixelFormat ????????????? * values tend to have more extended capabilities (e.g. multisampling) which we don't need. */ + +??????????? TRACE("Emulating %d\n",cfgs->iPixelFormat); ???????????? iPixelFormat = cfgs->iPixelFormat; -??????? } +??????????? break; /* Added June 24,08 */ +????????? } ???? } ? ???? /* When findCompatible is set and no suitable format was found, let ChoosePixelFormat choose a pixel format in order not to crash. */ -??? if(!iPixelFormat && !findCompatible) { + +#if 0??? +if (!iPixelFormat && !findCompatible) +????? { ???????? ERR("Can't find a suitable iPixelFormat\n"); ???????? return FALSE; -??? } else if(!iPixelFormat) { -??????? PIXELFORMATDESCRIPTOR pfd; - +????? } +#endif +????? +??? if (!iPixelFormat) +????? { ???????? TRACE("Falling back to ChoosePixelFormat as we weren't able to find an exactly matching pixel format\n"); ???????? /* PixelFormat selection */ ???????? ZeroMemory(&pfd, sizeof(pfd)); @@ -235,16 +241,17 @@ ???????? pfd.cDepthBits = depthBits; ???????? pfd.cStencilBits = stencilBits; ???????? pfd.iLayerType = PFD_MAIN_PLANE; - +??????? ???????? iPixelFormat = ChoosePixelFormat(hdc, &pfd); -??????? if(!iPixelFormat) { -??????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ -??????????? ERR("Can't find a suitable iPixelFormat\n"); -??????????? return FALSE; -??????? } -??? } +??????? if (!iPixelFormat) +????????? { +?????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ +?????????? ERR("Can't find a suitable iPixelFormat\n"); +?????????? return FALSE; +????????? } +????? } ? -??? TRACE("Found iPixelFormat=%d for ColorFormat=%s, DepthStencilFormat=%s\n", iPixelFormat, debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat)); +??? TRACE("Found iPixelFormat\n"); ???? return iPixelFormat; ?} ? @@ -372,6 +379,7 @@ ? ???????? /* If we still don't have a pixel format, something is very wrong as ChoosePixelFormat barely fails */ ???????? if(!iPixelFormat) { +??????????? TRACE("Choose Pixel Format Failed\n"); ???????????? ERR("Can't find a suitable iPixelFormat\n"); ???????????? return FALSE; ???????? } Better? Chris

4 3

Re: [6/7] gdiplus: Implemented GdipGetPathData with test
by Detlef Riekenberg June 26, 2008

June 26, 2008

Hi Nikolay: > + pathData->Points = GdipAlloc(sizeof(PointF) * pathData->Count); > + if(!pathData->Points) > + return OutOfMemory; > + > + pathData->Types = GdipAlloc(pathData->Count); > + if(!pathData->Points) Greetings from Copy & Paste pathData->Points => pathData->Types > + return OutOfMemory; You are leaking the memory in pathData->Points -- By by ... Detlef

1 0

context.c diff file...
by celticht32＠aol.com June 26, 2008

June 26, 2008

ok sorry for cutting and pasting the whole routine.. did not see to do just the diff ... (give the old guy a break.. I am an architect now not a programmer <G>) here is the diff : 119d118 < 122d120 <???? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; 124,125c122,124 <???? TRACE("ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d, pbuffer=%d, findCompatible=%d\n", <?????????? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat), auxBuffers, numSamples, pbuffer, findCompatible); --- >???? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; >???? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */?? >???? PIXELFORMATDESCRIPTOR pfd;???? /*Changed june 23,08 */ 148,150c147,151 <???? if(DepthStencilFormat) { <???????? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); <???? } --- > /* Changed Section June 24,08 */ > > /*??? if(DepthStencilFormat) {???????????????????? Changed June 19,08*/ >???? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); > /*??? } */ 153,154c154,155 <???? for(i=0; i<nCfgs; i++) { <???????? BOOL exactDepthMatch = TRUE; --- >???? for(i=0; i<nCfgs; i++) >?????? { 156c157 < --- >???????????????????? 160c161 <???????????? continue; --- >??????????? continue; 164c165 <???????????? continue; --- >??????????? continue; 166c167 <???????? /* We like to have aux buffers in backbuffer mode */ --- >??????? /* We like to have aux buffers in backbuffer mode */ 168c169 <???????????? continue; --- >??????????? continue; 172,181c173 <???????????? continue; < <???????? if(cfgs->redSize != redBits) <???????????? continue; <???????? if(cfgs->greenSize != greenBits) <???????????? continue; <???????? if(cfgs->blueSize != blueBits) <???????????? continue; <???????? if(cfgs->alphaSize != alphaBits) <???????????? continue; --- >????????????? continue; 183,188c175,176 <???????? /* We try to locate a format which matches our requirements exactly. In case of <????????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ <???????? if(cfgs->depthSize < depthBits) <???????????? continue; <???????? else if(cfgs->depthSize > depthBits) <???????????? exactDepthMatch = FALSE; --- >???????? if ((cfgs->redSize != redBits) || (cfgs->greenSize != greenBits) || (cfgs->blueSize != blueBits) || (cfgs->alphaSize != alphaBits)) >????????????? continue; 194,195c182,183 <???????? if(stencilBits != cfgs->stencilSize && !(This->adapter->brokenStencil && stencilBits <= cfgs->stencilSize)) <???????????? continue; --- >???????? if((stencilBits != cfgs->stencilSize) && !((This->adapter->brokenStencil && stencilBits) <= cfgs->stencilSize)) >????????????? continue; 199c187 <???????????? continue; --- >????????????? continue; 201,205c189,192 <???????? /* When we have passed all the checks then we have found a format which matches our <????????? * requirements. Note that we only check for a limit number of capabilities right now, <????????? * so there can easily be a dozen of pixel formats which appear to be the 'same' but <????????? * can still differ in things like multisampling, stereo, SRGB and other flags. <????????? */ --- >???????? /* We try to locate a format which matches our requirements exactly. In case of >????????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ >????????? if (cfgs->depthSize !=? depthBits) >???????????? continue; 208c195,197 <???????? if(exactDepthMatch) { --- >???????? if (exactDepthMatch) >??????????? { >???????????? TRACE("Exact Depth Match\n"); 211c200,202 <???????? } else if(!iPixelFormat) { --- >??????????? } >???????? if (!iPixelFormat) >?????????? { 214a206 >???????????? TRACE("Emulating %d\n",cfgs->iPixelFormat); 216c208,209 <???????? } --- >???????????? break; /* Added June 24,08 */ >?????????? } 220c213,215 <???? if(!iPixelFormat && !findCompatible) { --- > > /*??? if (!iPixelFormat && !findCompatible) >?????? { 223,225c218,222 <???? } else if(!iPixelFormat) { <???????? PIXELFORMATDESCRIPTOR pfd; < --- >?????? } > */ >?????? >???? if (!iPixelFormat) >?????? { 238c235 < --- >???????? 240,245c237,243 <???????? if(!iPixelFormat) { <???????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ <???????????? ERR("Can't find a suitable iPixelFormat\n"); <???????????? return FALSE; <???????? } <???? } --- >???????? if (!iPixelFormat) >?????????? { >??????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ >??????????? ERR("Can't find a suitable iPixelFormat\n"); >??????????? return FALSE; >?????????? } >?????? } 247c245 <???? TRACE("Found iPixelFormat=%d for ColorFormat=%s, DepthStencilFormat=%s\n", iPixelFormat, debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat)); --- >???? TRACE("Found iPixelFormat\n"); 374a373 >???????????? TRACE("Choose Pixel Format Failed\n"); Chris

4 3

Re: netapi32: Set the buffer to NULL in NetApiBufferFree
by Juan Lang June 26, 2008

June 26, 2008

Kai Blin wrote: > This fixes a Valgrind warning triggered by the NetApiBufferFree() test > where a buffer is free()d twice. @@ -52,6 +52,7 @@ NET_API_STATUS WINAPI NetApiBufferFree(LPVOID Buffer) { TRACE("(%p)\n", Buffer); HeapFree(GetProcessHeap(), 0, Buffer); + Buffer = NULL; return NERR_Success; } I don't get it. How does setting a local variable to NULL avoid a warning about freeing it twice? I'm not saying the patch is wrong, I'm just saying I don't get how Valgrind is tricked by this. --Juan

4 8

Re: [2/2] ntdll: rtlstr.c: Implement checking for control characters in RtlIsTextUnicode [try 7]
by Zac Brown June 26, 2008

June 26, 2008

Zac Brown wrote: > Add checking for control characters in both standard and byte-reversed > forms to (Rtl)IsTextUnicode. > > Changelog: > * Add if-statement to ensure we only found control characters in the > first 256 indices. If we found them beyond that, we don't care since > Windows doesn't either. > > > > ------------------------------------------------------------------------ > > --- > dlls/ntdll/rtlstr.c | 23 +++++++++++++++++++++++ > dlls/ntdll/tests/rtlstr.c | 21 +++++---------------- > 2 files changed, 28 insertions(+), 16 deletions(-) > > diff --git a/dlls/ntdll/rtlstr.c b/dlls/ntdll/rtlstr.c > index deec931..802782f 100644 > --- a/dlls/ntdll/rtlstr.c > +++ b/dlls/ntdll/rtlstr.c > @@ -1591,7 +1591,10 @@ NTSTATUS WINAPI RtlFindCharInUnicodeString( > */ > BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > { > + static const WCHAR std_control_chars[] = {'\r','\n','\t',' ',0x3000,0}; > + static const WCHAR byterev_control_chars[] = {0x0d00,0x0a00,0x0900,0x2000,0x0030,0}; > const WCHAR *s = buf; > + WCHAR *tmp_ptr; > int i; > unsigned int flags = ~0U, out_flags = 0; > > @@ -1650,6 +1653,26 @@ BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > } > } > > + /* These two tests are not mutually exclusive so regardless of whether */ > + /* the string has the BOM for byte-reversed order, it still checks */ > + /* the string if the flag is set. */ > + > + /* Check for standard Unicode control characters. */ > + if (flags & IS_TEXT_UNICODE_CONTROLS) > + { > + tmp_ptr = strpbrkW(s, std_control_chars); > + if (tmp_ptr != NULL && (tmp_ptr - s) < len) > + out_flags |= IS_TEXT_UNICODE_CONTROLS; > + } > + > + /* Check for byte-reversed Unicode control characters. */ > + if (flags & IS_TEXT_UNICODE_REVERSE_CONTROLS && strpbrkW(s, byterev_control_chars) != NULL) > + { > + tmp_ptr = strpbrkW(s, byterev_control_chars); > + if (tmp_ptr != NULL && (tmp_ptr - s) < len) > + out_flags |= IS_TEXT_UNICODE_REVERSE_CONTROLS; > + } > + > if (pf) > { > out_flags &= *pf; > diff --git a/dlls/ntdll/tests/rtlstr.c b/dlls/ntdll/tests/rtlstr.c > index 74ba8ea..d5d8839 100644 > --- a/dlls/ntdll/tests/rtlstr.c > +++ b/dlls/ntdll/tests/rtlstr.c > @@ -1693,7 +1693,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_UNICODE_MASK; > ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Text should not pass a Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_STATISTICS | IS_TEXT_UNICODE_CONTROLS), > "Expected flags 0x6, obtained %x\n", flags); > > @@ -1712,7 +1711,7 @@ static void test_RtlIsTextUnicode(void) > be_unicode[i + 1] = (unicode[i] >> 8) | ((unicode[i] & 0xff) << 8); > } > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, NULL), "Reverse endian should not be Unicode\n"); > - todo_wine ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), NULL), "Reverse endian should not be Unicode\n"); > + ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), NULL), "Reverse endian should not be Unicode\n"); > > flags = IS_TEXT_UNICODE_REVERSE_MASK; > ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), &flags), "Reverse endian should be Unicode\n"); > @@ -1722,7 +1721,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_REVERSE_MASK; > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, &flags), "Reverse endian should be Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_REVERSE_CONTROLS | IS_TEXT_UNICODE_REVERSE_SIGNATURE), > "Expected flags 0xc0, obtained %x\n", flags); > > @@ -1750,11 +1748,8 @@ static void test_RtlIsTextUnicode(void) > ok(flags == 0, "Expected flags 0x0, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > - todo_wine > - { > - ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Test should pass on Unicode string lacking control characters.\n"); > - ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > - } > + ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Test should pass on Unicode string lacking control characters.\n"); > + ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > ok(!pRtlIsTextUnicode(be_unicode_no_controls, sizeof(unicode_no_controls) + 2, &flags), > @@ -1762,11 +1757,8 @@ static void test_RtlIsTextUnicode(void) > ok(flags == 0, "Expected flags 0x0, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > - todo_wine > - { > - ok(pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing control characters.\n"); > - ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > - } > + ok(pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing control characters.\n"); > + ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > > /* Test IS_TEXT_UNICODE_REVERSE_CONTROLS flag */ > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > @@ -1784,18 +1776,15 @@ static void test_RtlIsTextUnicode(void) > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, &flags), > "Test should pass with byte-reversed Unicode string containing control characters.\n"); > - todo_wine > ok(flags == IS_TEXT_UNICODE_REVERSE_CONTROLS, "Expected flags 0x40, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing byte-reversed control characters.\n"); > - todo_wine > ok(flags == IS_TEXT_UNICODE_REVERSE_CONTROLS, "Expected flags 0x40, obtained %x\n", flags); > > /* Test with flags for both byte-reverse and standard Unicode characters */ > flags = IS_TEXT_UNICODE_CONTROLS | IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on string containing both byte-reversed and standard control characters.\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_CONTROLS | IS_TEXT_UNICODE_REVERSE_CONTROLS), "Expected flags 0x44, obtained %x\n", flags); > > HeapFree(GetProcessHeap(), 0, be_unicode); > > > ------------------------------------------------------------------------ > > Ignore this patch please.

1 0

AppDB patches
by Francois Gouget June 26, 2008

June 26, 2008

I see that these patches have not yet been applied to the AppDB. Is there anything wrong with them? * [AppDB] Assorted spelling fixes. http://www.winehq.org/pipermail/wine-patches/2008-June/056192.html * [AppDB] application_queue: Fix update(). http://www.winehq.org/pipermail/wine-patches/2008-June/056193.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

2 1

context.c
by celticht32＠aol.com June 26, 2008

June 26, 2008

Has anyone looked at the changes put on the list for context.c? Just had not heard anything.. I assume it is because I am new and all but still...just trying to help per the request on the wine site =) chris

3 2

valgrind regression in gdiplus
by Dan Kegel June 26, 2008

June 26, 2008

Yesterday, there were a bunch of new valgrind warnings in gdiplus, and they're still there today. See http://kegel.com/wine/valgrind/logs-2008-06-26/vg-gdiplus_font.txt For instance, Invalid read of size 4 at GdipCreateFont (font.c:99) by test_createfont (font.c:57) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Address 0x4 is not stack'd, malloc'd or (recently) free'd ... Conditional jump or move depends on uninitialised value(s) at winetest_vok (test.h:272) by winetest_ok (test.h:301) by test_createfont (font.c:61) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Uninitialised value was created by a stack allocation at test_createfont (font.c:43) ... Syscall param write(buf) points to uninitialised byte(s) at (within /lib/ld-2.7.so) by (within /lib/tls/i686/cmov/libc-2.7.so) by _IO_file_xsputn (in /lib/tls/i686/cmov/libc-2.7.so) by (within /lib/tls/i686/cmov/libc-2.7.so) by vfprintf (in /lib/tls/i686/cmov/libc-2.7.so) by winetest_vok (test.h:279) by winetest_ok (test.h:301) by test_createfont (font.c:65) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Address 0x7f21d657 is on thread 1's stack Uninitialised value was created by a stack allocation at test_createfont (font.c:43)

1 0

opengl32: work around a crash in glGetString
by Louis. Lenders June 26, 2008

June 26, 2008

>As I mentioned before this requires a test case. As i tried to explain , in a simple test glGetString just return null, it will not crash for me, like it does in the program. >I remember from the gl log that the program didn't create a WGL context at all. It isn't allowed >to make opengl calls because of that Allowed or not, the program does so, and on windows it installs just fine. >Perhaps without a context (if Windows allows it) you get some GDI software renderer string >back or so. It just returns (null) >Anyway at this point it sounds like a workaround instead of a fix for the real bug. Well, the bug might be outside wine, so then it would be workaround, yes, but still necessary IMO. I cannot see how i can make a testcase based on the output of autocad here: http://bugs.winehq.org/attachment.cgi?id=14005 , other then i did already. It's just an endless sequence of 'wglGetIntegerv','wglFinish', and 'wglFlush', and then a crash in glGetString. I cannot make a test program crash like that; the test program just returns null, like i said before A last stupid question for stefan: how can i make X load the mesa driver, instead of my nvidia? __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

2 1

Whats wrong with my patch.
by Przemysław Białek June 26, 2008

June 26, 2008

Hi! I sent a patch last Friday to the wine-patches list. I think that I fulfill the rules that I read on winehq website. Patch is simple implementation of function GdipDrawEllipse, and is based on existing function GdipFillEllipse. This is my first patch to the Wine project. I don't have deeper Wine, and Windows knowledge, so I ask, what else I must do, to get this patch accepted. The link to the mail is below: http://www.winehq.org/pipermail/wine-patches/2008-June/056223.html -- Best Regards Przemysław Białek

3 3

Re: memory leak fix
by Huw Davies June 26, 2008

June 26, 2008

On Thu, Jun 26, 2008 at 02:05:15AM -0700, Joris Huizer wrote: > Untested, but this seems trivial/obvious, unless I overlooked something > > > > > From 4026f68e4404c4b1822eefe0b3419db4f896e055 Mon Sep 17 00:00:00 2001 > From: Joris Huizer <jorishuizer(a)debian.(none)> > Date: Thu, 26 Jun 2008 11:07:11 +0200 > Subject: [PATCH] memory leak fix > > --- > dlls/gdiplus/font.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 0bb9fc7..9ef8edc 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -378,6 +378,7 @@ GpStatus WINGDIPAPI GdipCreateFontFamilyFromName(GDIPCONST WCHAR *name, > ffamily->FamilyName = GdipAlloc(LF_FACESIZE * sizeof (WCHAR)); > if (!ffamily->FamilyName) > { > + GdipFree(ffamily->tmw); > GdipFree(ffamily); > return OutOfMemory; > } That's a good start, but there's more. The function leaks an hfont both on success and in this failure case. Also there should be a ReleaseDC in the failure case. In addition it seems to me that the tmw element may as well be an embedded structure rather than a structure pointer. That'll save having to worry about alloc'ing/free'ing it. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: Memory leak patch
by Huw Davies June 26, 2008

June 26, 2008

On Thu, Jun 26, 2008 at 03:25:30AM -0700, Joris Huizer wrote: > > > dlls/gdiplus/font.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > >diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c >index 9ef8edc..86122da 100644 >--- a/dlls/gdiplus/font.c >+++ b/dlls/gdiplus/font.c >@@ -42,6 +42,7 @@ static inline REAL get_dpi (void) > HDC hdc = GetDC(0); > GdipCreateFromHDC (hdc, &graphics); > GdipGetDpiX(graphics, &dpi); >+ GdipFree(graphics); > ReleaseDC (0, hdc); > > return dpi; This should be GdipDeleteGraphics. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: quartz Rewrite the avi splitter so that video and sound run in separate threads, with tests
by Alexandre Julliard June 26, 2008

June 26, 2008

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > + FIXME("Waiting for %u to terminate\n", x); > + /* Make the thread return first */ > + SetEvent(stream->packet_queued); > + if (WaitForSingleObject(stream->thread, 10000) == WAIT_TIMEOUT) > + exit(1); Don't use exit(). If you absolutely need to kill the whole process you should use ExitProcess, and you have to print an error so that users know what happened. But I doubt you need such a drastic action here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: opengl32: work around a crash in glGetString
by Roderick Colenbrander June 26, 2008

June 26, 2008

As I mentioned before this requires a test case. I remember from the gl log that the program didn't create a WGL context at all. It isn't allowed to make opengl calls because of that. You should figure out why that is done. Either some other check in the program failed due to which it wasn't able to create a context OR the application is looking for some strange behavior. Perhaps without a context (if Windows allows it) you get some GDI software renderer string back or so. Anyway at this point it sounds like a workaround instead of a fix for the real bug. Roderick > Hi this fixes http://bugs.winehq.org/show_bug.cgi?id=13599 > > A +relay trace shows glGetString is crashing inside glGetString. The cause > is _not_ a lacking opengl context setup around glGetString. I did some > testing and both on windows and wine glGetString just returns NULL if this > is the case, but it never crashes inside glGetString: > > /* glGetString without opengl context: */ > 0009:Call opengl32.glGetString(00001f01) ret=004016bc > 0009:Ret opengl32.glGetString() retval=00000000 ret=004016bc > > /* Crash from Autocad */ > > 0064:Call opengl32.glGetString(00001f01) ret=1000cd58 > 0064:trace:seh:raise_exception code=c0000005 flags=0 addr=0x60ec12f6 > 0064:trace:seh:raise_exception info[0]=00000000 > /* and never returns*/ > > > This bug has been reproduced by several other people , so it's also not > due to a bad gl-setup on my side. In case you want to try , Autocad trial > 2004 can be downloaded from http://www.brothersoft.com/autocad-78351.html. > It's the main issue that prevent autocad 2004 up to 2008 from running. > > So for now my conclusion is, this is a nasty bug outside wine, and an > exception handler is needed to work around the crash. If the patch is rejected > i would appreciate some input. Thanks and regards > > > > __________________________________________________________ > Not happy with your email address?. > Get the one you really want - millions of new email addresses available > now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

RE: opengl32: work around a crash in glGetString
by Stefan Dösinger June 26, 2008

June 26, 2008

Does this crash occur with Mesa as well? If yes, it might be interesting to step through the Mesa code to see what is going wrong in there. Otherwise, drivers are never bug free of course. This could be a bug in the Nvidia driver From: wine-patches-bounces(a)winehq.org [mailto:wine-patches-bounces(a)winehq.org] On Behalf Of Louis. Lenders Sent: Thursday, June 26, 2008 9:06 AM To: wine-patches(a)winehq.org Subject: opengl32: work around a crash in glGetString Hi this fixes http://bugs.winehq.org/show_bug.cgi?id=13599 A +relay trace shows glGetString is crashing inside glGetString. The cause is _not_ a lacking opengl context setup around glGetString. I did some testing and both on windows and wine glGetString just returns NULL if this is the case, but it never crashes inside glGetString: /* glGetString without opengl context: */ 0009:Call opengl32.glGetString(00001f01) ret=004016bc 0009:Ret opengl32.glGetString() retval=00000000 ret=004016bc /* Crash from Autocad */ 0064:Call opengl32.glGetString(00001f01) ret=1000cd58 0064:trace:seh:raise_exception code=c0000005 flags=0 addr=0x60ec12f6 0064:trace:seh:raise_exception info[0]=00000000 /* and never returns*/ This bug has been reproduced by several other people , so it's also not due to a bad gl-setup on my side. In case you want to try , Autocad trial 2004 can be downloaded from http://www.brothersoft.com/autocad-78351.html. It's the main issue that prevent autocad 2004 up to 2008 from running. So for now my conclusion is, this is a nasty bug outside wine, and an exception handler is needed to work around the crash. If the patch is rejected i would appreciate some input. Thanks and regards _____ Not happy with your email address? Get the one you really want <http://uk.docs.yahoo.com/ymail/new.html> - millions of new email addresses available now at Yahoo! <http://uk.docs.yahoo.com/ymail/new.html>

1 0

App non running with +relay enabled
by Massimo June 26, 2008

June 26, 2008

What could be the reason of an app running fine with no relay enabled, but exiting very soon with it enabled ? Best Regards Max

2 1

Re: shell32: iconcache.c: Add stub implementation for SHGetIconOverlayIndex[AW] (RESEND)
by Zac Brown June 26, 2008

June 26, 2008

Zac Brown wrote: > Add stub implementation for SHGetIconOverlayIndex[AW]. > > Mentioned in Bug 7447, though it does not seem to need a full > implementation yet. Since its documented in MSDN, may as well add the > stub implementation of it. > > > ------------------------------------------------------------------------ > > Error in my comments. Scratch it, sending another...

1 0

Re: shell32: iconcache.c: Add stub implementation for SHGetIconOverlayIndex[AW]
by Zac Brown June 26, 2008

June 26, 2008

Zac Brown wrote: > Add stub implementation for SHGetIconOverlayIndex[AW]. > > --Zac > > > ------------------------------------------------------------------------ > > scratch this one.

1 0

"remote" start/stop of relay/snoop output
by max＠veneto.com June 25, 2008

June 25, 2008

I asked that question some years ago, and IIRC then it was not possible, so I resorted to add an external filter app in order to start/stop relays on an already running app. Filter app solved partially the problem : I could get the relay part I needed, but the speed was about the same as dumping the full relay on file. Now (as it was years ago for autocad r14...) I'm trying to trace some calls in autocad2005, but relay log becomes easily 10-20 GB in size, so quite useless. I think the log start/stop feature could be a *very* useful way to isolate needed relay part and to speed up tests. Is it still not possible nor faisible ? Max

3 4

Re: rasapi32: return an error for invalid paramaters
by James Hawkins June 25, 2008

June 25, 2008

On Tue, Jun 24, 2008 at 3:47 PM, Austin English <austinenglish(a)gmail.com> wrote: > Changes like these are so simple that you really should go the extra 5 feet and write simple tests for them. -- James Hawkins

3 4

Re: [1/3] wininet/tests: add InternetErrorDlg tests
by James Hawkins June 25, 2008

June 25, 2008

On Wed, Jun 25, 2008 at 11:00 AM, Alexander Morozov <amorozov(a)etersoft.ru> wrote: > Changelog: > Add InternetErrorDlg tests > > I ran these tests on Win98 and WinXP > > From 687f7d365b97d1da95db222e5bd5bbdf5c62c76f Mon Sep 17 00:00:00 2001 > From: Alexander Morozov <amorozov(a)builder.office.etersoft.ru> > Date: Wed, 25 Jun 2008 19:01:42 +0400 > Subject: [PATCH] wininet/tests: add InternetErrorDlg tests > > --- > dlls/wininet/tests/Makefile.in | 3 +- > dlls/wininet/tests/dialogs.c | 194 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 196 insertions(+), 1 deletions(-) > create mode 100644 dlls/wininet/tests/dialogs.c > > diff --git a/dlls/wininet/tests/Makefile.in b/dlls/wininet/tests/Makefile.in > index ba8f662..92d875b 100644 > --- a/dlls/wininet/tests/Makefile.in > +++ b/dlls/wininet/tests/Makefile.in > @@ -3,9 +3,10 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = wininet.dll > -IMPORTS = wininet ws2_32 kernel32 > +IMPORTS = wininet ws2_32 kernel32 user32 > > CTESTS = \ > + dialogs.c \ > ftp.c \ > generated.c \ > http.c \ > diff --git a/dlls/wininet/tests/dialogs.c b/dlls/wininet/tests/dialogs.c > new file mode 100644 > index 0000000..c2f3878 > --- /dev/null > +++ b/dlls/wininet/tests/dialogs.c > @@ -0,0 +1,194 @@ > +/* > + * Wininet - dialog tests > + * > + * Copyright 2008 Alexander Morozov for Etersoft > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "windows.h" > +#include "wininet.h" > + > +#include "wine/test.h" > + > +static LONG end_thread; > + > +static BOOL CALLBACK enum_wnd_proc(HWND hwnd, LPARAM lparam) > +{ > + SendMessageA(hwnd, WM_CLOSE, 0, 0); > + InterlockedIncrement(&end_thread); > + return TRUE; > +} > + > +static DWORD CALLBACK killer_thread(LPVOID param) > +{ > + /* Without Sleep(50) a window failed to close sometimes */ > + Sleep(50); > + while (!end_thread) > + EnumThreadWindows((DWORD)param, enum_wnd_proc, 0); > + return 0; > +} > + > +static void test_InternetErrorDlg(void) > +{ > + HANDLE hThread; > + HINTERNET hi, hc, hr; > + DWORD ret, id; > + > + hi = InternetOpenA("winetest", 0, NULL, NULL, 0); > + ok(hi != NULL, "InternetOpen failed\n"); > + hc = InternetConnectA(hi, "localhost", INTERNET_DEFAULT_HTTP_PORT, > + NULL, NULL, INTERNET_SERVICE_HTTP, 0, 0); > + ok(hc != NULL, "InternetConnect failed\n"); > + hr = HttpOpenRequestA(hc, "GET", "/", NULL, NULL, NULL, 0, 0); > + ok(hr != NULL, "HttpOpenRequest failed\n"); > + > + ret = InternetErrorDlg(NULL, NULL, ERROR_SUCCESS, 0, NULL); > + todo_wine > + ok(ret == ERROR_INVALID_HANDLE, "InternetErrorDlg failed\n"); > + > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_SUCCESS, 0, NULL); > + todo_wine > + ok(ret == ERROR_NOT_SUPPORTED, "InternetErrorDlg failed\n"); > + > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_FILE_NOT_FOUND, 0, NULL); > + todo_wine > + ok(ret == ERROR_NOT_SUPPORTED, "InternetErrorDlg failed\n"); > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_HTTP_TO_HTTPS_ON_REDIR, 0, NULL); > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_POST_IS_NON_SECURE, 0, NULL); > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED, 0, NULL); > + todo_wine > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_INVALID_CA, 0, NULL); > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_SEC_CERT_CN_INVALID, 0, NULL); > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + end_thread = 0; > + hThread = CreateThread(NULL, 0, killer_thread, > + (LPVOID)GetCurrentThreadId(), 0, &id); > + ok(hThread != NULL, "create thread failed\n"); > + if (NULL != hThread) > + { > + ret = InternetErrorDlg(GetDesktopWindow(), hr, > + ERROR_INTERNET_SEC_CERT_DATE_INVALID, 0, NULL); > + ok(ret == ERROR_CANCELLED || ret == ERROR_SUCCESS, > + "InternetErrorDlg failed\n"); > + InterlockedIncrement(&end_thread); > + ret = WaitForSingleObject(hThread, 3000); > + ok(ret == WAIT_OBJECT_0, "thread wait failed\n"); > + CloseHandle(hThread); > + } > + > + /* This crashes Crashes what? Wine? Windows? If it crashes Windows, the test needs to be if-def'ed out, not commented out. If it crashes on Wine but not Windows, then this patch is wrong. You can't submit a test that crashes in Wine, even if it's commented out. The part that crashes has to be fixed first. -- James Hawkins

1 0

richedit: fix failing EM_GETCHARFORMAT test on all platforms
by Alex Villacís Lasso June 25, 2008

June 25, 2008

Default richedit font (System) in Windows causes native richedit to report CFM_BOLD as always set, regardless of selection, or previous calls to EM_SETCHARFORMAT. Switch to Courier New in order to see that richedit really sets the CFM_BOLD attribute in the correct selection. This fix was successful in removing failure in WinXP-SP2 (real machine) and in Win98 (QEMU virtual machine). However, could you please test on other platforms (win2k, win2k3, Vista) to see whether it removes the failure there too? I want to be extra sure that this test actually passes on all platforms. Changelog: * Fix failing EM_GETCHARFORMAT test on all platforms -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1