- wine-devel - winehq.org

Dockable Toolbar painting issue on SUSE 9.1
by Krishna Murthy 10 Aug '04

10 Aug '04

I am facing the following issue on SUSe pro 9.1, but this issue is not happening on RH 9.1. - The MFC application has the dockable toolbar - When I undock the toolbar to display ad popup window, the screen is not refreshed and when I see the trace, the X11DRV_SetWindowPos() is called ininitely. - Any one faced this issue? - Could you please point me to the wine code source files related to toolbar / dockable controls so that I could debug where the problem is occurring. The SUSe pro 9.1 has the follwoing library versions: XFree86-fonts-scalable-4.3.99.902-40 XFree86-libs-4.3.99.902-40 XFree86-Mesa-devel-4.3.99.902-40 XFree86-fonts-75dpi-4.3.99.902-40 XFree86-4.3.99.902-43.25 XFree86-Mesa-4.3.99.902-40 XFree86-devel-4.3.99.902-40 XFree86-server-glx-4.3.99.902-40 XFree86-server-4.3.99.902-43.25 XFree86-Xvnc-4.3.99.902-40 kdebase3-SuSE-9.1-18.1 kdebase3-3.2.1-68.15 Thanks in advance, Krishna Murthy Gupta Technologies LLC TEL: (650) 596-4828 E-mail: Krishna.Murthy(a)guptaworldwide.com

1 1

RE: Wine devel: Two MFC bugs
by Green, Shaun E. 10 Aug '04

10 Aug '04

>This is a known problem. Our edit control does not currently support the ES_RIGHT style at this time. Okay, thanks for letting me know. > The second bug is that when I multi-select files to perform an > operation on, nothing happens. One selected file works fine, but any > additional ones cause nothing to happen. Works fine in Windows. >What control are you using for the multi-select? ofn.Flags = OFN_ALLOWMULTISELECT | OFN_HIDEREADONLY | OFN_FILEMUSTEXIST | OFN_EXPLORER ; Here is the dialog code; szFileName[0] = '\0'; OPENFILENAME ofn; ofn.lStructSize = sizeof (OPENFILENAME); ofn.hwndOwner = this->m_hWnd; ofn.hInstance = NULL; #if _LANGUAGE==FRENCH ofn.lpstrFilter = "Fichiers TXT\0*.txt\0\0"; #elif _LANGUAGE==ENGLISH ofn.lpstrFilter = "txt (*.txt)\0*.txt\0\0"; #endif ofn.lpstrCustomFilter = NULL; ofn.nMaxCustFilter = 0; ofn.nFilterIndex = 0; ofn.lpstrFile = szFileName; ofn.nMaxFile = _MAX_PATH+50000; ofn.lpstrFileTitle = NULL; ofn.nMaxFileTitle = 0; ofn.lpstrInitialDir = pDoc->repertoire; ofn.lpstrTitle = NULL; ofn.Flags = OFN_ALLOWMULTISELECT | OFN_HIDEREADONLY | OFN_FILEMUSTEXIST | OFN_EXPLORER ; ofn.nFileOffset = 0; ofn.nFileExtension = 0; ofn.lpstrDefExt = NULL; #ifdef _DEBUG ofn.lCustData = 1L; #else ofn.lCustData = 0L; #endif ofn.lpfnHook = NULL; ofn.lpTemplateName = NULL; if (GetOpenFileName (&ofn)) { Thanks, Shaun

2 1

Incoming message
by Prupe 10 Aug '04

10 Aug '04

1 0

Wine devel: Two MFC bugs
by Green, Shaun E. 10 Aug '04

10 Aug '04

I would like to first thank all the Wine developers for your help. Without you, this wonderful software would not be maintained and allow good cross-platform app development. Several months ago I received some help from the list on an MFC application I'm helping develop. Now that I've completed sokoban version 1.3, I'm ready to report only two bugs I've found with the latest Wine 20040716, running the sokoban.exe in Linux. The first is a display problem of edit boxes; for some reason the text (numbers) are displaying left justified, instead of right justified. The edit boxes are definitely set for right justified and display fine in Windows. The second bug is that when I multi-select files to perform an operation on, nothing happens. One selected file works fine, but any additional ones cause nothing to happen. Works fine in Windows. For both of these problems I'd be happy to provide the MFC/C++ code snippets, just let me know. Thanks, Shaun

2 1

(no subject)
by Dpaun 10 Aug '04

10 Aug '04

1 0

Re: Wine devel: Two MFC bugs
by Dan Kegel 10 Aug '04

10 Aug '04

Shaun Green wrote: > The first is a display problem of edit boxes; for some reason the text > (numbers) are displaying left justified, instead of right justified. The > edit boxes are definitely set for right justified and display fine in > Windows. > > The second bug is that when I multi-select files to perform an operation on, > nothing happens. One selected file works fine, but any additional ones cause > nothing to happen. Works fine in Windows. > > For both of these problems I'd be happy to provide the MFC/C++ code > snippets, just let me know. Please do. Ideally, you should file a separate bug in Wine's bugzilla (http://bugs.winehq.org/) for each of the two problems, and attach or link to a zip file of an MSVC project plus source code and executable of the small test case. (Like I did in bug http://bugs.winehq.org/show_bug.cgi?id=1404 ) Thanks, Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Winelib under Solaris/SPARC
by Robin KAY 10 Aug '04

10 Aug '04

I would to like compile Winelib under Solaris/SPARC so that I can develop Windows applications from the relative comfort of UNIX, leaving only the final building and testing to real Windows running under Bochs. I have tested a selection of Wine releases and the build typically fails with either one of two errors. I used gcc 3.3.4 with the assembler and linker from binutils 2.15, and I configured the builds with: LDFLAGS="-R/opt/csw/lib -L/opt/csw/lib" CPPFLAGS="-I/opt/csw/include" ./configure --without-opengl 1) Releases between wine-20021125 and wine-20040121 (inclusive) gcc -c -I. -I. -I../../include -I../../include -I/usr/openwin/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/csw/include -g -O2 -o ddraw.spec.o ddraw.spec.c {standard input}: Assembler messages: {standard input}:1169: Error: operation combines symbols in different segments [snip] {standard input}:2006: Error: operation combines symbols in different segments gmake[2]: *** [ddraw.spec.o] Error 1 An archived mailing list post suggested that this is caused by a failure to RTFM and configure the source tree to build winelib rather than plain wine with PE loader, however I haven't been able to find any documentation that supports this view. None of the releases I tested had a configure script which accepted --disable-emulator. The source file which causes this error varies with release. 2) Releases between wine-20040213 and wine-20040716 (inclusive) ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o error.o exception.o file.o heap.o large_int.o loader.o loadorder.o misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o wcstring.o relay32.o ntdll.dll.dbg.o -o ntdll.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -R/opt/csw/lib -L/opt/csw/lib -lresolv -lsocket -lnsl ntdll.dll-DqmZVz.spec.c:20:1: warning: "__stdcall" redefined <command line>:17:1: warning: this is the location of the previous definition thread.o(.text+0xc1c): In function `NtCurrentTeb': /home/komadori/dev/stuff/wine-20040716/dlls/ntdll/thread.c:582: undefined reference to `wine_pthread_get_current_teb' collect2: ld returned 1 exit status winegcc: gcc failed. gmake[2]: *** [ntdll.dll.so] Error 2 I tried adding wine_pthread_get_current_teb to libs/wine/wine.def and libs/wine/wine.map, but this caused the resulting binaries to dereference a bad address in NtCurrentTeb. This mail was origianally posted to comp.emulators.ms-windows.wine from where I was redirectled. Does anyone know how to fix these problems or if any of the older release tags in CVS will build under Solaris/SPARC? Thanks. -- Wishing you good fortune, --Robin Kay-- (komadori)

2 2

Problem with ITypeInfo
by jack 10 Aug '04

10 Aug '04

Hi. I've tryed to run game Project Entropia and I got segmentation fault because of a bug in OLE. I've hacked code and I found two bugs: 1. ITypeInfo has back pointer to ITypeLib, but it's possible (and happened) that ITypeLib is destroyed and later ITypeInfo calls its function. I've solve this problem by call ITypeLib_AddRef while creating ITypeInfo (and ITypeLib_Release while destroying ITypeInfo). 2. ITypeInfo_Invoke doesn't support optional parameters. I've added support for cParamsOpt>0. MSDN says that optional parameter is when VARTYPE equals VT_EMPTY, but in my case it was a VT_BYREF | VT_VARIANT type but the pointer was NULL. When I treated it as VT_EMPTY, it was OK. I enclose my patch. My knownlage about OLE is sparse so I'm not able to test this. Thanks, Jacek

3 4

Re: Add a linker rpath so libwine can be found without modifying ld.so.conf or LD_LIBRARY_PATH
by Alexandre Julliard 09 Aug '04

09 Aug '04

Mike Hearn <mike(a)navi.cx> writes: > --- Make.rules.in.~1.172.~ 2004-03-24 03:34:01.000000000 +0000 > +++ Make.rules.in 2004-08-02 22:57:38.868759456 +0100 > @@ -78,6 +78,7 @@ > LIBPORT = -L$(TOPOBJDIR)/libs/port -lwine_port > LIBUNICODE = -L$(TOPOBJDIR)/libs/unicode -lwine_unicode > LIBWINE = -L$(TOPOBJDIR)/libs/wine -lwine > +RPATH = -Wl,-rpath,'$${ORIGIN}/../lib' You cannot depend on libdir being ../lib, users can specify a different one. -- Alexandre Julliard julliard(a)winehq.org

1 0

CVS build fails
by Ivan Leo Puoti 09 Aug '04

09 Aug '04

Current CVS build fails. make[3]: Entering directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/tests' gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o mixer.o mixer.c mixer.c: In function `mixer_test_deviceA': mixer.c:353: error: union has no member named `s1' mixer.c:354: error: union has no member named `s1' mixer.c: In function `mixer_test_deviceW': mixer.c:570: error: union has no member named `s1' mixer.c:571: error: union has no member named `s1' make[3]: *** [mixer.o] Error 1 make[3]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm/tests' make[2]: *** [tests] Error 2 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/winmm' make[1]: *** [winmm] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls' make: *** [dlls] Error 2 [ivan@localhost wine]$ Ivan.

1 0

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings
by Dmitry Timoshkov 09 Aug '04

09 Aug '04

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > +static const int size_of_wchar = sizeof(WCHAR); > + ... > - ok(!memcmp(bufW, stringW, 5 * sizeof(WCHAR)), "bufW/stringW mismatch\n"); > + ok(!memcmp(bufW, stringW, 5 * size_of_wchar), "bufW/stringW mismatch\n"); > - if (GetLastError()==NTE_BAD_KEYSET) > + LONG gle = GetLastError(); > + if (gle==NTE_BAD_KEYSET) This is ugly. This kind of "fixes" clutters Wine code and should be deprecated. -- Dmitry.

3 4

rsabase and itunes
by Michael Jung 09 Aug '04

09 Aug '04

Rob, I've seen the press release concerning the CrossOver Office iTunes preview and I've noticed that it depends on libcrypto. Im just wondering if your effort with rsabase is related to this? Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

2 1

"Call Identifier" -- MSRPC ??
by Auge Mike 09 Aug '04

09 Aug '04

Hi all, I really like to know hot to change the "call identifier" in a MSRPC call??? Please help me, I already wasted too long time searching for this info with no luck??? Thank you in advance!!! _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

Re: Add debugstr_rect alias for consistency with other debugging functions.
by Alexandre Julliard 08 Aug '04

08 Aug '04

Mike Hearn <mike(a)navi.cx> writes: > The lack of this confused me for a few minutes, might as well stick it in. It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: Fix crash in dsound test
by Ferenc Wagner 08 Aug '04

08 Aug '04

Paul Millar <paulm(a)astro.gla.ac.uk> writes: > The build failed. It looks like there's a bug in CVS. Both > CLSID_DirectSoundPrivate and DSPROPSETID_DirectSoundDevice defined multiple > times (the wine-version of mingw libraries and in the source). Yes, there was a short discussion about this on 23-24 July on wine-devel. It reached no conclusion, though, and I didn't try the various MinGW libraries recommended there. The abundance of MinGW packages always confused me, and at the moment I don't even know where I got mine from. But it can't compile the dsound tests, that's for sure. Comments welcome. -- Feri.

2 1

Re: patch: shell32.dll - SHELL_ArgifyW expands env-vars
by Steven Edwards 08 Aug '04

08 Aug '04

Hi Jens, --- Jens Collin <jens.collin(a)lakhei.com> wrote: > * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. > (Such as %SystemRoot%). Do you think you could write some test cases for the shellexecute functions using the wine regression tests? I would like to try and merge the rest of shell32 in to ReactOS but am worried that we may overwrite fixes Martin made in the ReactOS tree. Thanks Steven __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com

2 1

Wine's OLE/COM doesn't work, and I can no longer use native COM
by David D. Hagood 08 Aug '04

08 Aug '04

One of the few Windows programs I use is Delorme's MapNGo (versions 4 and 6). Under older versions of Wine wherein I could use the native Windows OLE/COM implementation it worked fairly well, but with the new Wine it does not. The symptoms are that the program cannot create the initial document object - this ususally is an indication that the DLLS implementing the COM classes for the MapNGo object are not registered correctly with the system. However, I have taken a system running an older version of Wine that could successfully run Mng6 and upgraded it to the latest CVS of Wine, and it broke the app. Not being a wiz at COM, I am not sure where to go from here, other than to report the results of tracing the run: WINDEBUG=+ole,+com wine ./Mng6 fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr@surfer AAAMNG6]$ [wowbaggr@surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./Mng6.mdb wine: cannot determine executable type for L"D:\\AAAMNG6\\Mng6.mdb" [wowbaggr@surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./mng mng6.cnt mng6.exe mng6.hlp mngfeat.hlp [wowbaggr@surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./mng6.exe fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr@surfer AAAMNG6]$ [wowbaggr@surfer AAAMNG6]$ WINDEBUG=+all wine ./mng6.exe fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr@surfer AAAMNG6]$ [wowbaggr@surfer AAAMNG6]$ WINEDEBUG=+ole,+com wine ./mng6.exe trace:ole:DllMain 0x40c00000 0x1 0x1 trace:ole:DllMain (0x40e30000,1,0x1) trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize () trace:ole:OleInitialize ((nil)) trace:ole:CoInitializeEx ((nil), 2) trace:ole:OleInitialize () - Initializing the OLE libraries trace:ole:OLEClipbrd_Initialize () fixme:ole:CoRegisterMessageFilter stub trace:ole:WINE_StringFromCLSID 0x49d964->{F4B4E540-7F32-11CE-AC56-0000C0496D91} trace:ole:WINE_StringFromCLSID 0x487530->{D97A6266-C342-11D2-A562-A313798CEB30} trace:ole:WINE_StringFromCLSID 0x4071f3bc->{D97A6266-C342-11D2-A562-A313798CEB30} trace:ole:CoGetClassObject CLSID: {d97a6266-c342-11d2-a562-a313798ceb30}, IID: {b196b28f-bab4-101a-b69c-00aa00341d07} trace:ole:COMPOBJ_DLLList_Add trace:ole:CoInitializeEx ((nil), 2) trace:ole:WINE_StringFromCLSID 0x5f8a41b8->{00025E15-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00025e15-0000-0000-c000-000000000046}, IID: {b196b28f-bab4-101a-b69c-00aa00341d07} trace:ole:COMPOBJ_DLLList_Add trace:ole:CreateErrorInfo (0x4071f38c): stub: trace:ole:IErrorInfoImpl_QueryInterface (0x40252658)->( IID: {22f03340-547d-101b-8e65-08002b2bd119},0x4071f38c) trace:ole:ICreateErrorInfoImpl_AddRef (0x40252658) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=1) trace:ole:IErrorInfoImpl_QueryInterface -- Interface: (0x4071f38c)->(0x4025265c)trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=2) trace:ole:ICreateErrorInfoImpl_QueryInterface (0x40252658) trace:ole:IErrorInfoImpl_QueryInterface (0x40252658)->( IID: {1cf2b120-547d-101b-8e65-08002b2bd119},0x4071f390) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=1) trace:ole:IErrorInfoImpl_QueryInterface -- Interface: (0x4071f390)->(0x40252658)trace:ole:ICreateErrorInfoImpl_SetGUID (0x40252658)->({00000000-0000-0000-0000-000000000000}) trace:ole:ICreateErrorInfoImpl_SetSource (0x40252658) trace:ole:ICreateErrorInfoImpl_SetDescription (0x40252658) trace:ole:ICreateErrorInfoImpl_SetHelpContext (0x40252658) trace:ole:SetErrorInfo (0, 0x40252658) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=2) trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=3) trace:ole:ICreateErrorInfoImpl_Release (0x40252658) trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=2) err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! (this last message usually happens when Mng tries to show an error dialog at startup.) When I've tried re-installing Mng6, I get messages from Wine about "Registering a non-oleautomation interface" - I do not know if this is significant or not. So, any pointers on where to go from here?

2 5

Re: Take monospace fonts into account in default font selectionalgorithm.
by Alexandre Julliard 07 Aug '04

07 Aug '04

Mike Hearn <mike(a)navi.cx> writes: > On Sat, 2004-08-07 at 23:16 +0900, Dmitry Timoshkov wrote: >> This can't work because instead of logical boolean results you compare >> binary flags which are different: >> >> #define FT_FACE_FLAG_FIXED_WIDTH ( 1L << 2 ) >> >> #define MONO_FONT 0x08 > > You are right. I will watch out for this in future! Here is a fixed > patch. The correct way to compare booleans in C is to invert them, i.e. instead of (a == b) use (!a == !b). You must not rely on booleans being always 0 or 1. -- Alexandre Julliard julliard(a)winehq.org

1 0

make crosstest fails
by Stefan Leichter 07 Aug '04

07 Aug '04

Hello, building cross tests of current cvs fails for me with: i386-mingw32-gcc capture.cross.o ds3d.cross.o dsound.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -lole32 -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 /usr/local/lib/gcc-lib/i386-mingw32/3.2.3/../../../../i386-mingw32/lib/ libdxguid.a(dxguid.o)(.text+0x570):/usr/src/packages/BUILD/mingw-3.2/ w32api-2.5/lib/directx/dxguid.c: multiple definition of `CLSID_DirectSoundPrivate' propset.cross.o(.text+0x0):propset.c: first defined here /usr/local/lib/gcc-lib/i386-mingw32/3.2.3/../../../../i386-mingw32/lib/ libdxguid.a(dxguid.o)(.text+0x580):/usr/src/packages/BUILD/mingw-3.2/ w32api-2.5/lib/directx/dxguid.c: multiple definition of `DSPROPSETID_DirectSoundDevice' propset.cross.o(.text+0x10):propset.c: first defined here make[3]: *** [dsound_crosstest.exe] Fehler 1 make[3]: Leaving directory `/usr/src/wine/wine-mingw/dlls/dsound/tests' make[2]: *** [tests/__crosstest__] Fehler 2 make[2]: Leaving directory `/usr/src/wine/wine-mingw/dlls/dsound' make[1]: *** [dsound/__crosstest__] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-mingw/dlls' make: *** [dlls/__crosstest__] Fehler 2 Bye Stefan

4 3

DOOM 3 misses some opengl32 wgl* and Cg functions
by Dr. Uwe Girlich 07 Aug '04

07 Aug '04

Hello all! I just tested out DOOM 3 (no-cd-cracked version) with the current Wine (CVS from 1 hour ago) and found the following problems on the game console: Couldn't find proc address for: wglSwapIntervalEXT Couldn't find proc address for: wglGetPixelFormatAttribivARB Couldn't find proc address for: wglGetPixelFormatAttribfvARB Couldn't find proc address for: wglChoosePixelFormatARB Couldn't find proc address for: wglCreatePbufferARB Couldn't find proc address for: wglGetPbufferDCARB Couldn't find proc address for: wglReleasePbufferDCARB Couldn't find proc address for: wglDestroyPbufferARB Couldn't find proc address for: wglQueryPbufferARB Couldn't find proc address for: wglBindTexImageARB Couldn't find proc address for: wglReleaseTexImageARB Couldn't find proc address for: wglSetPbufferAttribARB GL_ARB_texture_non_power_of_two not found GL_ATI_fragment_shader not found (this is expected, I have a nvidia card) Cg not available. Are these wgl* function difficult to implement? Almost all computer terminals in the game show static black & white noise (instead of some animated computer screen image). I suspect, that this has something to do with the missing 'Cg' support in Wine (DOOM3 cannot find cg.dll & cgGL.dll). On the other hand, the rendering paths (r_renderer nv10, nv20, arb, and arb2) are all more or less working (besides the noise and the too bright lighting in nv10). BTW, DOOM 3 crashes at program start in Cedega, you made it better! Bye, Uwe

7 7

Re: Take monospace fonts into account in default font selectionalgorithm.
by Dmitry Timoshkov 07 Aug '04

07 Aug '04

"Mike Hearn" <mike(a)navi.cx> wrote: > + (*insertface)->fixed_width = ft_face->face_flags & FT_FACE_FLAG_FIXED_WIDTH; ... > - if(csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) > + if((csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) && > + (family->FirstFace->fixed_width == (lf.lfPitchAndFamily & MONO_FONT))) This can't work because instead of logical boolean results you compare binary flags which are different: #define FT_FACE_FLAG_FIXED_WIDTH ( 1L << 2 ) #define MONO_FONT 0x08 -- Dmitry.

1 0

suse patch for wineprefixcreate
by Marcus Meissner 07 Aug '04

07 Aug '04

Hi, This is the patch I use at SUSE for wineprefixcreate. Mike wanted to see it ;) $dlldir/config is the sample config file with just minimal local suse changes. Ciao, Marcus Index: wineprefixcreate.in =================================================================== RCS file: /home/wine/wine/tools/wineprefixcreate.in,v retrieving revision 1.4 diff -u -r1.4 wineprefixcreate.in --- wineprefixcreate.in 14 May 2004 00:43:50 -0000 1.4 +++ wineprefixcreate.in 7 Aug 2004 12:40:57 -0000 @@ -86,8 +86,10 @@ if [ -d "$WINEPREFIX" ] || mkdir "$WINEPREFIX"; then : else - echo "Could not create $WINEPREFIX, aborting" - exit 1 +fi + +if [ ! -f "$WINEPREFIX/config" ]; then + cp $dlldir/config "$WINEPREFIX/config" fi WINEPREFIX=`cd "$WINEPREFIX" && pwd` @@ -124,6 +126,35 @@ [ -d "$i" ] || mkdir "$i" done +# Create the drive symlinks +if [ ! -d "$WINEPREFIX/dosdevices" ] +then + mkdir "$WINEPREFIX/dosdevices" + ln -s "../drive_c" "$WINEPREFIX/dosdevices/c:" + ln -s "/" "$WINEPREFIX/dosdevices/z:" + ln -s "/tmp" "$WINEPREFIX/dosdevices/x:" + if [ -d "$HOME" ]; then + ln -s "$HOME" "$WINEPREFIX/dosdevices/y:" + if [ ! -f "$HOME/.windows-label" ]; then + echo "HOME" > "$HOME/.windows-label" + fi + fi + # autodetect CD-ROMS on SUSE. + drive=D + for i in /media/* ; do + bn=`basename $i` + if [ "$i" = "/media/floppy" ]; then + ln -s /media/floppy "$WINEPREFIX/dosdevices/a:" + ln -s /dev/fd0 "$WINEPREFIX/dosdevices/a::" + fi + if echo $bn| grep -E -v "^(sd|usb-storage|floppy)" >/dev/null; then + ln -s /media/$bn "$WINEPREFIX/dosdevices/"`echo $drive|tr "[A-Z]" "[a-z]"`: + ln -s /dev/$bn "$WINEPREFIX/dosdevices/"`echo $drive|tr "[A-Z]" "[a-z]"`:: + drive=`echo $drive|tr "D-L" "E-M"` + fi + done +fi + # Create the application symlinks link_app()

2 1

msvideo 16bit codec question
by Mike Hearn 07 Aug '04

07 Aug '04

Hey Mike, I've been trying to make Maxis Marble Drop work in my non-connected spare time in the evenings, and the intro video doesn't render right. Examination of the code revealed that it had been patched to output pixel blocks in the right direction for the 8 bit decoder but the 16 bit decoder hadn't been modified. So, I copied across the changes to the 16 bit decoder as well, unfortunately it doesn't work. Something is going wrong, and the codec trashes the heap arena, so I'm guessing there's something in the maths that is different for 16 bit videos than 8 bit. Got any ideas? thanks -mike

1 0

wine debugger
by Chipzz 07 Aug '04

07 Aug '04

Hi all, for some reason, the wine debugger just doesn't seem to work for me. wine: Unhandled exception (thread 000f), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ae990,1) - no error checking or testing yet WineDbg starting on pid 0xe In 32 bit mode. Wine-dbg>bt Backtrace: =>1 0x40107b08 __read+0x28 in libc.so.6 (0x40032c54) 2 0x401cc022 Exception c0000005 The backtrace it shows appears to be from the debugger itself, not from the program? Or am I wrong in assuming this? I am getting this same backtrace for each and every program... Also, the ctrl-c key doesn't work as advertised (just does nothing). Wine is wine cvs from 07/31, gdb is 6.1-3 from debian unstable. Anyone got some pointers? kr, Chipzz AKA Jan Van Buggenhout -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

2 1

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier
by Krishna Murthy 06 Aug '04

06 Aug '04

Alexandre, I am resending this patch. There exists a defect 2388. Also confirmed that it fixes one of the Katia's defect found. Please let us know about your thoughts. Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard@winehq.org] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > No, it is required. The DEFDLG_SetDefButton() is also called from > message DM_SETDEFID. In this case idResult should set to the default > button ID passed. And the current logic of DEFDLG_SetDefButton() does > what is required for DM_SETDEFID. Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: list view completely mangled in WINE
by Dan Kegel 06 Aug '04

06 Aug '04

Hi Filip, if you're looking for testcases, could you try the demo programs in http://bugs.winehq.org/show_bug.cgi?id=1268 and http://bugs.winehq.org/show_bug.cgi?id=1404 ? Especially the latter one, which has a tiny MFC demo program in both source code form and precompiled. It misbehaves badly with Wine, and has for years, but perhaps your patch will fix it. Thanks, Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

2 1

vc++ install requires NetUserModalsGet
by James Hawkins 06 Aug '04

06 Aug '04

Hi, Taking the advice of Ivan, I downloaded the beta of Visual C++ 2005 to see how far it could work in Wine, and these are the results: # wine vcsetup.exe fixme:ver:RtlVerifyVersionInfo (0x406df40c,64,180000): Not all cases correctly implemented yet fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:netapi32:NetUserModalsGet (null) 2 0x406df394 Then an error message pops up stating that "a problem has been encountered while loading components" and then it exits. Looking into netapi32/access.c, NetUserModalsGet is a stub and returns NERR_InternalError by default. I think vcsetup is requiring this call to succeed so it bails out because of the error. Reading the trace and the msdn docs about NetUserModalsGet, vcsetup is calling with the level parameter == 2 so it is requesting the domain name and identifier. With the included patch, I have stubbed the structure of the 4 levels that can be queried, but I haven't written the code to handle them yet. If anyone has any information or links that will enlighten me about netapi32 or anything pertaining to this matter, I would greatly appreciate it. quote from MSDN: "The NetUserModalsGet function retrieves global information for all users and global groups in the security database, which is the security accounts manager (SAM) database or, in the case of domain controllers, the Active Directory." Does wine have a security accounts manager or an Active Directory? -- James Hawkins

3 2

Different approach to a->w cleanup of crypt
by James Hawkins 06 Aug '04

06 Aug '04

Hi, I have been trying to get my a->w cleanup of crypt committed for quite some time now, and mostly with no luck because of all the bugs, but I have a better idea about how accomplish this. The problem is that crypt requires a lot of changes to get rid of the w->a calls (the patch was ~27k), and it's too risky to commit the patch even though it looks like all the bugs are gone. The solution is that I will change one piece of crypt at a time and submit small patches that are easier to find bugs in. There are a number of private functions in crypt though that cant be changed to unicode because it will break compilation before the rest of the patches are submitted, so I will submit unicode patches with a W appended to the name of the function as in static inline PSTR CRYPT_GetProvKeyName(PCSTR pProvName) static inline PWSTR CRYPT_GetProvKeyNameW(PCWSTR pProvName) //added Any public api functions that I change until the final patch will use the W version while the unchanged version will continue using the regular ansii version so as to not break compilation. Along with the changes, I will also submit tests for the new unicode api functions so they can be verified to be correct. The first patch adds CRYPT_GetProvKeyNameW. -- James Hawkins

1 1

Re: [D3D] Fixed XYZRHW vertex handling
by Francois Gouget 06 Aug '04

06 Aug '04

--- dlls/ddraw/d3ddevice/mesa_old.c 2004-08-05 15:11:43.000000000 +0100 +++ dlls/ddraw/d3ddevice/mesa.c 2004-08-05 12:50:45.000000000 +0100 @@ -1172,7 +1172,7 @@ glVertex3fv(coords); } inline static void handle_xyzrhw(D3DVALUE *coords) { - if (coords[3] < 1e-8) + if ((coords[3] < 1e-8) && (coords[3] > -1e-8)) glVertex3fv(coords); else { GLfloat w = 1.0 / coords[3]; This could be a job for fabsf of fabs (might be more portable): + if (fabsf(coords[3]) < 1e-8) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

2 1

BeginUpdateResource, UpdateResource and EndUpdateResource
by Vincent Béron 05 Aug '04

05 Aug '04

Hi, I'd like to implement those 3 APIs (both the A and W variants) as the process to update the Mozilla installer for a localized build uses them. Anybody has some pointers where to begin? I tried following the FindResourceEx path, but got lost in ntdll. Vincent

1 0

list view completely mangled in WINE
by Tobias Burnus 05 Aug '04

05 Aug '04

Hello, in Crystal Impact's Diamond the list view is completely mangled and only barely recognizable as list view. Result in WINE: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list_wine.png Result in Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png I'd be really pleased if someone could look at the problem. The demo version of the program is free and available from http://www.crystalimpact.com/download/diamond/demo/dm2demo.exe (In addition to this list-view problem the application does off-screen rendering which is not supported by WINE; one needs to disable rendering in order use the program. See WINE bug http://bugs.winehq.com/show_bug.cgi?id=2320 ) Tobias

5 15

Is check for WS_THICKFRAME style really needed for sizing?
by Santosh Siddheshwar 05 Aug '04

05 Aug '04

Hi, Is the check for windows WS_THICKFRAME style really needed to decide whether a window can be resized or not? I have a scenario where this style is not set but the user can still size the window. This is being done by dispatching WM_SYSCOMMAND messages with SC_SIZE command but WINE is preventing these messages from being effectively handled by returning from the SysCommandSizeMove (winpos.c) method, without doing anything, if the window in question doesnt have this style set. Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

warning when configuring wine-20040716 on OpenBSD 3.5+
by Angelos D. Keromytis 05 Aug '04

05 Aug '04

configure: WARNING: sys/sysctl.h: present but cannot be compiled configure: WARNING: sys/sysctl.h: check for missing prerequisite headers? configure: WARNING: sys/sysctl.h: see the Autoconf documentation configure: WARNING: sys/sysctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/sysctl.h: proceeding with the preprocessor's result configure: WARNING: sys/sysctl.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/sysctl.h... yes

1 0

Fwd:Novell client
by Ivan Leo Puoti 04 Aug '04

04 Aug '04

new ad request.

1 0

Re: Wine and locales
by Dmitry Timoshkov 04 Aug '04

04 Aug '04

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > In an attempt to get away from a possibly confusing subject line, and to > converge on an agreed behavior, here is an attempt to clear the desired > locale behavior Wine should have. Dmitry (and anyone else), please > comment on this table where you think there are errors in it, and say > what should be there. > > In the "Unix setting", I'm always assuming that LC_ALL overrides > whatever is written in that column, and that LANG is used if neither > LC_ALL nor the column are set. I said it many times already, and I'll repeat once more: Windows has only one active locale which defines all the things you mentioned in the table except language of the interface which let's set aside to not confuse each other. There is no need to try to find appropriate mappings for LC_TYPE or anything else you find in the output of the 'locale' command. But still (almost) any locale setting you want to modify in the win32 environment on a per user basis can be done either by running Control Panel/Regional Options, or modifying the registry or win.ini directly. By default all locale data are set according to the global system locale. Any attempt to have more than one active locale simultaneously will lead to confusion and nothing else, be it unix environment or win32. -- Dmitry.

5 40

Re: winedos: dos debugger support
by markus.amsler＠oribi.org 04 Aug '04

04 Aug '04

Quoting Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>: > What does this patch do? Does it do what I believe it does?? :-) > (finally provide useful debugging for DOS programs launched by Wine?) Yeahp. For Debugging .com files you also have to apply the EXEC fix patch [1]. For line editing support, apply BUFFERED INPUT patch [5]. Tested Debuggers (for more see [2]): - Microsoft's debug.exe - ddeb.exe (my favorite) [3] - debug.com (with source) [4] Markus [1] http://www.winehq.org/hypermail/wine-patches/2004/08/0044.html [2] http://www.programmersheaven.com/zone5/cat188/ [3] http://www.programmersheaven.com/zone5/cat188/26391.htm [4] http://www.programmersheaven.com/zone5/cat188/2025.htm [5] http://www.winehq.org/hypermail/wine-patches/2004/08/0043.html

1 0

Re: ListView fixes for Diamond (Try 2)
by Robert Shearman 04 Aug '04

04 Aug '04

Filip Navara wrote: > Changelog: > - Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. > - Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. > - Fix TOOLBAR_DrawMasked to correctly use image list mask. > > - Filip > >------------------------------------------------------------------------ > >Changelog: >- Don't update infoPtr->dwStyle in LISTVIEW_WindowProc. It's already > handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing. >- Ignore WS_VSCROLL/WS_HSCROLL flags in infoPtr->dwStyle because it's > not always up-to-date. >- Fix TOOLBAR_DrawMasked to correctly use image list mask. > >--- comctl32/listview.c Sat Jul 31 22:07:42 2004 >+++ comctl32/listview.c Wed Aug 4 00:19:30 2004 > > ... >--- comctl32/toolbar.c Sat Jul 31 22:07:14 2004 >+++ comctl32/toolbar.c Wed Aug 4 00:19:34 2004 >@@ -658,8 +658,7 @@ > > /* Create src image */ > hdcImage = CreateCompatibleDC(hdc); >- hbmImage = CreateBitmap(cx, cy, GetDeviceCaps(hdc,PLANES), >- GetDeviceCaps(hdc,BITSPIXEL), NULL); >+ hbmImage = CreateCompatibleBitmap(hdc, cx, cy); > SelectObject(hdcImage, hbmImage); > ImageList_DrawEx(himl, index, hdcImage, 0, 0, cx, cy, > RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_NORMAL); >@@ -670,8 +669,8 @@ > SelectObject(hdcMask, hbmMask); > > /* Remove the background and all white pixels */ >- SetBkColor(hdcImage, ImageList_GetBkColor(himl)); >- BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, SRCCOPY); >+ ImageList_DrawEx(himl, index, hdcMask, 0, 0, cx, cy, >+ RGB(0xff, 0xff, 0xff), RGB(0,0,0), ILD_MASK); > SetBkColor(hdcImage, RGB(0xff, 0xff, 0xff)); > BitBlt(hdcMask, 0, 0, cx, cy, hdcImage, 0, 0, NOTSRCERASE); > > > Filip, please put this in a separate patch. Rob

1 0

Re: WININET: take account of dwHeaderLength in HttpSendRequest
by Dmitry Timoshkov 03 Aug '04

03 Aug '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > Does this look better? Strange I didn't get a compiler warning from that... > + if( dwHeaderLength == -1L ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; Well, it's better, but really needs a test to verify whether only -1 or any negative value is treated as a hidden strlen. -- Dmitry.

1 0

Re: WININET: take account of dwHeaderLength in HttpSendRequest
by Dmitry Timoshkov 03 Aug '04

03 Aug '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * take account of dwHeaderLength in HttpSendRequest > - len = strlenW(lpszHeaders)+3; > - szCookedHeaders = HeapAlloc( GetProcessHeap(), 0, sizeof(WCHAR)*len ); > - strcpyW( szCookedHeaders, lpszHeaders ); > + if( dwHeaderLength < 0 ) > + len = strlenW(lpszHeaders); > + else > + len = dwHeaderLength; (dwHeaderLength < 0) is an always true condition, since dwHeaderLength is DWORD, i.e. unsigned long. -- Dmitry.

1 0

wine metacity and ctrl-alt-del binding - ctrl sticks
by Grant Williamson 03 Aug '04

03 Aug '04

Curious if there is a patch somewhere for this. Running rhel3, gnome-2.2 with metacity. 1) Start notepad, type a few characters 2) hit the keyboard combination ctrl-alt-del ... "gnome-session-kill --save" is started. 3) Cancel this option. 4) Now try typing in Notepad, i.e. hit the keys "s" or "f", its just like ctrl-s or ctrl-f have been held in. 5) Hitting ctrl once cancels this. Anyone have a patch, to stop this happening?

2 1

Re: cleanup a->w cross calls in advapi32/crypt.c
by Mike McCormack 03 Aug '04

03 Aug '04

James Hawkins wrote: > + PWSTR keyname; > > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > + keyname = CRYPT_Alloc((strlenW(KEYSTR) + strlenW(pProvName) + 1) * sizeof(WCHAR)); > if (keyname) > { > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > + strcpyW(keyname, KEYSTR); > + strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); > } else > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return keyname; > } This doesn't look right.... when using pointer arithmetic, you do so in increments of the pointer's type (eg. WCHAR). The following two lines are the same, and are both wrong: strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); strcpyW(&keyname[strlenW(KEYSTR) * sizeof(WCHAR)], pProvName); The right version would be: strcpyW(&keyname[strlenW(KEYSTR)], pProvName); but how about just using: strcatW( keyname, pProvname ); Mike

4 4

Re: cleanup a->w cross calls in advapi32/crypt.c
by Jeroen Janssen 02 Aug '04

02 Aug '04

James Hawkins wrote: > I'm wasn't exactly sure on this one so it would be great if you could > help me on this one. When using pointer arithmetic, do the operations > such as --, ++... increment or decrement by the size of the pointer > type? Yes, if you have a char (1byte) pointer and you ++, you'll get one byte further. If you have a short (2byte) you'll get two bytes further in memory. If you have a long (4byte) pointer, you'll get 4 bytes further in memory if you ++. It is simular to dealing with arrays (looking at the memory layout) If you have an array of structs and need to get to the next struct in the array then you will need to look sizeof(struct) further in memory to find the next item in the array. --- Jeroen

1 0

Dynamic memory management in CryptAcquireContext
by Michael Jung 02 Aug '04

02 Aug '04

Alexandre, I've noticed that you applied a modified version of my patch, which tries to fix a potential double free of the "temp" variable in dlls/advapi32/crypt.c's CryptAcquireContextA function. However, I think that the modified version does not fix the problem. Here is a code snippet from the current cvs versionc of crypt.c: CRYPT_Free(temp); ... if (pProv->pFuncs->pCPAcquireContext(&pProv->hPrivate, (CHAR*)pszContainer, dwFlags, pProv->pVTable)) { ... return TRUE; } /* FALLTHROUGH TO ERROR IF FALSE - CSP internal error! */ error: ... CRYPT_Free(temp); ... return FALSE; If the CSP's CPAcquireContext function fails, which is quite common (e.g. because the user specified key container does not exist), the "temp" variable is still free'd twice. I'm aware that my original patch was pretty ugly, due to a lot of redundancy, but I think this is due to fact that the CryptAcquireContext function seems not to be very well structured. I've submitted a patch two weeks ago, which basically was a reimplementation of CryptAcquireContext, but which was not committed (http://www.winehq.org/hypermail/wine-patches/2004/07/0213.html). Rob Shearman commented on this patch and felt that it is overkill to add both a helper function and a new struct type. Is this the reason the patch was not applied? I would be glad to rework the patch, if you give me some hints about what you did not like. However, I would prefer to wait until James Hawkins got his a->w cross call cleanup patch committed, in order not to break his work. Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

2 1

Re: RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info
by Alexandre Julliard 02 Aug '04

02 Aug '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Try to avoid loading 16-bit DLLs into memory for accessing > version info, this might lead to undesired side effects like > loading a bunch of other 16-bit DLLs. The problem I see is that this will bypass the loadorder config, and retrieve the version of the native dll in all cases. I think it would be better to try to take loadorder into account, though I admit it's not trivial to do. -- Alexandre Julliard julliard(a)winehq.org

2 2

Anyone writing COM tests?
by Duane Clark 02 Aug '04

02 Aug '04

Howdy, Debugging a problem I am having in COM (mentioned a few weeks ago), I think I know what the problem is but not where. So I figured some COM test would help me to understand how things should work. I was a bit surprised to see no COM tests, or at least I didn't find any in the ole* directories. So I figured if no one else is working on them, I might take a shot at it over the next few weeks/months. And maybe this would encourage some updates to the COM implementation.

2 2

Fwd:Advertising Enquiry
by Ivan Leo Puoti 02 Aug '04

02 Aug '04

Not sure if I ever forwarded this. Ivan.

2 1

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered
by Marcus Meissner 02 Aug '04

02 Aug '04

On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote: > This change will make sure that if a proxy/stub dll was already registered, > it is not overwritten by the TypeLib Marshaller if we're not registering > an ole automation interface. > I think we (always?) want to use a 'real' available proxy/stub > implementation when available, instead of simply 'overruling' to the > typelib marshaller. Did you verify that this patch does not break InstallShield? Ciao, Marcus

3 5

debugging a dll
by Dan Timis 02 Aug '04

02 Aug '04

Hi, Someone sent me a debug version of a Windows dll and a map file. I'm not a Windows programmer, and I'm not sure how to use the map fiile. For instance, I get a runtime error dialog. With backtrace in winedbg I get this: ... 29 0x400bf58d (NTDLL.DLL.RtlRaiseException+0x5 in NTDLL.DLL) (ebp=4083f9dc) 30 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609 in LIBDEBUG.DLL) (ebp=4083fa1c) 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) 32 0x100012b2 (LIBDEBUG.DLL..text+0x2b2 in LIBDEBUG.DLL) (ebp=4083fbf8) ... I assume that everything above NTDLL.DLL.RtlRaiseException is just code to put up the dialog box, and that the problem is at 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609... If I look for 0x100771e9 in the map file, the closest thing I find is this: 0001:00076ed0 _realloc 10077ed0 f LIBCMTD:dbgheap.obj 0001:00076f00 __realloc_dbg 10077f00 f LIBCMTD:dbgheap.obj 0001:000774b0 __expand 100784b0 f LIBCMTD:dbgheap.obj 0001:000774e0 __expand_dbg 100784e0 f LIBCMTD:dbgheap.obj Am I correct to assume that realloc_dbg throws an exception? If I look for 0x100012b2 (LIBDEBUG.DLL..text+0x2b2), the closest I find is: 0001:000011d0 ?_Grow@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAE_ NI_N@Z... That would make sense, we are trying to grow a string, calling realloc, etc. The entry in the middle: 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) points to: 0001:00097140 ?onEvent@Application@UIA@NI@@MAE_NIPAVEventData@23@@Z ... I don't understand how this relates to the other two. Are there any tools that could help understand better what's going on? Are there any tools to demangle the C++ names? I tried c++filt and not surprisingly it did not understand these symbols. Thanks, Dan Timis Muse Research, Inc.

4 3

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 02 Aug '04

02 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Full rewrite. If you have any questions, I'll be happy to answer them. > > Changelog > * clean up cross-call functions > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > + strcpyW(keyname, KEYSTR); > + strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); Why did you add '* sizeof(WCHAR)' here? > - user ? strcpy(keyname, USERSTR) : strcpy(keyname, MACHINESTR); > - ptr = keyname + strlen(keyname); > - *(--ptr) = (dwType % 10) + '0'; > - *(--ptr) = ((dwType / 10) % 10) + '0'; > - *(--ptr) = (dwType / 100) + '0'; > + user ? strcpyW(keyname, USERSTR) : strcpyW(keyname, MACHINESTR); > + ptr = keyname + strlenW(keyname) * sizeof(WCHAR); And here? Did you ever test the resulting code? -- Dmitry.

1 0

c:\\windows is not accessible message
by Mike Hearn 01 Aug '04

01 Aug '04

Hi guys, It seems quite a few people have been seeing this message lately, and I'm not sure why. This occurs even with a non-existant ~/.wine directory, so wineprefixcreate should set up a correct system for them. Examples: http://www.linuxquestions.org/questions/showthread.php?s=&threadid=204255&h… http://forums.devshed.com/archive/t-166324 This one seems to imply that the symlinks aren't being created properly: http://www.winehq.org/hypermail/wine-users/2004/07/0022.html but that sounds like a migration issue rather than something you'd see with a clean .wine If anybody has any ideas I'd love to track this one down. I am wondering if it's to do with packaging, I have never been able to reproduce this with Wine CVS builds (ie from source) but I know some packagers are still shipping custom ~/.wine building scripts. thanks -mike

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