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