May 2006 - wine-devel

Re: 4979: wine 9.11 make fails on AMD64, more info
by David Anderson 16 May '06

16 May '06

I just installed kubuntu 6.06 on a new laptop (no binary avail), AMD64. Compiling wine failed as 4979 says, no libfreetype.so that is compatible. The problem is not in the -L or in gcc or in wine. The problem is in the m32 libfreetype. /usr/lib32 is searched (as /usr/lib/../lib32) by gcc automatically with -m32. The libfreetype developer(s) provided libfreetype.so.6.3.8 and link libfreetype.so.6 ->libfreetype.so.6.3.8 However they forgot to create the symlink libfreetype.so -> libfreetype.so.6 Create this by hand in /usr/lib32 and regrettably wine still will not build as 4 externs are left unresolved: inflate, inflateReset,inflateEnd, inflateInit2. This appears to also be a libfreetype issue. It's been reported several times in various contexts, google for 'libfreetype inflate' to see them. I don't have a solution, sorry.

2 2

bugzilla report changes
by Saulius Krasuckas 16 May '06

16 May '06

I just have submited an additional attachment on my report page [*]. After this bugzilla said to me: Changes Submitted -- Attachment #2466 to Bug #2082 Created Email sent to: lionel.ulmer(a)free.fr, jave27(a)gmail.com, z77y16(a)hotmail.com, danielv(a)freeshell.org, ivg2(a)cornell.edu, pq(a)iki.fi, chuzzum(a)gmail.com, flerchjj(a)ieee.org Excluding: saulius.krasuckas(a)elst.vtu.lt Well, I don't understand, why this hasn't been sent to wine-bugs(a)winehq.org. Did that happen by a design? [*] http://bugs.winehq.org/show_bug.cgi?id=2082#c23

2 1

Re: [wined3d] Corrected definition for parameters (Coverity)
by Ivan Gyurdiev 16 May '06

16 May '06

Paul Vriens wrote: > Hi, > > don't know anything about wined3d, but the code in > IWineD3DVertexShaderImpl_ExecuteSW could make use of 6 parameters. The > definitions should cover this. > I don't think so... the case for 6 parameters should be removed. I can't find 6-parameter instructions in the ins table. [otherwise this would have to be fixed in a lot of other places as well]. ==== I find the multi-argument calls rather ugly, though I understand they might be necessary for speed. However, I am currently trying to get relative addressing tokens in shaders 2.0+ properly accounted for. We can have up to... 5 extra tokens per instruction for relative addressing. So, either all those multi-arg calls need to switch to unpacking structures, or the number of arguments should be increased up to 10. I think I'll ignore software shaders for now though - not sure how to test them.

2 2

OGL Crash
by Robert Lunnon 16 May '06

16 May '06

I have a problem with OGL , during initialisation I have a segfault occurring in the following code segment, note that I have instrumented the code XVisualInfo *X11DRV_setup_opengl_visual( Display *display ) { XVisualInfo *visual = NULL; /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, */ fprintf(stderr,"setup visual\n"); int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; if (!has_opengl()) return NULL; fprintf(stderr,"Choosing Visual display=%p DefaultScreen=%p dblBuf=%p\n",display, DefaultScreen(display), dblBuf); wine_tsx11_lock(); ************************Crash Occurs in the following line visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf); wine_tsx11_unlock(); fprintf(stderr,"Visual is %d\n",visual); Output is setup visual Choosing Visual display=81ad320 DefaultScreen=0 dblBuf=7fd1ef70 Handling exception at EIP 7f0434b7 accessing 2a0 wine: Unhandled page fault on read access to 0x000002a0 at address 7f0434b7 (thread 0009), starting debugger... Can't attach process 8: error 5 I suspect the problem is DefaultScreen returning 0 Anyone know where this is defined ?

1 0

Re: rpcrt4: Implemented NTLM authentication for rpcrt4 connections.
by Kai Blin 16 May '06

16 May '06

* Mike McCormack <mike(a)codeweavers.com> [15/05/06, 23:04:25]: > + r = AcquireCredentialsHandleA(NULL, "NTLM", SECPKG_CRED_OUTBOUND, NULL, > + AuthIdentity, NULL, NULL, &bind->cred, &bind->exp); Sweet. Glad to see that code in use. :) > + /* tack on a negotiate packet */ > + RPCRT4_AuthNegotiate(Connection, &out); > + r = RPCRT4_SendAuth(Connection, Header, Buffer, BufferLength, out.pvBuffer, out.cbBuffer); > + HeapFree(GetProcessHeap(), 0, out.pvBuffer); Should that actually be a Negotiate packet? If it should, I can add Negotiate to the set of patches I sent Rob. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Your wig steers the gig. -- Lord Buckley

2 2

Re: user32: Add more ShowWindow tests
by Alexandre Julliard 16 May '06

16 May '06

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -3217,7 +3295,7 @@ static void test_showwindow(void) > > trace("calling ShowWindow( SW_SHOWMAXIMIZE ) for invisible popup window\n"); > ShowWindow(hwnd, SW_SHOWMAXIMIZED); > - ok_sequence(WmShowMaxPopupResizedSeq, "ShowWindow(SW_SHOWMAXIMIZED):popup", FALSE); > + ok_sequence(WmShowMaxPopupResizedSeq, "ShowWindow(SW_SHOWMAXIMIZED):popup", TRUE); It would be better to avoid turning working tests back into todos, because it means a lot of things will no longer be properly regression tested, since todo applies to the whole sequence. -- Alexandre Julliard julliard(a)winehq.org

2 3

Help needed: Drawing of transformed vertices
by Stefan Dösinger 16 May '06

16 May '06

Hello, As I have mentioned on irc some time ago, I have some Z order problems in a few d3d7 games. It seems to affect all games which mix transformed and untransformed vertices in one scene. The problem is that the transformed vertices show up in front of the untransformed, although the shouldn't. See http://stud4.tuwien.ac.at/~e0526822/messiah-broken.png, this is a screenshot from the game Messiah, and the symptoms are that the flames and the beams can be seen through boxes, units and other objects. I can remember that a simmilar problem was reported for a d3d8 or d3d9 game. Other affected games are Gothic 2(fire can be seen though walls) and Anarchy Online(water level is too high). With Lionel Ulmer I found the problem in the glOrtho setup that wined3d does in drawprim.c(and in surface.c). The -minZ, -maxZ z range scales the vertices and disturbes the z order. The old ddraw code uses a transform matrix which is equally to passing zmin = 1.0 and zmax = -1.0 to address this issue. Then the z coordinate are passed to gl unchanged and the z order is left intact. But as you undoubtately can guess, this breaks other games such as Prince of Persia 3D. Some investigation showed that the current z setup in wined3d seems to be to avoid clipping. First I thought that rhw vertices aren't supposed to be clipped at all, but opengl does that and it's impossible to deactivate clipping in gl. So the vertices are scaled into the depth range to prevent them from beeing clipped. Lionel Ulmer mentioned a DONOTCLIP flag for d3d7 vertex drawing, which pop3d indeed passes. But we can't avoid clipping and disturbing the z setup at the same time :-( The attached patch moves the glOrtho setup in a shared function for drawprim and unlockrect to avoid having double code. It also changes the default z range to 1.0, -1.0, with a dontclip flag which selects the old setup(but this is disabled for now, it will be activated for the DONOTCLIP flag and if ProcessVertices was supposed to clip the vertices). Can you test the patch on some d3d8 and d3d9 games? I tested it on warcraft 3 and half-life 2 and didn't see any difference. Can you report negative and positive changes? Thanks, Stefan

2 1

SoC idea: fix wine 2398 bug.
by Marcin Kardas 15 May '06

15 May '06

Hi, I'm participate in Google summer of code and I'm going to send application with my own idea. I would like to fix popular wine bug - http://bugs.winehq.org/show_bug.cgi?id=2398. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I've made some test and it should work, but may be it will cause another problems to solve, for example conecting X graphic context with GLContext. Maybe I will have to rewritte wine graphics function to use only OpenGL (or may be I will found another way). What do you think about it? Cheers, Marcin.

8 11

ClipCursor implementation
by Remus 15 May '06

15 May '06

Hello, Please excuse me if i didn't sent this mail to the right mailing list. I want to implement in Linux a function similar with ClipCursor, but without using XGrabPointer(). The first time i tried to process mouse-move events, but it doesn't look good. Second time i tried XGrabPointer(), it works, but an extra window is not wanted in my app. I think this functionality is already implemented in Wine, but i didn't find much about it in the sources, except for setting a rectangle, etc. Do you have any ideas or directions to point to me? Thanks, Remus

1 0

Re: Dinput8: DirectInput8Create rewrite
by Roderick Colenbrander 15 May '06

15 May '06

> On 5/15/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > > > Are you sure it is this patch that causes the regression and not > Vitaly's > > latest one? This patch changes the way dinput8 objects are created and > it > > does this similar to windows. Could you figure out what part breaks it? > > > > Yes, I have tried without Vitaly's. CoCreateInstance is failing: > > err:ole:CoCreateInstance apartment not initialised > err:dinput:DirectInput8Create CoCreateInstance failed with hr = > -2147221008 > err:ole:CoGetClassObject class {ef985e71-d5c7-42d4-ba4d-2d073e2e96f4} > not registered > err:ole:CoGetClassObject class {ef985e71-d5c7-42d4-ba4d-2d073e2e96f4} > not registered > err:ole:CoGetClassObject no class object > {ef985e71-d5c7-42d4-ba4d-2d073e2e96f4} could be created for context > 0x3 > > Is this because I am missing registry entries? > > Jesse > Yes, that's the reason. I forgot that I still need to send the patch for the registry settings. Basicly what you need to add is this: REGEDIT4 [HKEY_CLASSES_ROOT\CLSID\{25E609E4-B259-11CF-BFC7-444553540000}] @="Microsoft DirectInput8" [HKEY_CLASSES_ROOT\CLSID\{25E609E4-B259-11CF-BFC7-444553540000}\InProcServer32] @="C:\\windows\\system32\\dinput8.dll" "ThreadingModel"="Both" -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

1 0

Re: riched20: Implement EM_SETUNDOLIMIT and its conformance tests, take 4
by Dimi Paun 15 May '06

15 May '06

On Mon, May 15, 2006 1:22 pm, Matt Finnicum wrote: > Hopefully, i've managed to do this one right. It is, but why not use STACK_SIZE_DEFAULT here as well: + ed->nUndoLimit = 100; /* 100 is the proper default */ -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Starred Chats Sent Mail Drafts (2) All Mail Spam (2510) Trash Contacts Labels battlezone class 05-06 facebook mfinnic2@uiuc.edu myself Summer of Code wine-appdb (16) wine-bugs wine-devel (10) wine-patches (384) wtf-trafton Edit labels Invite a friend
by Dimi Paun 15 May '06

15 May '06

On Mon, May 15, 2006 11:28 am, Matt Finnicum wrote: > Hello! > > Patch updated w/ Dimi Paun's advice (using #define's for the default > and max values), and slightly cleaned up. Well, not quite (maybe you've sent the wrong patch): + case EM_SETUNDOLIMIT: + { + if ((int)wParam < 0) + editor->nUndoLimit = 100; + else if ((int)wParam > 10000) + /* This should be high enough. it keeps wine from getting killed + from hogging memory. Windows allocates all this memory at once, so + no program would realisticly set a value this high */ + editor->nUndoLimit = 10000; + else + editor->nUndoLimit = wParam; + -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Starred Chats ... blah blah blah
by Matt Finnicum 15 May '06

15 May '06

This was *supposed* to have been titled: "riched20: Implement EM_SETUNDOLIMIT and its conformance tests, take 3" Sorry! --Matt On 5/15/06, Matt Finnicum <mattfinn(a)gmail.com> wrote: > Hello! > > Patch updated w/ Dimi Paun's advice (using #define's for the default > and max values), and slightly cleaned up. > > Thanks, > --Matthew Finnicum > > Changelog: > riched20: Implemented conformance tests for EM_SETUNDOLIMIT() > riched20: Implemented EM_SETUNDOLIMIT() > > editor.c | 21 +++++++++++++++--- > editstr.h | 4 ++- > tests/editor.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > undo.c | 27 ++++++++++++++++++++++- > 4 files changed, 112 insertions(+), 5 deletions(-) > > >

1 0

Re: dnsapi: Switch from libresolv to libbind for DNS support.
by Marcus Meissner 15 May '06

15 May '06

On Sat, May 13, 2006 at 05:10:55PM +0200, Hans Leidekker wrote: > > This patch presents an alternative to the one I sent a while ago > that adds two source files from libbind. The advantage of this > alternative is that it brings DNS message parsing support and DNS > update support, without adding files from external projects. > > The drawback is that libbind appears to be packaged only as a static > library on Debian based systems, whereas libresolv is available as a > shared library on virtually every system. libbind.a is 428694 bytes > in size on my Kubuntu system and 546908 bytes in size on my Fedora > system. > > -Hans > > Changelog > Switch from libresolv to libbind for DNS support. The disadvantage is that bind-libs is under a BSD 4 clause license. While it is allowed to link it, it will also make dnsapi and likely WINE itself fall under the BSD 4 clause license (additionaly to LGPL) and both need to be honored from this point on. BSD 4 clause is only used in parts of the lib, other parts are under regular BSD license or others. grep -r "All advertising materials" <dir> to find all files with BSD clause 4 license. I think the DNS parsing code itself in libbind is under normal BSD license and the pieces necessary could be copied/imported safely into LGPL code. (This is likely the reason Debian packs it statically.) Ciao, Marcus

2 1

Re: Dinput8: DirectInput8Create rewrite
by Jesse Allen 15 May '06

15 May '06

On 5/14/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This patch lets DirectInput8Create work similar to the native version which > according to MSDN uses CoCreateInstance to create a dinput8 object. This > rewrite should fix the dll count related issues. > This patch needs linking against ole32 and it breaks keyboard and mouse input in Star Wars Battlefront for some reason. Hmmm... Jesse

1 0

Moving menus to wineserver
by Dan Kegel 15 May '06

15 May '06

wineserver currently tracks a lot of info about windows (those things on the screen, not the operating system). It turns out (see http://bugs.winehq.org/show_bug.cgi?id=5231 ) that it probably needs to do the same thing for menus and menuitems to make the win32 apis GetMenuItemCount and GetMenuItemInfo work for menus of other processes. (Why would you need that, you say? To support gui test scripting languages, e.g. Perl's win32::GuiTest; see http://kegel.com/wine/testsw.html I have a feeling that big companies won't take Wine seriously until they can run their apps' regression tests on Wine. So this is, if not urgent, at least pretty desirable.) This seems to be part of Dimi Paun's TODO list. Dimi, were you about to do this? If not, am I on the right track here? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

Still missing glyph
by Uwe Bonnes 14 May '06

14 May '06

Hallo, even with a recent fontforge, I get "Missing glyph for": fontforge -script ../fonts/genttf.ff small_fonts.sfd small_fonts.ttf Copyright (c) 2000-2006 by George Williams. Executable based on sources from 19:18 13-Apr-2006. ../tools/widl/widl -I. -I. -I../include -I../include -h -H amstream.h amstream.idl LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt system.ttf 16 932 96 128 7 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1252 96 128 5 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1250 96 128 5 LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt small_fonts.ttf 11 1253 96 128 5 Missing glyph for char 0385 Missing glyph for char 0386 ... Is this expected behaviour? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Valgrind warning cleanup...
by Dan Kegel 14 May '06

14 May '06

I was trying to use valgrind-3.1.1 to track down an OpenOffice crash, and I noticed that current wine shows errors like this even running notepad: ==8986== Invalid read of size 4 ==8986== at 0x20010C21: (within /lib/ld-2.3.6.so) ... ==8986== by 0x20189D10: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==8986== by 0x20023CB8: wine_dlopen (loader.c:663) ==8986== by 0x200248B7: wine_init (loader.c:625) ==8986== by 0x7BF00F9F: main (main.c:58) ==8986== Address 0x2018D3A8 is 56 bytes inside a block of size 57 alloc'd ==8986== at 0x2001C422: malloc (vg_replace_malloc.c:149) ==8986== by 0x2002463A: first_dll_path (loader.c:201) ==8986== by 0x20024895: wine_init (loader.c:623) ==8986== by 0x7BF00F9F: main (main.c:58) I looked at first_dll_path, but I couldn't see any problem. On the theory that glibc is reading a bit past the end of the string, I tried changing the line that does the allocation in question. Adding one byte cut down the number of those warnings; adding two bytes didn't help more than adding one; adding three bytes got rid of the warnings. Here's the change: --- libs/wine/loader.c 17 Mar 2006 12:23:52 -0000 1.36 +++ libs/wine/loader.c 13 May 2006 19:56:52 -0000 @@ -199,7 +199,7 @@ char *p; int namelen = strlen( name ); - context->buffer = malloc( dll_path_maxlen + 2 * namelen + strlen(ext) + 3 ); + context->buffer = malloc( dll_path_maxlen + 2 * namelen + strlen(ext) + 6 ); context->index = build_dir ? 0 : 3; /* if no build dir skip all the build dir magic cases */ context->name = context->buffer + dll_path_maxlen + namelen + 1; context->namelen = namelen + 1; What do folks think - should we just make the allocation a little bigger to make valgrind happy? I'd also like to understand what's causing them, too, though. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 5

Re: widl: Added an option to set importlib search path.
by Detlef Riekenberg 14 May '06

14 May '06

Hi Jacek: +" -L path Set importlib searcg dir to path (multiple -L Small typo in tools/widl/widl.c: "search" -- By By ... ... Detlef

1 0

Re: gdi: Add WineGL driver interface and wrapper functions
by Tomas Carnecky 14 May '06

14 May '06

... and here the patch

1 0

Re: Quiet valgrind warnings in init_current_teb
by Mike Hearn 14 May '06

14 May '06

Hmm, are you sure this isn't a bug in Valgrind itself? The code it's warning on is this: inline static void wine_ldt_set_limit( LDT_ENTRY *ent, unsigned int limit ) { if ((ent->HighWord.Bits.Granularity = (limit >= 0x100000))) limit >>= 12; ent->LimitLow = (WORD)limit; ent->HighWord.Bits.LimitHi = (limit >> 16); } but unless I'm reading it wrong this is not testing ent before initialization at all, it's testing limit, assigning to ent, then testing the result of that assignment ... which seems to be valid. Of course, working around bugs in Valgrind may be a useful thing to do for now ... that code is seriously terrifying stuff. And I thought Wine was scary :) thanks -mike

4 4

possible MCI deadlock
by Damjan Jovanovic 14 May '06

14 May '06

I've been looking at bug 3930 (http://bugs.winehq.org/show_bug.cgi?id=3930), where Heroes of might and magic basically hangs on a black screen when sound is enabled (and works when sound is disabled). It happens on all wine versions, the winedbg session below is from wine 0.9.11 and was done during the black screen. Any ideas? What's exception c0000005? Wine-dbg>info process pid threads parent executable (all id:s are in hex) 0000000a 1 00000008 'c:\windows\system32\explorer.exe' 00000008 2 00000000 'C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE' Wine-dbg>attach 8 0xffffe410: popl %ebp Wine-dbg>bt all Backtracing for thread 0xc in process 0x8 (C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE): Backtrace: =>1 0xffffe410 (0xffffe410) 2 0x7eced300 wodPlayer+0xc0(pmt=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winmm/winealsa/audio.c:2261] in winealsa (0x7eced300) 3 0x7fc75dc9 THREAD_Start+0x119(ptr=0x7fd4a3e0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/thread.c:76] in kernel32 (0x7fc75dc9) 4 0x7ffbba86 start_thread+0x236(info=0x7fd4a3f8) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/thread.c:357] in ntdll (0x7ffbba86) 5 0xb7ec7380 (0xb7ec7380) 6 0xb7e60c6e __clone+0x5e in libc.so.6 (0xb7e60c6e) Process of pid=0x00000008 has terminated 0xffffe40e: jmp 0xffffe403 Backtracing for thread 0xb in process 0xa (c:\windows\system32\explorer.exe): Backtrace: =>1 0xffffe40e (0xffffe40e) 2 0x7ffb7d52 NTDLL_wait_for_multiple_objects+0x252(count=0x2, handles=0x7fbbf4b0, flags=0x4, timeout=0x0, signal_object=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/sync.c:729] in ntdll (0x7ffb7d52) 3 0x7ffb7e57 NtWaitForMultipleObjects+0x67(count=0x2, handles=0x7fbbf4b0, wait_all=0x0, alertable=0x0, timeout=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/ntdll/sync.c:760] in ntdll (0x7ffb7e57) 4 0x7fc5d84e WaitForMultipleObjectsEx+0xae(count=0x2, handles=0x7fbbf600, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/sync.c:213] in kernel32 (0x7fc5d84e) 5 0x7f774eac X11DRV_MsgWaitForMultipleObjectsEx+0xfc(count=0x1, handles=0x7fbbf768, timeout=0xffffffff, mask=0x4ff, flags=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/x11drv/event.c:312] in winex11 (0x7f774eac) 6 0x7fa10dc1 GetMessageW+0x211(msg=0x7fbbf8f0, hwnd=0x0, first=0x0, last=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/user/message.c:2836] in user32 (0x7fa10dc1) 7 0x7fbd57f5 manage_desktop+0x255(arg=0x7fcf075d) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/programs/explorer/desktop.c:190] in explorer (0x7fbd57f5) 8 0x7fbd5e38 WinMain+0x268(hinstance=0x7fbd0000, previnstance=0x0, cmdline=0x7fcf0755, cmdshow=0x1) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/programs/explorer/explorer.c:139] in explorer (0x7fbd5e38) 9 0x7fbd71a7 main+0xd7(argc=0x2, argv=0x7fcf0450) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winecrt0/exe_main.c:48] in explorer (0x7fbd71a7) 10 0x7fbd70b9 __wine_spec_exe_entry+0x99(peb=0x7ffdf2c0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/winecrt0/exe_entry.c:37] in explorer (0x7fbd70b9) 11 0x7fc4a0ae start_process+0xee(arg=0x0) [/home/dacha/Programs/InstallationFiles/wine-0.9.11/dlls/kernel/process.c:845] in kernel32 (0x7fc4a0ae) 12 0xb7ef5587 wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ef5587) Process of pid=0x0000000a has terminated 0xffffe410: popl %ebp Backtracing for thread 0x9 in process 0x8 (C:\Program Files\3DO\Heroes of Might and Magic\HEROES.EXE): Backtrace: Exception c0000005 Wine-dbg> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: comctl32[1/8]: header: don't check lpItem for NULL in GetItemT
by Vitaliy Margolen 14 May '06

14 May '06

Saturday, May 13, 2006, 1:07:54 PM, Mikolaj Zalewski wrote: > These patches implements the callback header items and should fix e.g. > bug #4344 > Changelog: don't check lpItem for NULL in GetItemT - lpItem can't be NULL You will need to split this patch into two. Checking for NULL has nothing to do with callback. Also I'm not sure why are you removing NULL check? Any explanations, tests? Vitaliy Margolen

2 1

Google Earth installer
by Robert Lunnon 14 May '06

14 May '06

I have an issue with Google Earth Installer generating an exception early in the install. Looks like it has a problem dereferencing a pointer returned by LoadResource. Anyone looking into this at all ? 1 000c:Call window proc 405fa1 (hwnd=10024,msg=WM_INITDIALOG,wp=00000000,lp=7fd5fa98) 2 000c:Call user32.SetTimer(00010024,000003e9,0000012c,00000000) ret=004060e7 2 000c:Ret user32.SetTimer() retval=000003e9 ret=004060e7 2 000c:Call kernel32.GetLastError() ret=00401c6c 1 000c:Ret kernel32.GetLastError() retval=00000000 ret=00401c6c 2 000c:Call ntdll.RtlAllocateHeap(7ef50000,00000000,00000001) ret=0040ceb8 1 000c:Ret ntdll.RtlAllocateHeap() retval=7ef50148 ret=0040ceb8 2 000c:Call kernel32.SetLastError(00000000) ret=00401c98 1 000c:Ret kernel32.SetLastError() retval=00000000 ret=00401c98 2 000c:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000009) ret=0040a03e 3 000c:Call ntdll.LdrFindResource_U(00400000,7ef3cc80,00000003,7ef3cc7c) ret=7fded3782 2 000c:Ret ntdll.LdrFindResource_U() retval=c0000204 ret=7fded378 3 000c:Call ntdll.RtlNtStatusToDosError(c0000204) ret=7fded38c 2 000c:Ret ntdll.RtlNtStatusToDosError() retval=00000717 ret=7fded38c 1 000c:Ret kernel32.FindResourceExA() retval=00000000 ret=0040a03e 2 000c:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000409) ret=0040a055 3 000c:Call ntdll.LdrFindResource_U(00400000,7ef3cc80,00000003,7ef3cc7c) ret=7fded378 2 000c:Ret ntdll.LdrFindResource_U() retval=00000000 ret=7fded378 1 000c:Ret kernel32.FindResourceExA() retval=00416440 ret=0040a055 2 000c:Call kernel32.LoadResource(00400000,00416440) ret=0040a071 3 000c:Call ntdll.LdrAccessResource(00400000,00416440,7ef3ccec,00000000) ret=7fdee7a6 2 000c:Ret ntdll.LdrAccessResource() retval=00000000 ret=7fdee7a6 1 000c:Ret kernel32.LoadResource() retval=0041a8f4 ret=0040a071 Handling exception at EIP 40a0aa accessing 41a936 000c:Call ntdll.RtlEnterCriticalSection(7f36b2e0) ret=7f312065 000c:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f312065 000c:Call ntdll.RtlLeaveCriticalSection(7f36b2e0) ret=7f3120c3 000c:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f3120c3 000c:Call ntdll.NtCurrentTeb() ret=7fdb17cd 000c:Ret ntdll.NtCurrentTeb() retval=7ef40000 ret=7fdb17cd 000c:Call ntdll.NtCreateEvent(7ef3c820,001f0003,7ef3c824,00000001,00000000) ret=7fdb168a 000c:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fdb168a wine: Unhandled page fault on read access to 0x0041a936 at address 40a0aa (thread 000c), starting debugger...

1 0

Re: comctl32[2/8]: header: don't send HDN_GETDISPINFO during HDM_SET/INSERTITEM
by James Hawkins 13 May '06

13 May '06

On 5/13/06, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > Changelog: don't send HDN_GETDISPINFO during HDM_SET/INSERTITEM - > Windows doesn't do it. > This is a good candidate for a test case. -- James Hawkins

1 0

Re: gdi: create driver interface for opengl implementation and add wrapper functions.
by Tomas Carnecky 13 May '06

13 May '06

Tomas Carnecky wrote: > This patch adds an WineGL interface to the GDI driver and creates > wrapper functions for them. If the wgl function takes a HDC, the wrapper > extract the PHYSDEV and prepends it to the driver-function argument > list. This way we have direct access to the PHYSDEV in x11drv and don't > need to use ExtEscape(). I've run into some problems with this. opengl32.dll exports only the basic wgl functions, if an application wants to use functions which are provided by various extensions, it has to use wglGetProcAddress(). I moved all extensions to x11drv and wglGetProcAddress() returns the pointer to those functions. The problem is that those functions are called directly by the application and not through the wrapper and thus don't have access to PHYSDEV like the basic wgl functions. We could make wrapper functions for each extension, but that would require changing the driver function table every time we add a new extension. I took another path and added a new GDI function 'wineGetDCPrivate(HDC)' that returns the PHYSDEV for the given DC. This way I can have all function prototypes the same for wgl?? in opengl32, WineGLWrapper_wgl?? in GDI and the WineGL_wgl?? implementation in x11drv. In the implementation in x11drv I get the PHYSDEV when required using the new GDI function and have direct access to it, no need to use ExtEscape(). In addition to the basic wgl?? functions the GDI driver has to expose two gl?? functions, glGetString() (for GL_EXTENSIONS to be able to report all supported WGL extensions) and glGetIntegerv() (because GL_DEPTH_BITS and GL_ALPHA_BITS don't have the same meaning on windows and X11). Also, once the x11drv side is stable, opengl32.spec can be changed like this: @ stdcall wglGetCurrentDC() gdi32.WineGLWrapper_wglGetCurrentDC And all but three functions can be deleted from wgl.c (and wgl_ext.c) can be removed completely). Those three functions are: o wglGetProcAddress(): first scan OpenGL functions, if not found fall back to WineGLWrapper_wglGetProcAddress() to let x11drv return the pointer to the wgl function. o glGetString: use glGetString and WineGLWrapper_glGetString() to build the extension string. o glGetIntegerv(): let x11drv return the proper values if the app is requesting GL_DEPTH_BITS or GL_ALPHA_BITS. tom

1 0

Re: [Wine] Wine + serial port basically hangs system
by Uwe Bonnes 13 May '06

13 May '06

Hallo, this is a thread from wine-users. I think further discussion of this issue is better done on wine-devel. In short, Dan Armbrust notices some application (heavy weather.exe) accessing the serial port causing a high system load. As the application uses WaitCommEvent, I fear that my implementation of WaitCommEvent is inappropriate. In my last posting, I ask Dan to count the calls to WaitcommEvent by counting the number of lines containing WaitCommEvent in a relay log. His results are: >>>>> "Dan" == Dan Armbrust <daniel.armbrust.list(a)gmail.com> writes: Dan> I let the app run for about 2 minutes, at the standard priority - Dan> basically until the system was about ready to take a dive :) Dan> Data was coming in to the program and being displayed before I Dan> killed it. Dan> The count on WaitCommEvent was 15051 - so I guess we would have Dan> 7526 calls to WaitCommEvent in < 2 minutes. It probably took the Dan> first 30 seconds just to get the app up and running, so that was Dan> maybe 90 seconds of actually accessing the serial port. As Dan's machine is not a "big iron one", I guess these about 7500 thread creation/termination in about 90 seconds could explain the high system load. In the moment, my implementation of WaitCommEvent creates a thread in the context of the running program for every call. Any ideas how to do it better? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 6

Re: rpcrt4: Fix some conditional includes
by Huw Davies 12 May '06

12 May '06

> -#ifdef HAVE_SYS_TYPES > #include <sys/types.h> > -#endif There is a HAVE_SYS_TYPES_H though. However since HAVE_SYS_TYPES isn't defined, couldn't you remove the #include too? Huw. -- Huw Davies huw(a)codeweavers.com

3 4

AW: thanks for wine
by Roland Kaeser 12 May '06

12 May '06

Hello I started CorelDraw with the given WINEDEBUG options but there is no chance to get success with this options. It took me more than 2 hours just to start Corel and generated about 1.5GB of log output. Even moving the mouse generated more than 5000 lines of debug output. So I removed the +relay option. And here is the generated debug output which is already a lot of text. (See the attachement). I hope this is enough information to find where there bug exactly comes. Many thanks for the efforts. Roland Kaeser >----- Ursprüngliche Mail ---- >Von: Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> >An: Roland Kaeser <roli8200(a)yahoo.de> >CC: wine-devel(a)winehq.org >Gesendet: Freitag, den 12. Mai 2006, 14:18:00 Uhr >Betreff: Re: thanks for wine >On Fri, May 12, 2006 at 06:20:13AM +0000, Roland Kaeser wrote: >> >The only major issues that I'm aware of are coping and pasting OLE embedded >> >objects. That should be taken care of when Rob is finished his COM work. >> >> >IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused >> >by problems translating from windows data formats to linux data formats and >> >vice versa. >> >> As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. >> BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason. >> >> I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application? >> On the other side I saw a lot of applications by which the copy/paste does not work. It seems to be a much bigger issue than assumed. >> >I agree, they are different bugs. I don't have Corel Draw 9 so if you can >send me a +relay,+clipboard,+tid trace I can take a look. >/Ulrich

1 0

AppDB
by Mike Hearn 12 May '06

12 May '06

I'm sure this was raised before, but why does the AppDB show comments from oldest to newest, not newest to oldest? This ordering makes no sense to me. thanks -mike

2 3

freedos - dossystem under gpl - for Wine and vdm - fully compatiebel - LFM and all what we need
by blackcrack 12 May '06

12 May '06

Hy Peoples, a idea again... why not use FreeDos in Wine... as dos for older programms... : http://en.wikipedia.org/wiki/FreeDOS regards Blacky

4 3

thanks for wine
by Marius Andreiana 12 May '06

12 May '06

Thank you wine developers for allowing me to play the Da Vinci Quest with Firefox and required Flash 8 plugin, not available for Linux. Copy-paste didn't work between wine and Gnome, but everything else was without a hitch! -- Marius Andreiana http://marius.andreiana.googlepages.com

2 2

Cursor questions
by Stefan Dösinger 12 May '06

12 May '06

Hi, I noticed that wine always uses it's own mouse cursor image looking like the standard windows cursor. Is there a reason why the X server mouse cursor isn't used? It's only a minor cosmetic issue, but i have wondered what the reason for this is and if it can be fixed. Cheers, Stefan

4 3

help
by Marco Ortega 12 May '06

12 May '06

1 0

add to list
by Marco Ortega 12 May '06

12 May '06

1 0

[0.9.13]Dynamic drive configuration using HAL?
by Uwe Bonnes 12 May '06

12 May '06

Hallo, I don't find any explanation or usage hints on wine-devel. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

PBuffer and wglMakeCurrent()
by Tomas Carnecky 12 May '06

12 May '06

In wglMakeCurrent(), when the HDC type is OBJ_MEMDC you activate the frontbuffer for drawing. PBuffers' type is also OBJ_MEMDC, but changing the drawbuffer in that case is wrong. Is there a way to find out if the HDC is a PBuffer? I have some patches in my local tree but I took the freedom to put the X11DRV escape codes to one common header which alexandre doesn't quite like.. In my local tree I have a 'flags' field in X11DRV_PDEVICE which I use to store whether the PBuffer is damaged or not, I don't know if its the right place, but I could add a flag IS_PBUFFER and set it in wglGetPbufferDCARB() and check for it in wglMakeCurrent(). comments? tom

3 6

appdb [HeidiSQL]
by Molle Bestefich 11 May '06

11 May '06

What's going on with the AppDB? It's really annoying to spend a lot of time testing apps, grabbing screenshots, writing descriptions etc., just to see that nobody approves the applications entered. Can we please drop this entire "approval of new apps" crap? Or just give me proper privileges to approve the applications myself? (I can load the http://appdb.winehq.org/admin/adminAppQueue.php page btw, but the queue always displays 0 items.) PLEASE FIX. THANK YOU.

2 1

re: Possibly crazy idea to deal with memory layout problems once and for all
by Dan Kegel 11 May '06

11 May '06

> it seemed that the only way to resolve it would be to > get in between the application and any libraries, and the kernel. > > If wine_preloader were extended to have its own implementation of all the > friends of mmap(), and to have its own implementation of the dynamic linker, > then in principle it could make sure only its mmap (and not the C library's) > is called. You can override mmap() in wine by just changing all the places it's called. (Having control over the source is a wonderful thing.) But if you want mmap to behave truly differently, you'd probably need to change the kernel. I seem to recall somebody was working on a linux kernel module for wine that just dealt with program loading, but I can't recall who. Perhaps he'll surface and comment on this. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 7

Re: wininet: Fix a possible NULL pointer deference (Coverity)
by Alexandre Julliard 11 May '06

11 May '06

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/dlls/wininet/dialogs.c b/dlls/wininet/dialogs.c > index 24c8506..f24e4ef 100644 > --- a/dlls/wininet/dialogs.c > +++ b/dlls/wininet/dialogs.c > @@ -119,10 +119,9 @@ static BOOL WININET_GetAuthRealm( HINTER > if( q ) > *q = 0; > } > + strcpyW( szBuf, p ); > } > > - strcpyW( szBuf, p ); > - > return TRUE; > } Do we really want to return the unmodified string in that case? That doesn't seem quite right. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: CreateToolhelp32Snapshot tests
by Dmitry Timoshkov 11 May '06

11 May '06

"Stefan Leichter" <Stefan.Leichter(a)camLine.com> wrote: > e.g. > http://test.winehq.org/data/200605071000/2000_ahz-vm2k/kernel32:toolhelp.txt > show four failing tests beause of comparing upper and lower case dll names > - if (!strcmp(expected[i], me.szModule)) found[i]++; > + /* on win2k the names can be upper case */ > + if (!strcasecmp(expected[i], me.szModule)) found[i]++; It's better to use win32 API lstrcmpi since strcasecmp might be not available on a target windows platform. -- Dmitry.

1 0

Might be useful for wine (DIB): 3D software renderer (LGPL)
by Detlef Riekenberg 10 May '06

10 May '06

Hi Just found this on Freshmeat: -- cut -- VortexGE is a software 3D renderer for the X environment that was created without using OpenGL/MesaGL. It also supports 2D image manipulations and audio access and is intended for creating Linux games without needing 3D card acceleration. -- cut -- License: LGPL http://freshmeat.net/projects/vortexge Homepage: http://bluewind25.org/ -- By By ... ... Detlef

1 0

Re: [WINED3D 13/13] Further split GLSL & ARB_v/f_program generation and allow GLSL functions to be called.
by H. Verbeet 10 May '06

10 May '06

On 10/05/06, Jason Green <jave27(a)gmail.com> wrote: > This patch splits the remaining ARB_vertex_program calls out of of the > generate_base_shader function and adds the option to call GLSL > routines instead. These new routines are disabled because USING_GLSL > is defined as 0 in wined3d_private.h at the moment. It should remain > 0 until everything is implemented, working well, and tested > thoroughly. I think it would be best not to have USING_GLSL checks at several different places in the code. The function signatures are the same, so it wouldn't be that hard to just pass a pointer to the correct function.

2 2

Wine installation on Ubuntu Dapper
by Marco Eminente 10 May '06

10 May '06

Thanks to suggestions from Vitaliy Margolen, Neil Skrypuch and Scott Ritchie I downloaded and manually installed 32 bit libraries ia32-libs_1.4ubuntu17_amd64.deb libc6-dev-i386_2.3.6-0ubuntu17_amd64.deb libicu34-dev_3.4.1a-1ubuntu1_i386.deb libicu34_3.4.1a-1ubuntu1_i386.deb libttf2_1.4pre.20030402-1.1ubuntu1_i386.deb libttf-dev_1.4pre.20030402-1.1ubuntu1_i386.deb libx11-dev_6.2.1+cvs.20050722-8_i386.deb libxext6_1.0.0-0ubuntu4_i386.deb libxext-dev_1.0.0-0ubuntu4_i386.deb following instructions found in http://ubuntuforums.org/showthread.php?p=967834 and now giving the command : :~$ sudo apt-get --build source wine the process stops returning the following message LD_LIBRARY_PATH="../../libs/unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nost dinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_GDI32_ -foversi on.res version.rc ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib .spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmeta file.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmf drv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o map ping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/ mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdr v.o region.o version.res -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/lib/w ine /usr/lib` -o gdi32.dll.so -L../../dlls -ladvapi32 -lkernel32 -lntdll -L../. ./libs -lwine -L../../libs/unicode -lwine_unicode /usr/lib/libsicuuc.a /usr/lib/ libsicudata.a -lstdc++ -lgcc_s -L../../libs/port -lwine_port ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.wVZfHm.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[3]: *** [gdi32.dll.so] Error 2 make[3]: Leaving directory `/home/marco/wine-0.9.12~winehq1/dlls/gdi' make[2]: *** [gdi] Error 2 make[2]: Leaving directory `/home/marco/wine-0.9.12~winehq1/dlls' make[1]: *** [dlls] Error 2 make[1]: Leaving directory `/home/marco/wine-0.9.12~winehq1' make: *** [build-stamp] Error 2 Comando di costruzione 'cd wine-0.9.12~winehq1 && dpkg-buildpackage -b -uc' fallito. E: Processo figlio fallito Can anyone help me a little more? Thanks in advance Marco

3 3

windows/programming resources
by EA Durbin 10 May '06

10 May '06

Here are some additional resources not listed on the wine resources page. http://computer-books.us http://www.ssuet.edu.pk/~amkhan/MicrosoftBooks/windows.htm http://www.ssuet.edu.pk/~amkhan/Linuxbooks/linux.htm

1 0

Dos-promt for Wine and other tools to integrate in wine
by blackcrack 09 May '06

09 May '06

Hy, the pshell is now commezial, but it's a good idea to make a command-promt for wine.. , and i think other users wish a commandline in wine to clean execute dosprogramms in a window who can kill the exec-windows-cmd-line is hang it.. the same is, a clear room for dosprogramms who can insert explizit variables and kan take a autoexec and config.sys to load drivers for the meulating hardware in wine.. humm, why not use a autoexec.nt and config.nt... or autoexec.wn and config.wn to configurating the dosvariables in wine and to get ram,exetendet and other memory and set it in config.wn (ram=128m ; ext=640k) and make for it a "mem" to show the memory-config ... and why not use the wineserver as a tsr-progamm to start with the windowmanager to load the dos-command in backround and if start a win32-program it's start mutch faster if had start the wineserver by User and Windowmanager and have a stiky-icon in the Systemtray in KDE and Gnome or other WM's how Openoffice run-helper or how name is it ;) So can you load dos-16Bit cmd and the Win32-labary in backround and if execute a Win32-Program can now faster run and take faster the entrys in registry and dll's and have/can set the "SET" cariables explizite for Win32 and dos-16bit... wit the winecfg can adjust the "autoexec.bat" and "config.sys" for Dos (Wine-dos-emulation) and can use a computeremulation via bios.bin and this can load the io.sys,msdos.sys,config.sys,command.com(or boot.bin), and autoexec.bat for make explizite variables in wine-enviroment. Let not boot wine with "wine" , let start wine with wineserver and the first step let be, configuring the wine, without start the wineserver, over winecfg and make more entrys, how manny ram, memory and so, C:-entry who the user like and not in the hidden .wine-dir... bah... i make the first step to adjusting the C: Folder to my Useraccount under /home/user/win_c, it's better if a want move files and save files in my Win32-folder... the best Steps be, : 1. winecfg - without start wine/wineserver - Configuring my Wine explizit 2. Set my C: / WineFolder, where i want ! eg: where the USER want , and other Folders, Net-Folders,CD-Rom and so.. 3. Set the variables, how manny ram, ext. Mem and the 640k (you now what i mean?) the cmd, dosenviroment,path-variables, Sound and other variables what Wine need. 4. Now, start the Wine with wineserver who make a little systray-icon to be in the backround as tsr-programm/-wineserver- as dos16bit-win32-libary-and-enviroment-server ;) 5. and now we have all win32-eviroment what we need, DDE, Ole32 and the other programms who need still running can still running and be in the backround. A singelklick or dubbleklick on the wineserver-icon in the systray let popopen the winecfg and with rightklick a list were can be the controlpanel ;) this constellation is good for reactos too, i think... ;) regards Blacky

1 0

latest cvs, d3d regression
by Kovács András 09 May '06

09 May '06

Hi! The wine's latest cvs i get this error on every direct3d games. The error output refers always to IWineD3DSwapChainImpl_GetFrontBufferData function. Here is painkiller's log: andras@gep:~/.wine/drive_c/Program Files/DreamCatcher/Painkiller SP err:x11drv:X11DRV_CreateWindow invalid window height 2140055837 err:x11drv:X11DRV_CreateWindow invalid window height 2140055837 err:x11drv:X11DRV_CreateWindow invalid window height 2140055837 err:x11drv:X11DRV_CreateWindow invalid window height 2140055837 err:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Can't get drawa property __wine_x11_whole_window fixme:d3d8:IDirect3DDevice8Impl_CreateAdditionalSwapChain (0x7d1a221 SwapChain failed fixme:d3d8:IDirect3D8Impl_CreateDevice (0x7fddff48) D3D Initializati fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7d1eff28) : s tub, emulating 64Mib for now, returning 64Mib fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _MULTISAMPLEMASK,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _PATCHEDGESTYLE,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _PATCHSEGMENTS,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _DEBUGMONITORTOKEN,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _POSITIONDEGREE,3) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _NORMALDEGREE,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _MINTESSELLATIONLEVEL,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _MAXTESSELLATIONLEVEL,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _ADAPTIVETESS_X,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _ADAPTIVETESS_Y,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _ADAPTIVETESS_Z,1065353216) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _ADAPTIVETESS_W,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _ENABLEADAPTIVETESSELLATION,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _COLORWRITEENABLE1,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _COLORWRITEENABLE2,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _COLORWRITEENABLE3,15) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _BLENDFACTOR,-1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _SRGBWRITEENABLE,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _SEPARATEALPHABLENDENABLE,0) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _SRCBLENDALPHA,2) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _DESTBLENDALPHA,1) not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x7d1eff28)->(WINED3DRS _BLENDOPALPHA,1) not handled yet wine: Unhandled page fault on read access to 0x0000ffff at address 0 x7cab3ad2 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x0000ffff in 32-b it code (0x7cab3ad2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7cab3ad2 ESP:7fb7f8e0 EBP:7fb7f948 EFLAGS:00010246( - 00 -RIZP1) EAX:7fb7f938 EBX:7caede80 ECX:00000000 EDX:7fb7f908 ESI:0000ffff EDI:7fb7f92c Stack dump: 0x7fb7f8e0: 00000003 7caee804 7cae5145 7cad58ec 0x7fb7f8f0: 7d23db58 00000001 00001909 00001401 0x7fb7f900: 7caede80 7d23de70 7fb7f938 00000000 0x7fb7f910: 00000000 00000000 00000000 00000000 0x7fb7f920: 00000000 7fb7f934 7fb7f930 00000000 0x7fb7f930: 7e753fcc 7c5de000 7cab3a5b 7caede80 Backtrace: =>1 0x7cab3ad2 IWineD3DSwapChainImpl_GetFrontBufferData+0x82(iface=0 x7d23db58, pDestSurface=0xffff) [/home/andras/src/wine/dlls/wined3d/ swapchain.c:351] in wined3d (0x7cab3ad2) 2 0x7ca79fab IWineD3DDeviceImpl_GetFrontBufferData+0x4b(iface=0x7d 1eff28, iSwapChain=0x0, pDestSurface=0xffff) [/home/andras/src/wine/ dlls/wined3d/device.c:5610] in wined3d (0x7ca79fab) 3 0x7caab997 IWineD3DStateBlockImpl_InitStartupStateBlock+0x1407(i face=0x7d230960) [/home/andras/src/wine/dlls/wined3d/stateblock.c:80 8] in wined3d (0x7caab997) 4 0x7ca8a3f2 IWineD3DDeviceImpl_Init3D+0xe2(iface=0x7d1eff28, pPre sentationParameters=0x7fb7faa4, D3DCB_CreateAdditionalSwapChain=0x7c b83dd0) [/home/andras/src/wine/dlls/wined3d/device.c:1706] in wined3 d (0x7ca8a3f2) 5 0x7cb84796 IDirect3D8Impl_CreateDevice+0x136(iface=0x7fddff48, A dapter=0x0, DeviceType=0x1, hFocusWindow=0x1021c, BehaviourFlags=0x5 0, pPresentationParameters=0x7c943168, ppReturnedDeviceInterface=0x7 c943090) [/home/andras/src/wine/dlls/d3d8/directx.c:336] in d3d8 (0x 7cb84796) fixme:dbghelp:sffip_cb NIY on 'c:\Painkiller\Game\Bin\ObjectsRelease \D3Dev\D3Dev.pdb' 6 0x7cb95229 in d3dev (+0x5229) (0x7cb95229) 7 0x00000000 (0x00000000) 0x7cab3ad2 IWineD3DSwapChainImpl_GetFrontBufferData+0x82 [/home/andr as/src/wine/dlls/wined3d/swapchain.c:351] in wined3d: movl 0x0( %esi),%eax 351 IWineD3DSurface_GetDesc(pDestSurface, &desc); Modules: Module Address Debug info Name (113 modules) PE 0x00400000-005c9000 Deferred paingame PE 0x10000000-1081a000 Deferred engine PE 0x21100000-21164000 Deferred mss32 PE 0x30000000-3006e000 Deferred binkw32 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ca53000-7caef000 Stabs wined3d<elf> \-PE 0x7ca70000-7caef000 \ wined3d ELF 0x7caef000-7cb65000 Deferred libglu.so.1 ELF 0x7cb65000-7cb90000 Stabs d3d8<elf> \-PE 0x7cb70000-7cb90000 \ d3d8 PE 0x7cb90000-7cbf2000 Export d3dev ELF 0x7d620000-7d746000 Deferred libcrypto.so.0.9.8 ELF 0x7d746000-7d783000 Deferred libssl.so.0.9.8 ELF 0x7d783000-7d7a1000 Deferred libcups.so.2 ELF 0x7d9fe000-7da30000 Deferred uxtheme<elf> \-PE 0x7da10000-7da30000 \ uxtheme ELF 0x7db46000-7db50000 Deferred libnss_files.so.2 ELF 0x7dc64000-7dc68000 Deferred iso8859-2.so ELF 0x7dd81000-7dda7000 Deferred msacm32<elf> \-PE 0x7dd90000-7dda7000 \ msacm32 ELF 0x7dddc000-7dde7000 Deferred libgcc_s.so.1 ELF 0x7dec7000-7decb000 Deferred libresmgr.so.1 ELF 0x7decb000-7df74000 Deferred libmcop.so.1 ELF 0x7df74000-7e029000 Deferred libartsflow_idl.so.1 ELF 0x7e029000-7e051000 Deferred libvorbis.so.0 ELF 0x7e051000-7e14d000 Deferred libvorbisenc.so.2 ELF 0x7e14d000-7e154000 Deferred libvorbisfile.so.3 ELF 0x7e154000-7e15d000 Deferred librt.so.1 ELF 0x7e15d000-7e219000 Deferred libasound.so.2 ELF 0x7e219000-7e23c000 Deferred libaudiofile.so.0 ELF 0x7e23c000-7e27f000 Deferred libkmedia2_idl.so.1 ELF 0x7e27f000-7e2e3000 Deferred libsoundserver_idl.s o.1 ELF 0x7e2e3000-7e408000 Deferred libartsflow.so.1 ELF 0x7e40a000-7e41f000 Deferred midimap<elf> \-PE 0x7e410000-7e41f000 \ midimap ELF 0x7e41f000-7e437000 Deferred msacm<elf> \-PE 0x7e430000-7e437000 \ msacm ELF 0x7e437000-7e4bd000 Deferred libglib-2.0.so.0 ELF 0x7e4bd000-7e4c3000 Deferred libartsc.so.0 ELF 0x7e4c4000-7e4c9000 Deferred libogg.so.0 ELF 0x7e4c9000-7e4e1000 Deferred libjack.so.0 ELF 0x7e4e1000-7e4f2000 Deferred libartscbackend.so ELF 0x7e4f2000-7e50e000 Deferred imm32<elf> \-PE 0x7e500000-7e50e000 \ imm32 ELF 0x7e554000-7e55c000 Deferred libxrender.so.1 ELF 0x7e55c000-7e560000 Deferred libgthread-2.0.so.0 ELF 0x7e560000-7e57a000 Deferred winearts<elf> \-PE 0x7e570000-7e57a000 \ winearts ELF 0x7e5ec000-7edad000 Deferred libglcore.so.1 ELF 0x7edad000-7ee32000 Deferred libgl.so.1 ELF 0x7ee32000-7ef29000 Deferred libx11.so.6 ELF 0x7ef29000-7ef37000 Deferred libxext.so.6 ELF 0x7ef37000-7ef3c000 Deferred libxxf86vm.so.1 ELF 0x7ef3c000-7ef45000 Deferred libsm.so.6 ELF 0x7ef46000-7ef49000 Deferred libgmodule-2.0.so.0 ELF 0x7ef49000-7ef4e000 Deferred libxfixes.so.3 ELF 0x7ef4e000-7ef57000 Deferred libxcursor.so.1 ELF 0x7ef57000-7ef74000 Deferred ximcp.so.2 ELF 0x7ef74000-7eff8000 Deferred winex11<elf> \-PE 0x7ef80000-7eff8000 \ winex11 ELF 0x7f1ee000-7f20d000 Deferred libexpat.so.1 ELF 0x7f20d000-7f246000 Deferred libfontconfig.so.1 ELF 0x7f246000-7f258000 Deferred libz.so.1 ELF 0x7f258000-7f2c5000 Deferred libfreetype.so.6 ELF 0x7f2c6000-7f2cb000 Deferred libxxf86dga.so.1 ELF 0x7f2cb000-7f2e3000 Deferred libice.so.6 ELF 0x7f2f4000-7f38e000 Deferred oleaut32<elf> \-PE 0x7f310000-7f38e000 \ oleaut32 ELF 0x7f38e000-7f3bd000 Deferred winspool<elf> \-PE 0x7f3a0000-7f3bd000 \ winspool ELF 0x7f3bd000-7f45f000 Deferred comdlg32<elf> \-PE 0x7f3d0000-7f45f000 \ comdlg32 ELF 0x7f45f000-7f479000 Deferred wsock32<elf> \-PE 0x7f470000-7f479000 \ wsock32 ELF 0x7f479000-7f539000 Deferred comctl32<elf> \-PE 0x7f480000-7f539000 \ comctl32 ELF 0x7f539000-7f596000 Deferred shlwapi<elf> \-PE 0x7f550000-7f596000 \ shlwapi ELF 0x7f596000-7f676000 Deferred shell32<elf> \-PE 0x7f5b0000-7f676000 \ shell32 ELF 0x7f676000-7f6ff000 Deferred winmm<elf> \-PE 0x7f680000-7f6ff000 \ winmm ELF 0x7f6ff000-7f72a000 Deferred ws2_32<elf> \-PE 0x7f710000-7f72a000 \ ws2_32 ELF 0x7f72a000-7f777000 Deferred rpcrt4<elf> \-PE 0x7f740000-7f777000 \ rpcrt4 ELF 0x7f777000-7f807000 Deferred gdi32<elf> \-PE 0x7f790000-7f807000 \ gdi32 ELF 0x7f807000-7f937000 Deferred user32<elf> \-PE 0x7f820000-7f937000 \ user32 ELF 0x7f937000-7f979000 Deferred advapi32<elf> \-PE 0x7f940000-7f979000 \ advapi32 ELF 0x7f979000-7fa11000 Deferred ole32<elf> \-PE 0x7f990000-7fa11000 \ ole32 ELF 0x7fa11000-7fa4e000 Deferred dinput<elf> \-PE 0x7fa20000-7fa4e000 \ dinput ELF 0x7fa4e000-7fa70000 Deferred dinput8<elf> \-PE 0x7fa60000-7fa70000 \ dinput8 ELF 0x7fbca000-7fcd0000 Deferred kernel32<elf> \-PE 0x7fbe0000-7fcd0000 \ kernel32 ELF 0x7fde1000-7fde3000 Deferred xlcutf8load.so.2 ELF 0x7fe18000-7fe3d000 Deferred libm.so.6 ELF 0x7fe3d000-7fe40000 Deferred libxrandr.so.2 ELF 0x7fe43000-7fe61000 Deferred iphlpapi<elf> \-PE 0x7fe50000-7fe61000 \ iphlpapi ELF 0x7fe6c000-7ff62000 Deferred libwine_unicode.so.1 ELF 0x7ff62000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff70000-7ffe0000 \ ntdll ELF 0xb7e31000-b7e33000 Deferred libnvidia-tls.so.1 ELF 0xb7e3c000-b7e40000 Deferred libdl.so.2 ELF 0xb7e40000-b7f60000 Deferred libc.so.6 ELF 0xb7f60000-b7f74000 Deferred libpthread.so.0 ELF 0xb7fbe000-b7fda000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) C:\Program Files\DreamCatcher\Painkiller SP Demo\Bin\Pa inGame.exe 00000009 0 <== Best regards, -- Lamarr Kovács András andras(a)csevego.net http://csevego.net

2 2

Re: dnsapi: Add tests for DnsValidateName_A. (Resend)
by Alexandre Julliard 09 May '06

09 May '06

Hans Leidekker <hans(a)it.vu.nl> writes: > + { "a.ö", DnsNameDomain, DNS_ERROR_NON_RFC_NAME }, It's better to avoid including Latin-1 characters in C source, especially since this means the test results will then depend on the locale. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Add stubs for NtCreateWaitablePort, NtReplyPort, and NtRequestPort [RESEND]
by Alexandre Julliard 09 May '06

09 May '06

"James Hawkins" <truiken(a)gmail.com> writes: > Is there anything wrong with this patch? It's needed for the > following port test patch. Do you have a real app that works better with that stub? Otherwise I think we want to wait until it's fleshed out a bit more to add it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ntdll: Add initial tests for the NT port functions
by Vitaliy Margolen 09 May '06

09 May '06

Monday, May 8, 2006, 11:35:46 PM, James Hawkins wrote: > Hi, > Changelog: > * Add initial tests for the NT port functions. > dlls/ntdll/tests/Makefile.in | 1 > dlls/ntdll/tests/port.c | 314 > ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 315 insertions(+), 0 deletions(-) > create mode 100644 dlls/ntdll/tests/port.c > -- > James Hawkins > +typedef struct _LPC_SECTION_READ > +{ > + ULONG Length; > + ULONG ViewSize; > + PVOID ViewBase; > +} LPC_SECTION_READ, *PLPC_SECTION_READ; > + This should go as a separate patch to include/ddk I think. > + HRESULT hr; > + > + ok(LpcMessage->>MessageType == LPC_CONNECTION_REQUEST, > + "Expected LPC_CONNECTION_REQUEST, got %d\n", LpcMessage->MessageType); > + ok(!*LpcMessage->Data, "Expected empty string!\n"); > + > + hr = pNtAcceptConnectPort(pAcceptPortHandle, 0, LpcMessage, 1, 0, NULL); > + ok(hr == S_OK, "Expected S_OK, got %ld\n", hr); HRESULT and NTSATUS are not the same things. You should not use HRESULT here at all. Vitaliy Margolen

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2006