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

[FreeBSD] locating wine at 0x20000000
by Tijl Coosemans Aug. 9, 2006

Aug. 9, 2006

Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?

2 7

Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
by Christoph Frick Aug. 9, 2006

Aug. 9, 2006

On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: > This patch fixes those issues by looking at the data types in the > vertex declaration the shader will be used with. To be able to do > that, we have to wait with compiling the shader until the shader is > first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu

1 0

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

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This small patch provides command line option output, a "--help" option > and a default user backend ("--backend=user" is default) to "wineconsole". Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. -- Alexandre Julliard julliard(a)winehq.org

6 14

widl: Error on simple idl file
by Elrond Aug. 9, 2006

Aug. 9, 2006

Hi, The attached idl file gives an error when used with widl -DUSE_TYPEDEF simple.idl I doubt, that it is a syntax error, since adding "-h" creates the header, using "-c" gives the error. The error is: error: Unsupported member type 0x0 Elrond

1 0

Re: ntdll: make shared user data access work
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Robert Reif <reif(a)earthlink.net> writes: > diff -p -u -r1.66 thread.c > --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 -0000 1.66 > +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 -0000 > @@ -215,7 +215,7 @@ HANDLE thread_init(void) > > addr = (void *)0x7ffe0000; > size = 0x10000; > - NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE, PAGE_READONLY ); > + NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. -- Alexandre Julliard julliard(a)winehq.org

2 2

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

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

Aug. 8, 2006

> HolyLich wrote: > > ChangeLog: > > 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. For more information, please, refer to patch. It contains some useful comment. --HolyLich

2 1

Font metrics
by Jeff L Aug. 8, 2006

Aug. 8, 2006

People, I am working on ScriptStringXtoCP etc in usp10. In setting up the tests for this I notice that ABC widths returned ScriptPlace (*/GetCharABCWidthsI) /*is not the same as Windows does. Have tried an couple of fonts and the results are the subtly different. Before I get too carried away with this, are the ABC widths supposed to be the same in Wine and Windows? Jeff Latimer

1 0

dinput & [Get|Set]CursorPos conandrum
by Vitaliy Margolen Aug. 8, 2006

Aug. 8, 2006

Some one few weeks ago mentioned that they needed SetCursorPos to work globally (between processes). Well it seems after all we do need that to fix few lots of things, including most mouse related bugs in dinput. Actually the problem I have is not as much with SetCursorPos as with the fact that with multiple processes only one gets MotionNotify (and other notify) events. This gets cursor position out of sync between two processes and causes interesting side-effects. It's not something major but an annoyance. There are could be more serious problems however. The possible solutions might be: 1. Store cursor_pos in wineserver and call wineserver whenever we need it or need to modify it. Seems straight forward but how expensive it would be? 2. Use shared memory. That means we have to allocate it first (will SharedUserData work for this?). And use mutex for sync. 3. Query X for it's cursor position. Pretty much what we do, except that needs to be fixed: Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X. Any ideas appreciated. Vitaliy

2 4

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

Aug. 8, 2006

HolyLich wrote: > ChangeLog: > 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. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: WineD3D: shader cap fixes
by Roderick Colenbrander Aug. 8, 2006

Aug. 8, 2006

Use this updated patch. I forgot to initialize some constants to zero and made the diff against a wrong file because of which some crucial changes were missed. Roderick > Hi, > > This patch adds most missing shader capabilities. Some capabilitise are > read from OpenGL but not everything is mappable to Direct3D in some cases an > extension from lets say Nvidia can be used but it is not really worth it. > If there's no OpenGL cap the minimum required values as required by the > shader specs are used. > > Regards, > Roderick Colenbrander -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

Constifying Undocumented Code?
by Andrew Talbot Aug. 8, 2006

Aug. 8, 2006

Where we emulate undocumented code, is it acceptable to constify the formal arguments, where appropriate? Thanks, -- Andy.

3 3

HAL and Copy Protection
by Jesse Allen Aug. 8, 2006

Aug. 8, 2006

Does anyone have HAL and SecuRom copy protection working? I'm starting to get support questions with people using HAL and I'm not sure how to help them. I need information now that HAL support is in Wine on whether SecuRom works with it and how to get it to work as I don't have HAL. Jesse

2 6

Re: wined3d: stub out remaining renderstates
by Stefan Dösinger Aug. 7, 2006

Aug. 7, 2006

Am Dienstag 08 August 2006 00:06 schrieb Jan Zerebecki: > If this patch is rejected from inclusion, please tell me why, as i would > have to ask anyway. It looks like you forgot d3d7 render states like TEXTUREMAPBLEND. This state isn't really important for this patch, I will send an implementation for it tomorrow, but other d3d7 render states are perhaps needed.

1 0

Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
by Paul Vriens Aug. 7, 2006

Aug. 7, 2006

On Mon, 2006-08-07 at 11:11 -0700, James Hawkins wrote: > Hi, > > Accoring to recent comments by Paul Vriens, Process Explorer now > accepts ERROR_SUCCESS from WinVerifyTrust, and several installers > require ERROR_SUCCESS in order to continue, so everyone is happy. > Fixes bugs 5573 and 3619. > > http://bugs.winehq.org/show_bug.cgi?id=5573 > http://bugs.winehq.org/show_bug.cgi?id=3619 > > Changelog: > * Always return ERROR_SUCCESS in WinVerifyTrust. > > dlls/wintrust/wintrust_main.c | 18 +++++------------- > 1 files changed, 5 insertions(+), 13 deletions(-) > When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Paul.

2 2

Re: user[2/2]: Preserve LastError.
by Vitaliy Margolen Aug. 7, 2006

Aug. 7, 2006

Saturday, July 29, 2006, 7:28:10 PM, Vitaliy Margolen wrote: > ChangeLog: > user: Preserve LastError. > dlls/user/tests/input.c | 4 ++++ > dlls/winex11.drv/x11drv.h | 3 +++ > 2 files changed, 7 insertions(+), 0 deletions(-) Anything wrong with this patch? Test case clearly shows that we should preserve the LastError. Vitaliy Margolen

2 3