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

Re: Wine devel: Two MFC bugs

by Dan Kegel

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

Aug. 10, 2004

Re: Winelib under Solaris/SPARC

by Robin KAY

Mike Hearn wrote: > wine_pthread_* functions are supposed to be defined in the > wine-pthread/wine-kthread binaries. The DSOs then have their symbols > resolved to the executable at runtime. I don't know why this isn't > working for you but it's almost certainly related to using > Solaris/SPARC. It looks like GNU binutils were at fault. I rebuilt gcc to use Sun's linker, fixed the bad flags specified for it in configure.ac, and wine builds without the error (not counting a bunch of other minor portability fixes to the tree). Of course, the binaries still segfault. $ wineprefixcreate $ winemine Segmentation Fault - core dumped $ gdb /usr/local/bin/wine core GNU gdb 6.1 [snip] Core was generated by `/usr/local/bin/wine winemine.exe'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libwine.so.1...done. [snip] Loaded symbols for /usr/local/lib/wine/kernel32.dll.so #0 0xfec92814 in NtCurrentTeb () from /usr/local/lib/wine/kernel32.dll.so (gdb) bt #0 0xfec92814 in NtCurrentTeb () from /usr/local/lib/wine/kernel32.dll.so #1 0xfec068c0 in __wine_kernel_init () at process.c:1016 #2 0xff04955c in __wine_process_init (argc=-16477044, argv=0xff3853d8) at loader.c:2057 #3 0xff384618 in wine_init (argc=1, argv=0x0, error=0xffbff0f8 "", error_size=1024) at loader.c:536 #4 0x00010fdc in main (argc=1, argv=0xffbff56c) at main.c:44 > You'd have greater success running Linux I suspect, if > it's just a UNIXish environment you're after .... Or Solaris/IA32 for that matter. This is the only machine I have at the moment though. -- Wishing you good fortune, --Robin Kay-- (komadori)

Aug. 10, 2004

Re: Small make compatibility changes (take 2)

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This seems to let users build and uninstall with BSD make. > > Changelog: > Evaluate variable after replacement to build with BSD make. Unfortunately assignments with := are not portable either, so it's only moving the problem. We probably need to restructure the makefiles a bit to avoid that construct. -- Alexandre Julliard julliard(a)winehq.org

Aug. 9, 2004

Re: Add a linker rpath so libwine can be found without modifying ld.so.conf or LD_LIBRARY_PATH

by Alexandre Julliard

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

Aug. 9, 2004

Wine devel: Two MFC bugs

by Green, Shaun E.

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

Aug. 9, 2004

CVS build fails

by Ivan Leo Puoti

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(a)localhost wine]$ Ivan.

Aug. 9, 2004

Re: Winelib under Solaris/SPARC

by Mike Hearn

> 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. wine_pthread_* functions are supposed to be defined in the wine-pthread/wine-kthread binaries. The DSOs then have their symbols resolved to the executable at runtime. I don't know why this isn't working for you but it's almost certainly related to using Solaris/SPARC. You'd have greater success running Linux I suspect, if it's just a UNIXish environment you're after .... though I'm not sure developing Windows software using Wine is a good plan anyway, you'd end up spending time fixing Wine bugs as well as writing your prorgams :) thanks -mike

Aug. 9, 2004

Winelib under Solaris/SPARC

by Robin KAY

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)

Aug. 9, 2004

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings

by Mike McCormack

Hans Leidekker wrote: > where Wine defines STATUS_SUCCESS like so: > > #define STATUS_SUCCESS 0x00000000 > > which means STATUS_SUCCESS is handled by gcc as an unsigned value. This > generates a warning because NTSTATUS is signed. If we look at the > SDK definition we see something different: > > #define STATUS_SUCCESS ((NTSTATUS)0x00000000L) > > Which would get rid of the warnings for us if we add the cast there too. > Should I submit a patch to do this? To add a cast in every such code sequence > is not a good alternative if you ask me, as it's a very common idiom. Any > other solutions? Seems reasonable to fix Wine's headers to me. I think there's quite a few values like that to fix :/ Mike

Aug. 9, 2004

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > What do you propose then? I could do something like this: > > if (GetLastError()==(DWORD)NTE_BAD_KEYSET) > > But I consider a cast even uglier then introducing an intermediate > variable. We somehow have to live with the fact that NTE_BAD_KEYSET > is defined as ((HRESULT)0x80090016L), which is signed, and GetLastError() > returning DWORD, i.e unsigned. I propose a simple solution - just ignore warnings in these cases. Win32 is not an API which you could safely compile with signed/unsigned comparison warnings turned on, there are huge amount of cases when an API receives an unsigned int as a string length but returns signed int as a resulting length, and vice versa. There is no any consistency with passing/returning buffer lengths in Win32 at all, sometimes it's DWORD, sometimes UINT, sometimes just int. And that's just a couple of examples. -- Dmitry.

Aug. 9, 2004

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings

by Hans Leidekker

On Monday 09 August 2004 12:17, Hans Leidekker wrote: > variable. We somehow have to live with the fact that NTE_BAD_KEYSET > is defined as ((HRESULT)0x80090016L), which is signed, and GetLastError() > returning DWORD, i.e unsigned. On a related note, I am looking at the last testsuite with signed/unsigned comparison warnings, ntdll, and I'm trying to deal with constructs like this one: NTSTATUS ntstatus; ok(ntstatus == STATUS_SUCCESS, "Call failed (%lu)\n", ntstatus); where Wine defines STATUS_SUCCESS like so: #define STATUS_SUCCESS 0x00000000 which means STATUS_SUCCESS is handled by gcc as an unsigned value. This generates a warning because NTSTATUS is signed. If we look at the SDK definition we see something different: #define STATUS_SUCCESS ((NTSTATUS)0x00000000L) Which would get rid of the warnings for us if we add the cast there too. Should I submit a patch to do this? To add a cast in every such code sequence is not a good alternative if you ask me, as it's a very common idiom. Any other solutions? -Hans

Aug. 9, 2004

Re: rsabase and itunes

by Robert Shearman

On Wed, 2004-08-04 at 03:31, Michael Jung wrote: > 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? The initial effort was to do with a Codeweavers project, as I suspected some problems with the application were due to missing functionality in rsabase, but it soon became obvious that this was not the problem. I then decided to continue development on rsabase in my own time. Hopefully, I will have some usable patches in the next week or so. Rob

Aug. 9, 2004

"Call Identifier" -- MSRPC ??

by Auge Mike

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

Aug. 9, 2004

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings

by Hans Leidekker

On Monday 09 August 2004 11:17, Dmitry Timoshkov wrote: > > - 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. What do you propose then? I could do something like this: if (GetLastError()==(DWORD)NTE_BAD_KEYSET) But I consider a cast even uglier then introducing an intermediate variable. We somehow have to live with the fact that NTE_BAD_KEYSET is defined as ((HRESULT)0x80090016L), which is signed, and GetLastError() returning DWORD, i.e unsigned. -Hans

Aug. 9, 2004

Re: RSABASE/TESTS: Fix signed/unsigned comparison warnings

by Dmitry Timoshkov

"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.

Aug. 9, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Apart for much cleaner code, it's also useful, as I can see many > people do: > #ifdef WINE > # define ERR WINE_ERR > # define TRACE WINE_TRACE > ... > #else > # define ERR printf > # define TRACE printf > ... > #endif > > I have a sentimental attachment to the Wine's debugging API, as it was > the first project that I undertook in Wine. It was what "hooked" me in. > This may be a small issue, and probably I shouldn't care, but I can't > help it. I truely think requiring the WINE_/wine_ prefix inside of Wine > for commonly used symbols in the debugging API is not a good direction, > and I really hope we can revisit this decision. I agree for the ERR etc. macros, but I don't think the debugstr functions are the same issue at all. You can't really #define them to something else anyway, you need to link with libwine to make them available. So I think it makes much more sense to keep the wine_ prefix for them, so that usage is consistent between Wine and Winelib code. -- Alexandre Julliard julliard(a)winehq.org

Aug. 8, 2004

Re: Fix crash in dsound test

by Kevin Koltzau

On Thursday 29 July 2004 01:17 pm, Ferenc Wagner wrote: > 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. My build is now working again as of today, thanks to Hans Leidekker What worked for me was removing w32api_directx.patch and adding his w32api_lib_uuid_c.patch

Aug. 8, 2004

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars

by Jens Collin

Hi Steven, yes, that's why I only merged enough to solve the problem to ros, and not the whole lib :) I'll see what I can do on regressiontests. / Jens -----Original Message----- From: Steven Edwards [mailto:steven_ed4153(a)yahoo.com] Sent: den 8 augusti 2004 18:34 To: wine-devel(a)winehq.org; wine-patches(a)winehq.org Cc: jens.collin(a)lakhei.com Subject: Re: patch: shell32.dll - SHELL_ArgifyW expands env-vars 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

Aug. 8, 2004

Re: patch: shell32.dll - SHELL_ArgifyW expands env-vars

by Steven Edwards

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

Aug. 8, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by Mike Hearn

On Sun, 2004-08-08 at 10:56 -0500, David D. Hagood wrote: > Mike Hearn wrote: > > Install it all as Win98 if possible, and native DCOM like this: > > > > WINEDLLOVERRIDES=ole32,oleaut32,rpcrt4=n wine DCOM98.EXE > > Well, having done so, and having tried setting all the OLE* and RPC* > DLLs to native, I am still having the same problem with that app - so I > am forced to conjecture that it is not a direct problem with OLE but > some other aspect of the program. That sounds likely. The OLE trace you provided didn't show much activity.

Aug. 8, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by David D. Hagood

Mike Hearn wrote: > Install it all as Win98 if possible, and native DCOM like this: > > WINEDLLOVERRIDES=ole32,oleaut32,rpcrt4=n wine DCOM98.EXE Well, having done so, and having tried setting all the OLE* and RPC* DLLs to native, I am still having the same problem with that app - so I am forced to conjecture that it is not a direct problem with OLE but some other aspect of the program.

Aug. 8, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Dimitrie O. Paun

On Sat, Aug 07, 2004 at 04:00:25PM -0700, Alexandre Julliard wrote: > 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. Please let's not do this inside of Wine. Clearly, we want to export everthing with the WINE_/wine_ prefix, I'm not debating this. I can also see that we want to be consistent, and that's a good thing -- for all but the debugging API our symbol invokations are far and few in between, and it actually *helps* to see when we call a non-standard API. However, the exact opposite holds for the debugging API: it is the most used API in the source, and it doesn't help to know that it's a Wine API. Having the prefix on every single symbol of this API would not only greatly clutter the code, but I'd also claim it's not the style we should promote. People should try to write portable Win32 code (and here portable is between MS Windows and Wine), and a wine_ prefix is a big bad warning sign. One should be able to grep the sources for wine_ to figure out such places. Hiding them inside mountains of debug calls will not help. Usage of the debug API should not tie the code to Wine, and the source should make it clear. We should promote symbol renaming for Winelib apps (just like we do in Wine today): #define ERR WINE_ERR #define TRACE WINE_TRACE ... Apart for much cleaner code, it's also useful, as I can see many people do: #ifdef WINE # define ERR WINE_ERR # define TRACE WINE_TRACE ... #else # define ERR printf # define TRACE printf ... #endif I have a sentimental attachment to the Wine's debugging API, as it was the first project that I undertook in Wine. It was what "hooked" me in. This may be a small issue, and probably I shouldn't care, but I can't help it. I truely think requiring the WINE_/wine_ prefix inside of Wine for commonly used symbols in the debugging API is not a good direction, and I really hope we can revisit this decision. -- Dimi.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Jacek Caban

Dmitry Timoshkov wrote: >"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > > > >>No, I don't. In my case I need only this: >> >> /* this is where we are coming from */ >>+ ITypeLib2_AddRef((ITypeLib*)pLibInfo); >> ptiRet->pTypeLib = pLibInfo; >> ptiRet->index=count; >> >>but I call ITypeLib_Release in ITypeInfo_Release so I thought I should >>increment ref here too. >> >> > >Then use my test program and possibly add some other test for >typelib reference counting until you get it right. Then submit >a tested patch to wine-patches. > > > Thanks for help. I found my bug and I'll send patch soon. Jacek

Aug. 8, 2004

Re: Problem with ITypeInfo

by Dmitry Timoshkov

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > No, I don't. In my case I need only this: > > /* this is where we are coming from */ > + ITypeLib2_AddRef((ITypeLib*)pLibInfo); > ptiRet->pTypeLib = pLibInfo; > ptiRet->index=count; > > but I call ITypeLib_Release in ITypeInfo_Release so I thought I should > increment ref here too. Then use my test program and possibly add some other test for typelib reference counting until you get it right. Then submit a tested patch to wine-patches. -- Dmitry.

Aug. 8, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by Mike Hearn

On Sat, 2004-08-07 at 16:02 -0500, David D. Hagood wrote: > Yes, I am - I was under the impression that would give a better shot at > compatability since, when there is a mutually exclusive choice between > the 9X and the NT way, Wine tends to follow the NT way. No, 9x mode is recommended. Programs tend to stress the system harder when run in NT mode, they use NT only APIs and such we may not implement and don't get as much testing. > > regression there lately if you use 9x DCOM but I think it's fixed now. > > Easy enough to fix if not. > > So you are suggesting that I attempt to re-install the Win98 DCOM > package? Should I change the ole* overrides to "native,builtin", and if > so, should I do so before or after installing the DCOM package? Should I > also change the Winver to 98, and if so, should I do so for all > programs, just the DCOM installer, or for the DCOM install + Mng6? Install it all as Win98 if possible, and native DCOM like this: WINEDLLOVERRIDES=ole32,oleaut32,rpcrt4=n wine DCOM98.EXE thanks -mike

Aug. 8, 2004