August 2006 - Wine-Devel - list.winehq.org

Re: wineconsole: command line option output / configurable default backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. I don't think that's an improvement, please let's not add more obscure environment variables. You should try to use the user backend when the X display is available and fall back to curses otherwise. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: oleaut32: Add tmarshal conformance test
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This adds a conformance test written by Rob Shearman. Pretty much all the > code in the four files beginning with "tmarshal" is his. All I did was make > some changes to the Makefiles to be able to test things with IDL components, > and I tweaked his stuff in one or two places where needed. For example, I > wrapped the tests that failed in todo_wine blocks, and I commented out a test > that crashes Wine. All the tests pass on Windows (including the one that > crashes Wine). They don't work on Wine here: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok fixme:ole:ITypeInfo_fnRelease destroy child objects err:ole:marshal_object couldn't get IPSFactory buffer for interface {a028db05-30f0-4b93-b17a-41c72f831d84} err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80040155 err:ole:CoMarshalInterface Failed to marshal the interface {a028db05-30f0-4b93-b17a-41c72f831d84}, 80040155 tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x8003001e tmarshal.c:760: Test failed: CoUnmarshalInterface failed with error 0x8003001e wine: Unhandled page fault on write access to 0x00000000 at address 0x15a159 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x0015a159). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:0015a159 ESP:0033fc88 EBP:0033fd58 EFLAGS:00010246( - 00 -RIZP1) EAX:00159310 EBX:7b8abaa8 ECX:00000000 EDX:00000001 ESI:8003001e EDI:60412be7 Stack dump: 0x0033fc88: 00159310 7b88c87f 00159310 00000001 0x0033fc98: 0015a500 0015a158 00159310 0033ff2c 0x0033fca8: 7b82be98 7b8415c0 7b8abaa8 8003001e 0x0033fcb8: 60412be7 0033fd58 0033fc90 7b88c805 0x0033fcc8: 00000001 00000000 00000000 00000020 0x0033fcd8: 0033fd58 7bc2764f 00110000 7bc77848 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000119 Backtrace: =>1 0x0015a159 (0x0015a159) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for oleaut32_test<elf> 2 0x603092f7 func_tmarshal+0x2f7 [/home/julliard/wine/wine/dlls/oleaut32/tests/tmarshal.c:763] in oleaut32_test (0x603092f7) 3 0x6040ee81 run_test+0x121(name=0x1103a9) [/home/julliard/wine/wine/dlls/oleaut32/tests/../../../include/wine/test.h:365] in oleaut32_test (0x6040ee81) 4 0x6040f1a9 __wine_spec_exe_entry+0x99(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in oleaut32_test (0x6040f1a9) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> 5 0x7b87015b start_process+0xeb(arg=0x0) [/home/julliard/wine/wine/dlls/kernel/process.c:822] in kernel32 (0x7b87015b) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 6 0x6001f887 wine_switch_to_stack+0x17 in libwine.so.1 (0x6001f887) 0x0015a159: addb %dl,0x0(%ecx) Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wineconsole: command line option output / configurable default backend
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Wednesday, August 9, 2006, 2:33:17 AM, Ekkehard Morgenstern wrote: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. > If the value isn't set, "curses" will be the default as in the original > code. You patch wrapped again. Please attach it to the e-mail instead. Vitaliy.

2 1

Re: riched20: new selection invalidation logic
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Monday, August 7, 2006, 9:27:16 AM, Krzysztof Foltman wrote: > ChangeLog: > * New, clean, simple selection repaint logic - should fix all > outstanding refresh issues (and bug#5882) > Krzysztof I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Vitaliy Margolen

3 6

Re: msvcrt: In text mode a ctrl-z signals EOF
by Duane Clark Aug. 8, 2006

Aug. 8, 2006

Duane Clark wrote: > Changelog: In text mode a ctrl-z signals EOF > Spotted by David Hagood with test suggested by Dan Kegel > Howdy David. Any chance you could try out this patch? I added a conformance test, as suggested by Dan, and it looks like any data after a ctrl-z is stripped. Of course, it may be that in the real world there will never be anything other than additional ctrl-z characters, in which case your version would be fine (and more efficient). http://www.winehq.org/pipermail/wine-patches/2006-August/029544.html

1 0

Re: libs/wine/config.c: use execve on FreeBSD
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Tijl Coosemans <tijl(a)ulyssis.org> writes: > * use execve on FreeBSD Renaming the msvcrt function would really be better. Particularly since "extern char **environ" doesn't work right on all platforms. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Jeff L <lats(a)yless4u.com.au> writes: > + cMaxItems = 255; /* Pick an abritary size for buffers */ > + analysis = (string_analysis*) pssa; > + if (!*pssa) { /* Clean it out and start again */ > + prtssa(*pssa); > + ScriptStringFree((SCRIPT_STRING_ANALYSIS*)analysis); > + } > + analysis = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(string_analysis)); > + *pssa = (string_analysis*)analysis; I don't follow what you are trying to do here. Why do you print and free a NULL structure? And why do you assign it to analysis and then overwrite it right away with a new allocation? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winhelp: bug fix in LZ77 decompressor - prehistory to make things clear
by HolyLich Aug. 8, 2006

Aug. 8, 2006

>> >> Why? >> >> Er, if the memcpy worked (or almost worked) and failed due to overlap >> problems, then memmove will do the trick. Did it ever work at all before? >> Either this code never worked, or you're either seeing a problem that doesn't >> exist/misunderstanding things. >> >> Cheers, Kuba Um, sorry, I didn't understand question. I try to explain why memcpy worked before. It did not worked. As far as I noticed, this bug does not affect small files (<=0x1000) but if file was large enough (>0x1000 byte) - it will appear. In my case it was multi-colour metafile (jwpce.hlp, http://www.physics.ucla.edu/~grosenth/jwpce.html - lots of metafiles). Small pictures are OK, but large are jammed. What is interesting, the bug affected bitmap part of metafile, so no errors while PlayMetaFile, but the result bitmap was jammed a little. --HolyLich

2 1

Re: riched20: modify ME_CharFromPoint to work properly with password controls
by Phil Krylov Aug. 8, 2006

Aug. 8, 2006

Hi Matt, On 07/08/06, Matt Finnicum <mattfinn(a)gmail.com> wrote: > This patch modifies ME_CharFromPoint to work properly with password > controls (the patch i sent in / got committed a couple days ago). Should not the temp string be freed afterwards? -- Ph.

2 2

Re: winhelp: bug fix in LZ77 decompressor
by HolyLich Aug. 8, 2006

Aug. 8, 2006

On Tue, 8 Aug 2006 09:37:09 -0400, Kuba Ober <kuba(a)mareimbrium.org> wrote: >> > > Fix rather unusual bug in LZ77 decompressor. We cannot use >> > > memcpy >> > > with overlapped areas because of unpredictable result. We must >> > > copy byte-by-byte. > >> > Why don't you use memmove instead? The man page for memcpy says: >> > Use memmove(3) if the memory areas do overlap. > >> We cannot use memmove. It provides different functionality. It moves >> blocks, but LZ77 decompress algorithm copies bytes. >> >> Let's suppose: >> 012 >> XYZ >> >> When we say 'memmove(1, 0, 2)' we will get: >> 012 >> XXY >> >> But we (LZ77 algorithm) expect: >> 012 >> XXX (three 'X'). >> >> memcpy is rather clever (it optmizes process by coping INT instead of >> BYTES). This optimization is fatal for LZ77. > > Why? > > Er, if the memcpy worked (or almost worked) and failed due to overlap > problems, then memmove will do the trick. Did it ever work at all before? > Either this code never worked, or you're either seeing a problem that doesn't > exist/misunderstanding things. > > Cheers, Kuba memmove provides OTHER functionality - it GUARANTEES, that if blocks overlaps, then destination area will the same as source area before. LZ77 decompress algorithms needs copiing byte-by-byte - of course, if areas overlap, then dest area WILL NOT match the src area before. It IS correct for LZ77! The simpliest version of memcpy routine, like this: void my_memcpy(char *dst, char *src, int len) { while (len-->0) *dst++=*src++; ) WILL work correctly for LZ77. memcpy provided by gcc is optimized - it NOT copies byte-by-byte from beginning till end. If you mediate over lz77 decompress algo (dlls/kernel/lzexpand.c) the things will be clean.

1 0