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

re: How to make your machine crash when running Wine
by Dan Kegel June 26, 2007

June 26, 2007

There's a similar discussion going on here: http://www.linuxforums.org/forum/wine/96022-wine-hard-system-freeze-new-pos… --- snip --- i had the same problem. I use wine with Ubuntu Daper on Core T7200 Duo Laptop. I moved from the kernel 2.6.15-28-386 to 2.6.15-28-686 and wine starts to freeze. * moving from nvidia to vesa-driver -> no luck * set Hyperthreading-kernelswitch ht=on to ht=off -> no luck After moving back to 2.6.15-28-386 it worked again. The workaround ist to use the 386-kernel. (Linux version 2.6.15-28-386 (buildd(a)terranova) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 PREEMPT Thu May 10 09:45:43 UTC 2007) PS: I used wine_0.9.39~winehq0~ubuntu~6.06-1_i386.deb and wine_0.9.9-0ubuntu2_i386.deb --- snip ---

1 0

Using Rx Controls (Delphi) [resend]
by Anatoly Lyutin June 26, 2007

June 26, 2007

-- Best regards Anatoly Lyutin.

1 0

Re: msi [1/6]: Add support for remote handles
by Alexandre Julliard June 26, 2007

June 26, 2007

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -215,18 +282,28 @@ UINT WINAPI MsiCloseHandle(MSIHANDLE han > > EnterCriticalSection( &MSI_handle_cs ); > > - info = msihandle2msiinfo(handle, 0); > - if( !info ) > - goto out; > - > - if( info->magic != MSIHANDLE_MAGIC ) > + unk = msi_get_remote( handle ); > + if (unk) > + IUnknown_Release( unk ); > + else > { It seems to me you are leaking the object here, the handle entry holds a ref to it too. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: About stdlib.h system()
by Kirill K. Smirnov June 26, 2007

June 26, 2007

I've tried MSVC 6.0 and MSVC 2003. All the same - it works. Please, check your sources. I have no idea where the bug can be. > Yes, the mingw-gcc case works. > But I use the Visual C++ 7.0 to compile. It still fails. > > On 6/26/07, Kirill K. Smirnov <lich(a)math.spbu.ru> wrote: > > Hi, > > > > I've tried to reproduce, but failed: > > > > a.c: > > #include <stdio.h> > > #include <stdlib.h> > > > > int main(void) > > { > > system("qqq.exe"); > > return 0; > > } > > > > > > $ mingw-gcc -mconsole -mno-cygwin a.c > > $ wine a.exe > > > > It works. > > > > $ mingw-gcc a.c > > $ wine a.exe > > > > It works too. > > > > Executable qqq.exe exists in ~/.wine/drive_c/windows directory. > > > > -- > > Kirill

1 0

About stdlib.h system()
by Kirill K. Smirnov June 26, 2007

June 26, 2007

Hi, I've tried to reproduce, but failed: a.c: #include <stdio.h> #include <stdlib.h> int main(void) { system("qqq.exe"); return 0; } $ mingw-gcc -mconsole -mno-cygwin a.c $ wine a.exe It works. $ mingw-gcc a.c $ wine a.exe It works too. Executable qqq.exe exists in ~/.wine/drive_c/windows directory. -- Kirill

2 1

please help me with filling a bug concerning WM_ERASEBKGND
by RusH June 26, 2007

June 26, 2007

searching bugzilla for WM_ERASEBKGND returns lots of bugs, but I have no idea if mine is there http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allwordssu… The bug is weird. Running uTorrent (latest beta ) http://download.utorrent.com/beta/utorrent-1.7-beta-2899.uncompressed.exe with wine set to emulate XP is fine, but when you set it to Windows 98 or lower wine stops sending WM_ERASEBKGND (or/and breaks WM_PAINT). background surfaces are not repainted and remain black. is this http://bugs.winehq.org/show_bug.cgi?id=6006 ? Il try to compile latest git with patches from that bug before filling new one. -- Who logs in to gdm? Not I, said the duck.

1 0

user32 patch unaccepted
by Clinton Stimpson June 26, 2007

June 26, 2007

Was there anything wrong with this patch, that it didn't get accepted? <http://www.winehq.org/pipermail/wine-patches/2007-March/037272.html> It limits update regions to the nearest clipping parent window. Thanks Clinton Stimpson

1 0

Re: gdi32: Multi-character character constants aren't portable as their behaviour is compiler dependent according to the C standard. Found by sparse.
by James Hawkins June 25, 2007

June 25, 2007

On 6/25/07, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > I have no way to test this patch as i don't have a Mac. > > bye > michael > --- > dlls/gdi32/freetype.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 424fb3d..bcf16ae 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -590,6 +590,7 @@ static char **expand_mac_font(const char *path) > unsigned short *num_faces_ptr, num_faces, face; > AsscEntry *assoc; > Handle fond; > + ResType fond_res = 0x464f4e44 /* 'FOND' */; > > fond = Get1IndResource('FOND', idx); > if(!fond) break; Did you mean to replace 'FOND' in the Get1IndResource call with fond_res? > @@ -605,6 +606,7 @@ static char **expand_mac_font(const char *path) > for(face = 0; face < num_faces; face++, assoc++) > { > Handle sfnt; > + ResType sfnt_res = 0x73666e74 /* 'sfnt' */ > unsigned short size, font_id; > char *output; > > @@ -617,7 +619,7 @@ static char **expand_mac_font(const char *path) > } > > TRACE("trying to load sfnt id %04x\n", font_id); > - sfnt = GetResource('sfnt', font_id); > + sfnt = GetResource(sfnt_res, font_id); > if(!sfnt) > { > TRACE("can't get sfnt resource %04x\n", font_id); > -- > 1.5.0.6 > -- James Hawkins

1 0

re: WIDL: Implement support for explicit user handles
by Dan Kegel June 25, 2007

June 25, 2007

Eric wrote: > This patch implements support for explicit user handles. Say, could you add a test for that? I think Dan H. usually adds tests to rpcrt4 whenever he adds a feature to widl. cf. http://source.winehq.org/git/?p=wine.git&a=search&st=author&s=dsh - Dan

1 0

Re: [5/5] WineD3D: Implement mipmap auto generation
by Stefan Dösinger June 25, 2007

June 25, 2007

Am Montag, 25. Juni 2007 14:42 schrieb Stefan Dösinger: > I have no application that needs this, so this is an untested per-msdn > implementation. Do not apply this patch yet. It's missing some check in LoadTexture to not upload sublevels manually if autogen is on

1 0

Re: [3/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
by H. Verbeet June 25, 2007

June 25, 2007

On 25/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + 0x0009fffe, 0x58443344, 0x68532038, /* No idea about that stuff, */ > + 0x72656461, 0x73734120, 0x6c626d65, /* vsa.exe generated it */ > + 0x56207265, 0x69737265, 0x30206e6f, /* And without it windows complains*/ > + 0x0031392e, That looks pretty bad, imo.

2 1

Re: mshtml #14: Added more QueryInterface tests.
by Detlef Riekenberg June 25, 2007

June 25, 2007

On So, 2007-06-24 at 21:10 +0200, Jacek Caban wrote: > + ok(qi == NULL, "runnable=%p, ezpected NULL\n", qi) The Patch is in the Tree, but I suggest to change: "ezpected" to "expected" in several Places. Thanks, with greetings from Copy and Paste -- By by ... Detlef

2 1

Making the wiki FAQ live
by Scott Ritchie June 25, 2007

June 25, 2007

So, about a month ago we discussed the idea of replacing the documentation FAQ with one based in the wiki. Nothing was done, but the general consensus seemed to be to wait and see if the wiki approach worked out better. Since that time, the Wiki FAQ has been updated by 7 people other than myself. We've removed most of the cruft, and taken the FAQ from an unhelpful mess to something a user actually should read. Meanwhile, the original FAQ has been unchanged. It's not done, but I think it's time to take it live and make the wiki FAQ our official FAQ, and then remove the old one from the documentation build. Based on the past month alone, I think it's fairly safe to say that it's easier to maintain, update, and keep relevant this way. I've already sent a patch for lostwages to wine-devel. Thanks, Scott Ritchie

3 3

re: VST wrapper
by Dan Kegel June 25, 2007

June 25, 2007

Hi N8, > [How can I write a shared library that uses Wine and > can be called from a non-winelib app?] This is a somewhat frequently asked question. As Stephan explained, wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround. - Dan

2 1

Re: [3/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
by Frank Richter June 25, 2007

June 25, 2007

On 25.06.2007 16:03, H. Verbeet wrote: > On 25/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> + 0x0009fffe, 0x58443344, 0x68532038, /* No >> idea about that stuff, */ >> + 0x72656461, 0x73734120, 0x6c626d65, /* >> vsa.exe generated it */ >> + 0x56207265, 0x69737265, 0x30206e6f, /* And >> without it windows complains*/ >> + 0x0031392e, > That looks pretty bad, imo. FWIW, that comment reads "D3DX8 Shader Assembler Version 0.91". -f.r.

1 0

configure:2479: error: C compiler cannot create executables
by jens＠jens June 25, 2007

June 25, 2007

This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 0.9.39, which was generated by GNU Autoconf 2.61. Invocation command line was $ ./configure --prefix=/opt/wine --with-x ## --------- ## ## Platform. ## ## --------- ## hostname = jens uname -m = x86_64 uname -r = 2.6.20-15-generic uname -s = Linux uname -v = #2 SMP Sun Apr 15 06:17:24 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1888: checking build system type configure:1906: result: x86_64-unknown-linux-gnu configure:1928: checking host system type configure:1943: result: x86_64-unknown-linux-gnu configure:2008: checking whether make sets $(MAKE) configure:2029: result: yes configure:2086: checking for gcc configure:2113: result: gcc -m32 configure:2351: checking for C compiler version configure:2358: gcc -m32 --version >&5 gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2361: $? = 0 configure:2368: gcc -m32 -v >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) configure:2371: $? = 0 configure:2378: gcc -m32 -V >&5 gcc: '-V' must come at the start of the command line configure:2381: $? = 1 configure:2404: checking for C compiler default output file name configure:2431: gcc -m32 /usr/lib32 conftest.c >&5 /usr/bin/ld: /usr/lib32: No such file: File format not recognized collect2: ld returned 1 exit status configure:2434: $? = 1 configure:2472: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.39" | #define PACKAGE_STRING "Wine 0.9.39" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2479: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=/usr/lib32 ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CARBONLIB='' CC='gcc -m32' CFLAGS='' COREAUDIO='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CXX='' CXXFLAGS='' DEFS='' DEPENDENCIES='' DISKARBITRATIONLIB='' DLLEXT='' DLLFLAGS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' EXTRA_BINARIES='' FLEX='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GPHOTO2INCL='' GPHOTO2LIBS='' GREP='' HALINCL='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='/usr/lib32' LDPATH='' LDSHARED='' LIBDL='' LIBEXT='' LIBOBJS='' LIBPOLL='' LIBPTHREAD='' LIBS='' LIBWINE_LDFLAGS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' MINGWAR='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 0.9.39' PACKAGE_TARNAME='wine' PACKAGE_VERSION='0.9.39' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' QUARTZFILES='' RANLIB='' RESOLVLIBS='' SANEINCL='' SET_MAKE='' SHELL='/bin/bash' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' XFILES='' XLIB='' XMKMF='' XML2INCL='' XML2LIBS='' XSLTINCL='' XSLTLIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CXX='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' ft_devel2='' ft_devel='' gphoto2_devel='' gphoto2port_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/opt/wine' program_transform_name='s,x,x,' psdir='${docdir}' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------------- ## ## File substitutions. ## ## ------------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Wine" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "0.9.39" #define PACKAGE_STRING "Wine 0.9.39" #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" configure: exit 77

3 2

Re: [Bug 8787] Manhunt: Video goes all black and haywire after intro movies.
by James Hawkins June 25, 2007

June 25, 2007

On 6/24/07, joe b <goce_jeb(a)yahoo.com> wrote: > Game will not install under wine though. That's why I had to install under > the windows partition. > > You can't file a bug report for a game you run from a Windows partition. It's not supported by Wine, mostly because we can't reproduce any bugs this way. If you can't install the game in Wine, then please open a bug report for that. -- James Hawkins

1 0

Re: user32,wined3d: move refresh rate fallback to catch all cases
by H. Verbeet June 25, 2007

June 25, 2007

On 24/06/07, Erik Inge Bolsø <knan-wine(a)anduin.net> wrote: > --- > dlls/user32/sysparams.c | 13 ++++++++++++- > dlls/wined3d/device.c | 10 +--------- > 2 files changed, 13 insertions(+), 10 deletions(-) > What was the reason for writing this?

1 0

Re: mshtml: Implement HTMLElement_get_children.
by Jacek Caban June 25, 2007

June 25, 2007

Hi, > + elem_vector buf = {NULL, 0, 8}; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + buf.buf = mshtml_alloc(buf.size*sizeof(HTMLElement**)); elem_vector is a self-resizable table, but in this case you know the size while creating it from nsIDOMNodeList::GetLength. I'd suggest to use it here during creation of buf to avoid useless memory reallocations. Thanks, Jacek

2 1

Re: WIDL: Implement support for explicit user handles
by Robert Shearman June 25, 2007

June 25, 2007

Eric Kohl wrote: > This patch implements support for explicit user handles. Looks good, but one small nit-pick: Microsoft calls these "generic" handles instead of user handles. It would be good if you could rename the relevant bits to match this. Thanks, -- Rob Shearman

1 0

VST wrapper
by Nathaniel Gray June 25, 2007

June 25, 2007

Hi, I'm interested in the goal of using Windows VST/VSTi audio plugins on my Intel Mac in OS X. I found the fst project, did some porting, and managed to get a few VSTs to work, which had me pretty stoked. Thanks to the FST folks and the Wine team for making this possible! On the other hand, I'd rather have the option of running the plugins in-process with my DAW software instead of as separate processes connected by JACK. I can imagine a super-thin layer of code that just translates calls between the plugin and the host and allows the plugin to access the Win32 API. In case I'm being unclear, here's how it breaks down. There's a host application that's native OS X and knows nothing about Wine. I'd like to write a plugin that, when it's loaded, will load a windows dll. The host will call into the plugin, which will call into the dll. The dll will make upcalls to the plugin, which will in turn call up to the host. The dll will probably be running a windows gui as well and making calls to various windows APIs. So is this possible? I'm pretty new to Wine and Windows programming so forgive me if the answer to this question is obvious. I've seen plenty of examples of how to build and run .exes that are windows programs from the ground up, but I've never seen wine used as part of a plugin. If it's possible, can you point me to any examples? What are the relevant parts of Wine I should look at? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

2 1

Re: VST wrapper
by Nathaniel Gray June 25, 2007

June 25, 2007

By the way, please CC me with replies. I'm not set up to receive mail from the list. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

2 1

fix for wine < 0.9.24 segfault on startup
by Damjan Jovanovic June 25, 2007

June 25, 2007

Hi On Ubuntu 7.04, versions of wine before around 0.9.24 die on startup with an undebuggable segmentation fault. After this bug stopped me from doing 2 regression tests, I decided to reverse regression test for the fix to the bug, and I found that the patch at http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html allows earlier versions of wine to run successfully. Thought this might be helpful to others Damjan

1 0

WIDL: Implement support for explicit user handles
by Eric Kohl June 24, 2007

June 24, 2007

This patch implements support for explicit user handles. Regards Eric Kohl ChangeLog: Implement support for explicit user handles. diff --git a/tools/widl/client.c b/tools/widl/client.c index 86ead20..6a84e94 100644 --- a/tools/widl/client.c +++ b/tools/widl/client.c @@ -89,12 +89,14 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) { const var_t *def = func->def; const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(func); + explicit_user_handle_var = get_explicit_user_handle_var(func); if (explicit_handle) { - if (!explicit_handle_var) + if (!explicit_handle_var && !explicit_user_handle_var) { error("%s() does not define an explicit binding handle!\n", def->name); return; @@ -102,7 +104,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) } else if (implicit_handle) { - if (explicit_handle_var) + if (explicit_handle_var || explicit_user_handle_var) { error("%s() must not define a binding handle!\n", def->name); return; @@ -167,6 +169,19 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) print_client("_Handle = %s;\n", explicit_handle_var->name); fprintf(client, "\n"); } + else if (explicit_user_handle_var) + { + print_client("_Handle = %s_bind(%s);\n", + explicit_user_handle_var->type->name, + explicit_user_handle_var->name); + print_client("if (_Handle == 0)\n"); + print_client("{\n"); + indent++; + print_client("RpcRaiseException(RPC_S_INVALID_BINDING);\n"); + indent--; + print_client("}\n"); + fprintf(client, "\n"); + } write_remoting_arguments(client, indent, func, PASS_IN, PHASE_BUFFERSIZE); @@ -240,6 +255,19 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) print_client("NdrFreeBuffer((PMIDL_STUB_MESSAGE)&_StubMsg);\n"); + if (explicit_user_handle_var) + { + fprintf(client, "\n"); + print_client("if (_Handle)\n"); + print_client("{\n"); + indent++; + print_client("%s_unbind(%s, _Handle);\n", + explicit_user_handle_var->type->name, + explicit_user_handle_var->name); + indent--; + print_client("}\n"); + } + indent--; print_client("}\n"); print_client("RpcEndFinally\n"); diff --git a/tools/widl/header.c b/tools/widl/header.c index 6f2da32..1119542 100644 --- a/tools/widl/header.c +++ b/tools/widl/header.c @@ -463,6 +463,21 @@ const var_t* get_explicit_handle_var(const func_t* func) return NULL; } +const var_t* get_explicit_user_handle_var(const func_t* func) +{ + const var_t* var; + + if (!func->args) + return NULL; + + LIST_FOR_EACH_ENTRY( var, func->args, const var_t, entry ) + if ((var->type->type != RPC_FC_BIND_PRIMITIVE) && + is_attr(var->type->attrs, ATTR_HANDLE)) + return var; + + return NULL; +} + int has_out_arg_or_return(const func_t *func) { const var_t *var; @@ -480,6 +495,40 @@ int has_out_arg_or_return(const func_t *func) return 0; } +static struct list user_handle_list = LIST_INIT(user_handle_list); + +struct user_handle +{ + struct list entry; + char name[1]; +}; + +void add_user_handle(type_t *type) +{ + struct user_handle *uh; + + if (is_attr(type->attrs, ATTR_HANDLE)) + { + uh = (struct user_handle *)xmalloc(sizeof(struct user_handle) + strlen(type->name)); + if (uh) + { + strcpy(uh->name, type->name); + list_add_tail(&user_handle_list, &uh->entry); + } + } +} + +void write_user_handles(void) +{ + const struct user_handle *uh; + + LIST_FOR_EACH_ENTRY(uh, &user_handle_list, struct user_handle, entry) + { + fprintf(header, "handle_t __RPC_USER %s_bind(%s);\n", uh->name, uh->name); + fprintf(header, "void __RPC_USER %s_unbind(%s, handle_t);\n", uh->name, uh->name); + } +} + /********** INTERFACES **********/ @@ -710,6 +759,7 @@ static void write_function_protos(const type_t *iface) const char *implicit_handle = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); int explicit_handle = is_attr(iface->attrs, ATTR_EXPLICIT_HANDLE); const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; const func_t *cur; int prefixes_differ = strcmp(prefix_client, prefix_server); @@ -720,13 +770,19 @@ static void write_function_protos(const type_t *iface) /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(cur); - if (explicit_handle) { - if (!explicit_handle_var) { + explicit_user_handle_var = get_explicit_user_handle_var(cur); + if (explicit_handle) + { + if (!explicit_handle_var && !explicit_user_handle_var) + { error("%s() does not define an explicit binding handle!\n", def->name); return; } - } else if (implicit_handle) { - if (explicit_handle_var) { + } + else if (implicit_handle) + { + if (explicit_handle_var || explicit_user_handle_var) + { error("%s() must not define a binding handle!\n", def->name); return; } diff --git a/tools/widl/header.h b/tools/widl/header.h index 54655a2..7a6508b 100644 --- a/tools/widl/header.h +++ b/tools/widl/header.h @@ -53,9 +53,12 @@ extern void write_externdef(const var_t *v); extern void write_library(const char *name, const attr_list_t *attr); extern void write_user_types(void); extern const var_t* get_explicit_handle_var(const func_t* func); +extern const var_t* get_explicit_user_handle_var(const func_t* func); extern int has_out_arg_or_return(const func_t *func); extern void write_guid(FILE *f, const char *guid_prefix, const char *name, const UUID *uuid); +extern void add_user_handle(type_t *type); +extern void write_user_handles(void); static inline int last_ptr(const type_t *type) { diff --git a/tools/widl/parser.y b/tools/widl/parser.y index 4933c43..a6df42d 100644 --- a/tools/widl/parser.y +++ b/tools/widl/parser.y @@ -1932,7 +1932,10 @@ static void process_typedefs(pident_list_t *pidents) type_t *type = find_type(var->name, 0); if (! parse_only && do_header) + { write_typedef(type); + add_user_handle(type); + } if (in_typelib && type->attrs) add_typelib_entry(type); diff --git a/tools/widl/server.c b/tools/widl/server.c index fd94c9a..2e261e5 100644 --- a/tools/widl/server.c +++ b/tools/widl/server.c @@ -61,6 +61,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) const func_t *func; const var_t *var; const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; if (!iface->funcs) return; LIST_FOR_EACH_ENTRY( func, iface->funcs, const func_t, entry ) @@ -69,9 +70,10 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(func); + explicit_user_handle_var = get_explicit_user_handle_var(func); if (explicit_handle) { - if (!explicit_handle_var) + if (!explicit_handle_var && !explicit_user_handle_var) { error("%s() does not define an explicit binding handle!\n", def->name); return; @@ -79,7 +81,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) } else if (implicit_handle) { - if (explicit_handle_var) + if (explicit_handle_var || explicit_user_handle_var) { error("%s() must not define a binding handle!\n", def->name); return; diff --git a/tools/widl/widl.c b/tools/widl/widl.c index 21657b6..0af449d 100644 --- a/tools/widl/widl.c +++ b/tools/widl/widl.c @@ -409,6 +409,7 @@ int main(int argc,char *argv[]) if(do_header) { fprintf(header, "/* Begin additional prototypes for all interfaces */\n"); fprintf(header, "\n"); + write_user_handles(); write_user_types(); fprintf(header, "\n"); fprintf(header, "/* End additional prototypes */\n");

1 0

wine menus
by Damjan Jovanovic June 24, 2007

June 24, 2007

Hi At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled. Wine also keeps .lnk files in ~/.wine/drive_c/windows/profiles/<user>/Start Menu/ just like Windows does, and those .lnk files seem like a much better representation of the menus that should appear on the system, because they are also deleted when an app is uninstalled. Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay? Thank you Damjan

7 9

Re: msi: Fix use of uninitialized variable (Coverity) (Try 3)
by James Hawkins June 24, 2007

June 24, 2007

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > [Reverting to "Plan A":] > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 22:19:03.000000000 +0100 > @@ -4668,7 +4668,7 @@ > > res = env_set_flags(&name, &deformatted, &flags); > if (res != ERROR_SUCCESS) > - goto done; > + goto done2; > > value = deformatted; > > @@ -4676,8 +4676,14 @@ > root = HKEY_LOCAL_MACHINE; > > res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); > + /* > + * FIXME: RegCloseKey() should not be called with an invalid handle. > + * So should we simply "goto done2" here, if res != EXIT_SUCCESS, > + * or does RegOpenKeyEx() have any failure modes in which "env" does > + * get initialized? > + */ > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVE) > FIXME("Not removing environment variable on uninstall!\n"); > @@ -4686,14 +4692,14 @@ > res = RegQueryValueExW(env, name, NULL, &type, NULL, &size); > if ((res != ERROR_SUCCESS && res != ERROR_FILE_NOT_FOUND) || > (res == ERROR_SUCCESS && type != REG_SZ)) > - goto done; > + goto done1; > > if (res != ERROR_FILE_NOT_FOUND) > { > if (flags & ENV_ACT_SETABSENT) > { > res = ERROR_SUCCESS; > - goto done; > + goto done1; > } > > data = msi_alloc(size); > @@ -4705,12 +4711,12 @@ > > res = RegQueryValueExW(env, name, NULL, &type, (LPVOID)data, &size); > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVEMATCH && (!value || !lstrcmpW(data, value))) > { > res = RegDeleteKeyW(env, name); > - goto done; > + goto done1; > } > > size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR); > @@ -4719,7 +4725,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > if (!(flags & ENV_MOD_MASK)) > @@ -4749,7 +4755,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > lstrcpyW(newval, value); > @@ -4758,8 +4764,9 @@ > TRACE("setting %s to %s\n", debugstr_w(name), debugstr_w(newval)); > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > -done: > +done1: > RegCloseKey(env); > +done2: > msi_free(deformatted); > msi_free(data); > msi_free(newval); > This is uglier than the other patch. The only change needed in this entire function is to set env to NULL initially. There's nothing wrong with calling RegCloseKey(NULL-var) and it's done everywhere in the code base. -- James Hawkins

1 0

Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
by James Hawkins June 24, 2007

June 24, 2007

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > This patch should fix Coverity bug CID-562. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 17:08:55.000000000 +0100 > @@ -4648,7 +4648,7 @@ > LPWSTR deformatted, ptr; > DWORD flags, type, size; > LONG res; > - HKEY env, root = HKEY_CURRENT_USER; > + HKEY env = NULL, root = HKEY_CURRENT_USER; > > static const WCHAR environment[] = > {'S','y','s','t','e','m','\\', > @@ -4759,7 +4759,7 @@ > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > done: > - RegCloseKey(env); > + if (env) RegCloseKey(env); > msi_free(deformatted); > msi_free(data); > msi_free(newval); > Please don't check env for NULL; RegCloseKey will just fail harmlessly if env is NULL. We spent a lot of time removing such checks. -- James Hawkins

4 3

Bugzilla mails and people replying to wine-bugs@winehq.com
by Tom Spear June 23, 2007

June 23, 2007

Just curious how trivial it would be to add a note to the bugzilla mail template saying to post replies to comments in the bug? Something like the following: A bug you are watching, Bug #(bug number), has a new comment. To reply to this comment, click (bug link). Then the rest of the email as it currently appears. I'm asking because I have received several replies to the list recently, and once wine reaches 1.0, I'm sure many more people will join the list and do the same. I don't want comments to be lost due to them not being posted in the proper place, as everyone's input on a bug is important. -- Thanks Tom

3 3

Wine on SkyOS
by Tom Wickline June 23, 2007

June 23, 2007

Hello All, Looks as if SkyOS will soon support Wine! Internals - Many kernel updates like LDT support (required by Wine), updated signal handling, pthread support, and overall additional POSIX compatibility enhancements. http://www.skyos.org/?q=node/605 Tom

3 2

Re: msi: Fix use of uninitialized variable (Coverity)
by Paul Vriens June 23, 2007

June 23, 2007

Andrew Talbot wrote: > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > Wouldn't it be easier to set env to NULL when declaring it and do a: if (env) RegCloseKey(env); Cheers, Paul.

2 1

RegOpenKeyExW() Question
by Andrew Talbot June 23, 2007

June 23, 2007

Hi, I want to patch msi:action.c:ITERATE_WriteEnvironmentString() so that it only calls RegCloseKey(env), in the cleanup, if "env" has been initialized (to fix Coverity report CID-562). I can bypass the call to RegCloseKey() for any early exit that occurs prior to calling RegOpenKeyExW(), and I can include the call to RegCloseKey() for exits that occur after a successful call to RegOpenKeyExW(). However, the problem, for me, is what to do if the call to RegOpenKeyExW() fails: does the occurrence of this initialization depend on the reason for failure. In other words, do I need something like the following code to cater for the reason failure occurred? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) if (res == ERROR_INVALID_HANDLE || res == RtlNtStatusToDosError(STATUS_BUFFER_OVERFLOW || res == RtlNtStatusToDosError(STATUS_INVALID_PARAMETER)) goto done2; else goto done1; ... done1: RegCloseKey(env); done2: ... Or will the following code suffice? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) goto done2; ... done1: RegCloseKey(env); done2: ... Thanks, -- Andy.

2 2

gdiplus: graphics tests [try2]
by Misha Koshelev June 22, 2007

June 22, 2007

> Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki: > > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote: > > > "Evan Stade" <estade at gmail.com> writes: > > > > +static const INT drawline_bmp1[192] = > > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf > > > >fffffff, > > > > > > I don't think we want to do that sort of thing. We can't guarantee > > > that the results will be exact pixel for pixel, and we don't really > > > care. And even if we did, hardcoding the image in the source this way > > > is unmaintainable. > > > > > > If you want to check the results, you should write an app that draws > > > various things and check it visually against Windows, but I don't > > > think that's something that can be part of the regression test suite. > > May I suggest something like enclosing your gdiplus function calls in a regression test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths created by your functions conform to those on native (you can take a look at what I am using right now in dlls/gdi/tests/path.c and some expansions here http://www.winehq.org/pipermail/wine-patches/2007-June/040679.html) I have found that it seems to be a good way to test at least the gdi functions without having to compare the visual result pixel by pixel while still being able to test the basic drawing primitives that are being used (btw you have to give the x&y coords +/- 1 or 2 when checking them b/c of floating point rounding diffs). The only downside for using this kind of framework would be that if anything changes in gdi32's path implementation it would affect your tests, but I think no matter what you do for a graphics regression tests for gdiplus changes in gdi32 would affect it. Just wanted to throw the idea out as I think a good conformance test is worth its weight in gold. Misha

2 2

Re: winealsa.drv: Fix missing unlock on the error path. Found by Smatch.
by Maarten Lankhorst June 22, 2007

June 22, 2007

That fix is correct, This->pcm is only ever changed inside the critical section Thanks, Maarten 2007/6/22, Michael Stefaniuc <mstefani(a)redhat.de>: > Maarten, > > is this the right fix or can the lock be moved below the > if (!This->pcm) > check? > > bye > michael > --- > dlls/winealsa.drv/dsoutput.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/winealsa.drv/dsoutput.c b/dlls/winealsa.drv/dsoutput.c > index 57b8968..9fc5020 100644 > --- a/dlls/winealsa.drv/dsoutput.c > +++ b/dlls/winealsa.drv/dsoutput.c > @@ -459,6 +459,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_GetPosition(PIDSDRIVERBUFFER iface, > if (!This->pcm) > { > FIXME("Bad pointer for pcm: %p\n", This->pcm); > + LeaveCriticalSection(&This->pcm_crst); > return DSERR_GENERIC; > } > > -- > 1.5.0.6 >

1 0

Failing assertion in dsound test, please confirm
by Alex Villacís Lasso June 22, 2007

June 22, 2007

I am experiencing a failing assertion in a dsound test. Could you please confirm if it is just me (and then it would be a configuration issue), or if anybody else is experiencing failing assertions: [alex(a)srv64 tests]$ WINETEST_INTERACTIVE=1 wine dsound_test.exe.so dsound ALSA lib conf.c:3939:(snd_config_expand) Unknown parameters 0 ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL default:0 fixme:wave:ALSA_AddCaptureDevice Add support for DSCapture dsound.c:973:DLL Version: 5.3.1.904 dsound.c:180:Testing IDirectSound fixme:dsalsa:SetFormat Your alsa dmix period size is excessively high, unfortunately this is alsa default, try decreasing it to 512 or 256 (but double the amount of periods) if possible fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x80004002 err:ole:CoGetClassObject class {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} not registered err:ole:CoGetClassObject no class object {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} could be created for context 0x1 dsound.c:938:*** Testing Primary Sound Driver - winealsa.drv *** dsound.c:475:Playing a 5 seconds reference tone at the current volume. dsound.c:478:(the current volume is -4651 according to DirectSound) dsound.c:480:All subsequent tones should be identical to this one. dsound.c:481:Listen for stutter, changes in pitch, volume, etc. ds3d.c:400:Requested format tag=0x0001 11025x16x2 avg.B/s=44100 align=4 ds3d.c:403:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 ds3d.c:453: Playing 5 second 440Hz tone at 48000x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x1 avg.B/s=8000 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x2 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x8x2 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x8x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x1 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x16x1 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x16x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x2 avg.B/s=32000 align=4 dsound.c:586:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 dsound.c:607: Testing a primary buffer at 48000x16x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 mixer.c:823: DSOUND_PerformMix: La declaración `device->playpos < device->buflen' no se cumple. wine: Assertion failed at address 0x600007f2 (thread 000f), starting debugger... dsound.c:582:Requested primary format tag=0x0001 11025x8x1 avg.B/s=11025 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 Unhandled exception: assertion failed in 32-bit code (0x600007f2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:600007f2 ESP:7ed516cc EBP:7ed516d8 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00002cd3 ECX:00002cd5 EDX:00000006 ESI:7ed51778 EDI:60298ff4 Stack dump: 0x7ed516cc: 60171fa0 60298ff4 7ed52b90 7ed51804 0x7ed516dc: 601738b1 00000006 7ed51778 00000000 0x7ed516ec: 00000068 7cae1278 00000000 00000000 0x7ed516fc: 601ae37d 7ed5173c 7cae1278 7cae12dc 0x7ed5170c: 7ed51814 60298ff4 00000062 7cae1278 0x7ed5171c: 7ed517e8 601a7d3b 7cae1278 00000062 Backtrace: =>1 0x600007f2 (0x7ed516d8) 2 0x601738b1 (0x7ed51804) 3 0x6016b3ce (0x7ed51848) 4 0x608bdfe8 DSOUND_timer+0x2108(timerID=0x1, msg=0x0, dwUser=0x167688, dw1=0x0, dw2=0x0) [/home/alex/install/wine-0.9.39-build/dlls/dsound/mixer.c:554] in dsound (0x7ed519b8) 5 0x60910b96 TIME_MMSysTimeThread+0x2e6(arg=0x0) [/home/alex/install/wine-0.9.39-build/dlls/winmm/time.c:181] in winmm (0x7ed51a18) 6 0x7bc5d19e call_thread_entry_point+0xe() in ntdll (0x7ed51a28) 7 0x7bc5de72 call_thread_func+0x42(rtl_func=<register EDI not in topmost frame>, arg=<register ESI not in topmost frame>) [/home/alex/install/wine-0.9.39-build/dlls/ntdll/thread.c:404] in ntdll (0x7ed51ac8) 8 0x7bc5e10f in ntdll (+0x4e10f) (0x7ed523c8) 9 0x601362fb (0x7ed524b8) 10 0x6021993e (0x00000000) 0x600007f2: ret Modules: Module Address Debug info Name (66 modules) ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 43e000- 45b000 Deferred ld-linux.so.2 ELF 45d000- 5b1000 Deferred libc.so.6 ELF 5b3000- 5dc000 Deferred libm.so.6 ELF 5de000- 5e3000 Deferred libdl.so.2 ELF 5fa000- 612000 Deferred libpthread.so.0 ELF 614000- 619000 Deferred libxxf86vm.so.1 ELF 640000- 645000 Deferred libxfixes.so.3 ELF 6b5000- 6bb000 Deferred libxdmcp.so.6 ELF 6bd000- 7bf000 Deferred libx11.so.6 ELF 802000- 805000 Deferred libxau.so.6 ELF 80c000- 81c000 Deferred libxext.so.6 ELF 8aa000- 8cb000 Deferred libexpat.so.0 ELF 926000- 92f000 Deferred libxrender.so.1 ELF a84000- a8e000 Deferred libxcursor.so.1 ELF a98000- b22000 Deferred libfreetype.so.6 ELF b24000- b53000 Deferred libfontconfig.so.1 ELF bbb000- bc6000 Deferred libdrm.so.2 ELF cef000- cf6000 Deferred libxrandr.so.2 ELF dfa000- dfd000 Deferred libxinerama.so.1 ELF 5cf0000- 5dce000 Deferred libasound.so.2 ELF 65f6000- 65ff000 Deferred libsm.so.6 ELF 6601000- 661b000 Deferred libice.so.6 ELF 6001d000-60131000 Deferred libwine.so.1 ELF 602cb000-6032b000 Deferred dsound_test<elf> \-PE 602e0000-6032b000 \ dsound_test ELF 6032b000-60371000 Deferred advapi32<elf> \-PE 60340000-60371000 \ advapi32 ELF 60371000-604ab000 Deferred user32<elf> \-PE 60390000-604ab000 \ user32 ELF 604ab000-60541000 Deferred gdi32<elf> \-PE 604c0000-60541000 \ gdi32 ELF 60541000-60597000 Deferred rpcrt4<elf> \-PE 60550000-60597000 \ rpcrt4 ELF 60597000-605b5000 Deferred iphlpapi<elf> \-PE 605a0000-605b5000 \ iphlpapi ELF 605c9000-605e2000 Deferred version<elf> \-PE 605d0000-605e2000 \ version ELF 60892000-608db000 Dwarf dsound<elf> \-PE 608a0000-608db000 \ dsound ELF 608db000-60968000 Dwarf winmm<elf> \-PE 608f0000-60968000 \ winmm ELF 60a46000-60a5e000 Deferred msacm32<elf> \-PE 60a50000-60a5e000 \ msacm32 ELF 60a5e000-60a84000 Deferred msacm32<elf> \-PE 60a70000-60a84000 \ msacm32 ELF 61d5f000-61d74000 Deferred midimap<elf> \-PE 61d70000-61d74000 \ midimap ELF 6a741000-6a74d000 Deferred libnss_files.so.2 ELF 6d8a4000-6d8d6000 Deferred winealsa<elf> \-PE 6d8b0000-6d8d6000 \ winealsa ELF 7525e000-752ec000 Deferred winex11<elf> \-PE 75270000-752ec000 \ winex11 ELF 757d6000-757ea000 Deferred lz32<elf> \-PE 757e0000-757ea000 \ lz32 ELF 77861000-7787e000 Deferred imm32<elf> \-PE 77870000-7787e000 \ imm32 ELF 79cd4000-79cd7000 Deferred iso8859-1.so ELF 79d6e000-79e0b000 Deferred ole32<elf> \-PE 79d80000-79e0b000 \ ole32 ELF 7b800000-7b924000 Deferred kernel32<elf> \-PE 7b820000-7b924000 \ kernel32 ELF 7bc00000-7bc96000 Dwarf ntdll<elf> \-PE 7bc10000-7bc96000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000010 00000012 0 00000011 0 0000000d (D) Z:\home\alex\install\wine-0.9.39-build\dlls\dsound\tests\dsound_test.exe 0000000f 15 <== 0000000e 0 -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1

Re: How to make your machine crash when running Wine
by gslink June 22, 2007

June 22, 2007

Most of the people here are probably smarter than to fall into this trap but I recently had several customers who did. Most of the time openGL just refuses to run but a couple of months ago RH did put out an update to some of the X code that did cause the machine to crash with Wine if you didn't replace the Nvidia driver. The customers were running some things under Wine that used hardware acceleration. If they had used hardware acceleration outside of Wine the machine would have crashed too. This is not a Wine problem but it is likely to be a source of regular complaints.

1 0

Re: dpnhpast: Add stub for DirectPlayNATHelpCreate
by Detlef Riekenberg June 22, 2007

June 22, 2007

On Fr, 2007-06-22 at 04:39 +0200, Alexander Nicolaysen Sørnes wrote: > +HRESULT WINAPI DirectPlayNATHelpCreate(const LPGUID pIId, void ** > ppvInterface) > { > - /* @stub in .spec */ > + FIXME("stub"); > + return E_FAIL; > } > -#endif The FIXME is missing the newline and it would be useful to dump the Parameters in the FIXME. -- By by ... Detlef

1 0

Re: [3/7] gdiplus: GdipReAlloc
by Alexandre Julliard June 22, 2007

June 22, 2007

"Evan Stade" <estade(a)gmail.com> writes: > This is only declared privately because it is not a function provided > by the dll. It follows the exported-function naming scheme however, > because it's a counterpart to GdipFree and GdipAlloc. Please don't do that, it's confusing. If there's no GdipReAlloc just use HeapReAlloc directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: [1/2] oleaut32: add PNG loading [try2]
by Dan Kegel June 22, 2007

June 22, 2007

Alexandre wrote: >> How can I improve this patch such that it will be accepted? > >The biggest problem is that the libpng versioning scheme is broken, so >we can't find the proper soname. This will need some more configure >magic. Looking at http://www.libpng.org/pub/png/libpng.html and http://www.linux-foundation.org/en/LibPng and /usr/include/png.h I get the impression that the libpng versioning scheme was cleaned up for the 1.2 series over four years ago. So perhaps we could just change configure.ac to check PNG_LIBPNG_VER_MAJOR and make sure it's exactly 1, and check PNG_LIBPNG_VER_MINOR and make sure it's 2 or greater. That would let us avoid the old broken libpng's, wouldn't it? - Dan

2 1

Re: [PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.
by Alexandre Julliard June 22, 2007

June 22, 2007

Misha Koshelev <mk144210(a)bcm.edu> writes: > This sends proper position information to the GDI driver when we are emulating these functions. I don't think I agree with this one. If the driver needs to update the position then it should implement ArcTo etc. since it may need to distinguish that from an explicit MoveTo. Or if the generic implementation is really good enough in all cases then we shouldn't export a driver entry point at all. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: PATCH - implement LockWorkStation using xdg-screensaver on Linux
by Hans Leidekker June 21, 2007

June 21, 2007

On Tuesday 19 June 2007 20:08:50 Steven Edwards wrote: > Patch by Hans Leidekker It's your idea so you should get the credit. I was just helping out with the implementation. > This could be expanded for other platforms that use xdg stuff by > changing the #ifdef. I added the #ifdef to also deal with the MacOS > case. There will allways be Linux distributions that don't install the xdg tools by default, and it's not inconceivable that they will be supported on MacOS one day. So I think it's better to just try to run xdg-screensaver, warn when it fails, but ignore the error. From reading MSDN this is consistent with the semantics of LockWorkStation. I also think it's better to not lock the entire desktop when Wine runs in a virtual desktop. I remember looking for a way to know whether we are running in desktop mode and found this snippet from PaintDesktop(): HWND hwnd = GetDesktopWindow(); /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ if (GetWindowThreadProcessId( hwnd, NULL )) ... I copied it but somehow it didn't work for me. -Hans

5 5

re: NULL ptr dereferences found with Calysto static checker
by Dan Kegel June 21, 2007

June 21, 2007

Domagoj wrote: > I've ran my static checker Calysto on Wine v0.9.35 and got > 78 bug reports:... > If you are interested in the reports, please: > 1) read > http://www.cs.ubc.ca/~babic/index_calysto_community.htm > 2) if the conditions are acceptable, let me know where to > send the reports. The conditions look very minimal, we should be fine with them. A check once a month should be fine. Just send the results to wine-devel(a)winehq.org. (There's some chance we'll ask you to switch to sending them somewhere else, but that will do initially.) For the moment just put the calysto.org link in the mail. Once it's clear the results are useful, somebody will link to calysto at least from our wiki. Say, whatever happened to Coverity's scans of Wine? I just logged in to the Wine results at http://scan.coverity.com, and the last scan seems to have been last July. Did they set up a new, private site for us? Paul V., do you know? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

9 11

Coverity status
by Paul Vriens June 21, 2007

June 21, 2007

Hi, I've been in contact with Coverity. People currently listed as Wine contacts are: - Jan Zerebecki - Paul Vriens The main page is changed so it reflects the new scan site http://scan2.coverity.com:7479 and there has just been a new run! Coverity is very busy setting up some proper communication channels and some means for the contacts to do some kind of user administration (limited of course). Apart from that a lot of the current manual tasks will be automated (like the counters on the page where Wine is listed http://scan.coverity.com/rung1.html) Cheers, Paul.

1 0

Re: winmm: Specify the arguments of the function in the function pointer
by Alexandre Julliard June 21, 2007

June 21, 2007

Michael Stefaniuc <mstefani(a)redhat.de> writes: > @@ -114,10 +114,10 @@ static BOOL MMDRV_GetDescription32(const char* fname, char* buf, int buflen) > DWORD dw; > BOOL ret = FALSE; > UINT u; > - FARPROC pGetFileVersionInfoSizeA; > - FARPROC pGetFileVersionInfoA; > - FARPROC pVerQueryValueA; > - HMODULE hmodule = 0; > + DWORD (WINAPI *pGetFileVersionInfoSizeA)(LPCSTR,LPDWORD); > + BOOL (WINAPI *pGetFileVersionInfoA)(LPCSTR,DWORD,DWORD,LPVOID); > + BOOL (WINAPI *pVerQueryValueA)(LPCVOID,LPCSTR,LPVOID*,UINT*); > + HMODULE hmodule = 0; It may have been done that way because local WINAPI pointers crash on old versions of gcc. But that whole function should probably be removed, dumping version info doesn't belong in winmm. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] oleaut32: add PNG loading [try2]
by Evan Stade June 21, 2007

June 21, 2007

On 6/19/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > Try2: This time the rowsize is correctly aligned (on 4-byte > boundaries) and palette-mode PNGs are allowed as well as RGB-mode > PNGs. > > Changelog: > *added support to decode some PNG files > *added check for png.h / dynamic loading of libpng.so > > configure.ac | 2 > dlls/oleaut32/olepicture.c | 205 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 207 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Hi, How can I improve this patch such that it will be accepted? -- Evan Stade

2 1

Re: shell32: Make SHGetDesktopFolder use a cached instance of IShellFolder
by Alexandre Julliard June 21, 2007

June 21, 2007

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > + sf = LocalAlloc( LMEM_ZEROINIT, sizeof (IGenericSFImpl) ); > + if (!sf) > + return E_OUTOFMEMORY; > + > + if (InterlockedCompareExchangePointer((void *)&cached_sf, sf, NULL) != NULL) > + LocalFree( sf ); /* some other thread already been here */ > + else > + { > + sf->ref = 0; > + sf->lpVtbl = &vt_MCFldr_ShellFolder2; > + sf->pidlRoot = _ILCreateDesktop(); /* my qualified pidl */ > + sf->sPathTarget = SHAlloc( (lstrlenW(szMyPath) + 1)*sizeof(WCHAR) ); > + lstrcpyW( sf->sPathTarget, szMyPath ); > + } > + } You need to initialize the object completely before storing it as cached entry. -- Alexandre Julliard julliard(a)winehq.org

1 0

ntdll: Constify some variables (1 of 2)
by Andrew Talbot June 21, 2007

June 21, 2007

Please ignore this patch. Thanks, -- Andy.

1 0

Re: [kernel32][tests] Add test for GetShortPathNameW
by Dmitry Timoshkov June 21, 2007

June 21, 2007

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > + WCHAR PROG_FILES_DIR[MAX_PATH]; Looks like that this variable is not used anywhere. > static DWORD (WINAPI *pGetLongPathNameA)(LPCSTR,LPSTR,DWORD); > static DWORD (WINAPI *pGetLongPathNameW)(LPWSTR,LPWSTR,DWORD); > +static DWORD (WINAPI *pGetShortPathNameW)(LPWSTR,LPWSTR,DWORD); I don't see where pGetShortPathNameW is initialized. > + file = CreateFileW(short_path, GENERIC_READ|GENERIC_WRITE, 0, > + NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); > + ok(file != INVALID_HANDLE_VALUE, "File was not created.\n"); > + ret = WriteFile(file, "test", strlen("test"), NULL, NULL); > + ok(ret, "Can not open file!!\n"); The error message in ok() is not correct. > + CloseHandle(file); > + ret = DeleteFileW(short_path); > + ok(ret, "Can not delete file.\n"); > + GetTempPathW(MAX_PATH, path); > + lstrcatW(path, src); > + lstrcatW(path, backSlash); > + ret = RemoveDirectoryW(path); 'path' at this point already contains what you need, calling GetTempPathW and friends is not needed, and that would simplify the code a bit. > +static void test_GetShortPathNameW(void) > +{ > + WCHAR empty[MAX_PATH]; > + WCHAR pathE[] = {'p','a','t','h','t','e','s','t',0}; > + WCHAR pathRL[] = {0x0414,0x043B,0x0438,0x043D,0x043D,0x043E,0x0435,0x0418,0x043C,0x044F,0}; /* Long Russian name > */ > + WCHAR pathRS[] = {0x0418,0x043C,0x044F,0}; /* Short Russian name */ Do you really need the test to use cyrillic characters? That won't work if underlying unix locale is not russian regardless what you set the thread locale to. > + /* Not present in all windows versions */ > + if(pGetShortPathNameW) > + { > + SetLastError(0xdeadbeef); > + length = pGetShortPathNameW(NULL,NULL,0); > + if(GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + { > + skip("GetShortPathNameW is not implemented\n"); > + return; > + } Indentation inside of 'if(pGetShortPathNameW)' is completely messed up. -- Dmitry.

2 2

Re: [kernel32][tests] Add test for GetShortPathNameW
by Detlef Riekenberg June 20, 2007

June 20, 2007

On Di, 2007-06-19 at 13:18 +0400, Anatoly Lyutin wrote: > + { > + SetLastError(0xdeadbeef); > + length = pGetShortPathNameW(NULL,NULL,0); > + if(GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + { > + skip("GetShortPathNameW is not implemented\n"); > + return; Your indention looks wired -- By by ... Detlef

1 0

NULL ptr dereferences found with Calysto static checker
by Domagoj Babic June 20, 2007

June 20, 2007

Hi, I've ran my static checker Calysto on Wine v0.9.35 and got 78 bug reports: makedep: 1 sfnt2fnt: 4 winebuild: 6 winedump: 2 winegcc: 5 libwine: 60 If you are interested in the reports, please: 1) read http://www.cs.ubc.ca/~babic/index_calysto_community.htm 2) if the conditions are acceptable, let me know where to send the reports. Kind regards, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

1 0

On stuttering audio in quartz/DirectShow
by Alex Villacís Lasso June 20, 2007

June 20, 2007

Upon checking the source code of dlls/quartz I found out about the method SetSyncSource defined in the IBaseFilter interface: dsoundrender.c:static HRESULT WINAPI DSoundRender_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filesource.c:static HRESULT WINAPI AsyncReader_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filtergraph.c:static HRESULT WINAPI MediaFilter_SetSyncSource(IMediaFilter *iface, IReferenceClock *pClock) parser.c:static HRESULT WINAPI Parser_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) transform.c:static HRESULT WINAPI TransformFilter_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) videorenderer.c:static HRESULT WINAPI VideoRenderer_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) In particular, I see the following two things about sync sources: 1) I see no effort on part of filtergraph.c to add a sync source when simply asked to render a file 2) Even if it did, current implementation of videorenderer.c does nothing with its sync source So I have a couple of questions: 1) Am I right to assume that a sync source might be used to synchronize and (if necessary) drop frames at the videorenderer in order to maintain synchronization and avoid stuttering? 2) Could the sttutering really be solved by implementing the using and passing of a synchronization source (systemclock.c) in file rendering? If so, then the migration to DirectDraw would become just an optimization to increase the frame rate. Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1