July 2003 - Wine-devel - list.winehq.org

I now know what I am going to work on
by Jonathan Wilson 22 Jul '03

22 Jul '03

After all the feedback, I have decided to work on 4 things: 1.a fontview.exe clone (should give me good experiance in working with the GDI font APIs and also should give the WINE implementations of those APIs a workout. In particular, the functionality used to display a font even though its not registered with the system font lists should be a nice thing to hack on and figure out how its done. Plus, ReactOS can use the results. 2.a guidgen.exe clone (the origonal uses MFC, mine wont obviously) 3.a uuidgen.exe clone (usefull as a way to generate GUIDs/UUIDs from a script or makefile) and 4.a cards.dll clone. Its not only used by the MS card games but others as well. Its been reverse engineered by some people and also at some point MS released an "official" SDK for it (at http://www.microsoft.com/mind/0396/games.asp ) so if we dont clone it, people cant play non-ms games that use it :)

1 0

Once again: Wine without X?
by Dan Kegel 22 Jul '03

22 Jul '03

OK folks, it's time for my semiannual "I need Wine to run a commandline program, but can't get it to work" rant. First try: just do a default installation of wine-20030709. Log: $ wine -- /dos/d/vss/win32/ss.exe Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Can't open display: $ echo $DISPLAY $ That should have worked, since ss.exe doesn't use any GDI functions. Moving right along, now let's try the tty driver. I added "GraphicsDriver" = "ttydrv" dank(a)dank:~$ wine /dos/d/vss/win32/ss.exe dank(a)dank:~$ It blipped the display to a second screen, then when the program exited, the screen blipped back so I couldn't read what it said. That's pretty useless. In fact, this is exactly the behavior complained about in bug 1358 ( http://bugs.winehq.com/show_bug.cgi?id=1358 ) subtitled "GraphicsDriver" = "none" wanted. On the off chance that a "none" driver had been implemented, I tried it. And suprisingly, something sensible happened: dank(a)dank:~$ wine /dos/d/vss/win32/ss.exe help Could not load graphics driver 'none' fixme:console:SetConsoleCtrlHandler (0x449460,1) - no error checking or testing yet Username: It actually seemed to work, once past the warning! I haven't tested it beyond the password prompt yet, but that was pretty convincing. Is this the recommended way to run console wine programs without any $&?@!\% curses stuff kicking in and without X? And is there a chance of setting this behavior on a program-by-program basis? AppDefaults appears to be keyed off the driver already, so is probably not able to say "these apps should not use x11drv or ttydrv". Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 9

Re: Sync (29): msvcrt cpp
by Alexandre Julliard 22 Jul '03

22 Jul '03

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/msvcrt/cpp.c > Use exception as the base for all exception derived classes. > Implement type_info methods correctly. > Add static RTTI for exported objects. > Throw exceptions when run time casts fail. Why did you remove all the structure definitions for the derived classes? I think it's much clearer to have a separate C type for each class instead of having everything be an exception object. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: shlwapi
by Alexandre Julliard 21 Jul '03

21 Jul '03

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Numbers without prefix are int (32bit signed). If you > want long long (64bit signed), append LL. LL is not portable, this needs to be done with casts. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Avoid problems with glibc's _res symbol
by Mike Hearn 21 Jul '03

21 Jul '03

Isn't _res an internal function? If so, why is Wine using it? On Mon, 2003-07-21 at 10:06, Mike McCormack wrote: > Newer versions of glibc don't exporting the _res symbol, but instead > replace it with a function call of a different name. This breaks binary > compatibility for code using _res compiled and linked with older > versions of glibc. (iphlpapi uses _res) > > Mike > > > ChangeLog: > * dlopen libc to avoid problems with glibc's _res symbol, which only > defined in older glibc versions > > > ______________________________________________________________________ > Index: configure.ac > =================================================================== > RCS file: /home/wine/wine/configure.ac,v > retrieving revision 1.166 > diff -u -r1.166 configure.ac > --- configure.ac 16 Jul 2003 23:37:22 -0000 1.166 > +++ configure.ac 21 Jul 2003 02:45:13 -0000 > @@ -911,8 +911,8 @@ > WINE_GET_SONAME(jack,jack_client_new) > WINE_GET_SONAME(ssl,SSL_library_init) > WINE_GET_SONAME(crypto,BIO_new_socket) > + WINE_GET_SONAME(c, vsprintf) > fi > - > > dnl **** Check for functions **** > > Index: configure > =================================================================== > RCS file: /home/wine/wine/configure,v > retrieving revision 1.441 > diff -u -r1.441 configure > --- configure 16 Jul 2003 23:37:22 -0000 1.441 > +++ configure 21 Jul 2003 02:45:21 -0000 > @@ -2246,7 +2246,8 @@ > echo "$as_me:$LINENO: \$? = $ac_status" >&5 > (exit $ac_status); }; }; then > for ac_declaration in \ > - '' \ > + ''\ > + '#include <stdlib.h>' \ > 'extern "C" void std::exit (int) throw (); using std::exit;' \ > 'extern "C" void std::exit (int); using std::exit;' \ > 'extern "C" void exit (int) throw ();' \ > @@ -2260,8 +2261,8 @@ > cat confdefs.h >>conftest.$ac_ext > cat >>conftest.$ac_ext <<_ACEOF > /* end confdefs.h. */ > -$ac_declaration > #include <stdlib.h> > +$ac_declaration > int > main () > { > @@ -12977,8 +12978,72 @@ > #define SONAME_LIBCRYPTO "$ac_cv_lib_soname_crypto" > _ACEOF > fi > -fi > > +echo "$as_me:$LINENO: checking for -lc soname" >&5 > +echo $ECHO_N "checking for -lc soname... $ECHO_C" >&6 > +if test "${ac_cv_lib_soname_c+set}" = set; then > + echo $ECHO_N "(cached) $ECHO_C" >&6 > +else > + ac_get_soname_save_LIBS=$LIBS > +LIBS="-lc $LIBS" > + cat >conftest.$ac_ext <<_ACEOF > +#line $LINENO "configure" > +/* confdefs.h. */ > +_ACEOF > +cat confdefs.h >>conftest.$ac_ext > +cat >>conftest.$ac_ext <<_ACEOF > +/* end confdefs.h. */ > + > +/* Override any gcc2 internal prototype to avoid an error. */ > +#ifdef __cplusplus > +extern "C" > +#endif > +/* We use char because int might match the return type of a gcc2 > + builtin and then its argument prototype would still apply. */ > +char vsprintf (); > +int > +main () > +{ > +vsprintf (); > + ; > + return 0; > +} > +_ACEOF > +rm -f conftest.$ac_objext conftest$ac_exeext > +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 > + (eval $ac_link) 2>&5 > + ac_status=$? > + echo "$as_me:$LINENO: \$? = $ac_status" >&5 > + (exit $ac_status); } && > + { ac_try='test -s conftest$ac_exeext' > + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 > + (eval $ac_try) 2>&5 > + ac_status=$? > + echo "$as_me:$LINENO: \$? = $ac_status" >&5 > + (exit $ac_status); }; }; then > + ac_cv_lib_soname_c=`$ac_cv_path_LDD conftest$ac_exeext | grep libc\\.so | sed 's/^[ ]*$[^ ]*$[ ]*=>.*$/\1/'` > + if test "x$ac_cv_lib_soname_c" = "x" > + then > + ac_cv_lib_soname_c="libc.so" > + fi > +else > + echo "$as_me: failed program was:" >&5 > +sed 's/^/| /' conftest.$ac_ext >&5 > + > +ac_cv_lib_soname_c="libc.so" > +fi > +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext > + LIBS=$ac_get_soname_save_LIBS > +fi > +echo "$as_me:$LINENO: result: $ac_cv_lib_soname_c" >&5 > +echo "${ECHO_T}$ac_cv_lib_soname_c" >&6 > +if test "x$ac_cv_lib_soname_c" != xNONE > +then > +cat >>confdefs.h <<_ACEOF > +#define SONAME_LIBC "$ac_cv_lib_soname_c" > +_ACEOF > +fi > +fi > > > # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works > Index: include/config.h.in > =================================================================== > RCS file: /home/wine/wine/include/config.h.in,v > retrieving revision 1.157 > diff -u -r1.157 config.h.in > --- include/config.h.in 20 Jun 2003 23:26:56 -0000 1.157 > +++ include/config.h.in 21 Jul 2003 02:45:22 -0000 > @@ -53,6 +53,9 @@ > /* Define to 1 if you have the <cups/cups.h> header file. */ > #undef HAVE_CUPS_CUPS_H > > +/* Define to the soname of the C library. */ > +#undef SONAME_LIBC > + > /* Define to 1 if you have the <curses.h> header file. */ > #undef HAVE_CURSES_H > > Index: dlls/iphlpapi/Makefile.in > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/Makefile.in,v > retrieving revision 1.1 > diff -u -r1.1 Makefile.in > --- dlls/iphlpapi/Makefile.in 13 May 2003 03:32:20 -0000 1.1 > +++ dlls/iphlpapi/Makefile.in 21 Jul 2003 02:45:22 -0000 > @@ -7,6 +7,7 @@ > > LDDLLFLAGS = @LDDLLFLAGS@ > SYMBOLFILE = $(MODULE).tmp.o > +EXTRALIBS = @DLLIBS@ > > C_SRCS = \ > ifenum.c \ > Index: dlls/iphlpapi/iphlpapi_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/iphlpapi_main.c,v > retrieving revision 1.4 > diff -u -r1.4 iphlpapi_main.c > --- dlls/iphlpapi/iphlpapi_main.c 23 Jun 2003 03:32:28 -0000 1.4 > +++ dlls/iphlpapi/iphlpapi_main.c 21 Jul 2003 02:45:22 -0000 > @@ -29,6 +29,8 @@ > #include <arpa/nameser.h> > #endif > #include <resolv.h> > +#include <wine/library.h> > +#include <wine/port.h> > #include "winbase.h" > #include "iphlpapi.h" > #include "ifenum.h" > @@ -847,6 +849,35 @@ > return getIPStats(pStats); > } > > +/****************************************************************** > + * IPHLPAPI_GetResolver > + * > + * Finds the location of the DNS server list for GetNetworkParams > + */ > +#ifdef __GLIBC__ > +struct __res_state *IPHLPAPI_GetResolverState() > +{ > + static struct __res_state *p_res; > + static struct __res_state *(*p__res_state)(); > + static void *plibc; > + > + if( !plibc ) > + { > + plibc = wine_dlopen(SONAME_LIBC, RTLD_GLOBAL, NULL, 0 ); > + p__res_state = wine_dlsym(plibc, "__res_state", NULL, 0 ); > + p_res = wine_dlsym(plibc, "_res", NULL, 0 ); > + } > + > + if( p__res_state ) > + return p__res_state(); > + > + if( p_res ) > + return p_res; > + > + return NULL; > +} > +#endif /* __GLIBC */ > + > > /****************************************************************** > * GetNetworkParams (IPHLPAPI.@) > @@ -865,11 +896,22 @@ > DWORD WINAPI GetNetworkParams(PFIXED_INFO pFixedInfo, PULONG pOutBufLen) > { > DWORD size; > +#ifdef __GLIBC__ > + struct __res_state *p_res = IPHLPAPI_GetResolverState(); > +#endif > + int res_nscount = 0; > > if (!pOutBufLen) > return ERROR_INVALID_PARAMETER; > > - size = sizeof(FIXED_INFO) + min(1, (_res.nscount - 1) * > +#ifdef __GLIBC__ > + if( p_res ) > + res_nscount = p_res->nscount; > +#else > + res_nscount = _res.nscount; > +#endif > + > + size = sizeof(FIXED_INFO) + min(1, (res_nscount - 1) * > sizeof(IP_ADDR_STRING)); > if (!pFixedInfo || *pOutBufLen < size) { > *pOutBufLen = size; > @@ -881,14 +923,19 @@ > GetComputerNameExA(ComputerNameDnsHostname, pFixedInfo->HostName, &size); > size = sizeof(pFixedInfo->DomainName); > GetComputerNameExA(ComputerNameDnsDomain, pFixedInfo->DomainName, &size); > - if (_res.nscount > 0) { > + if ( res_nscount > 0) { > PIP_ADDR_STRING ptr; > int i; > > - for (i = 0, ptr = &pFixedInfo->DnsServerList; i < _res.nscount; > + for (i = 0, ptr = &pFixedInfo->DnsServerList; i < res_nscount; > i++, ptr = ptr->Next) { > +#ifdef __GLIBC__ > + toIPAddressString(p_res->nsaddr_list[i].sin_addr.s_addr, > + ptr->IpAddress.String); > +#else > toIPAddressString(_res.nsaddr_list[i].sin_addr.s_addr, > ptr->IpAddress.String); > +#endif > ptr->Next = (PIP_ADDR_STRING)((PBYTE)ptr + sizeof(IP_ADDRESS_STRING)); > } > }

3 3

Re: [MSDMO] Some methods implement and stubs added
by Dmitry Timoshkov 21 Jul '03

21 Jul '03

"Michael "GЭnnewig"" <MichaelGuennewig(a)gmx.de> wrote: > Changelog: > - Implemented Mo* methods in msdmo.dll > - Added stubs for DMORegister, DMOUnregister, DMOEnum, DMOGetTypes, > DMOGetName. > - Added version resources. Please use a usual Wine scheme for defining version resources, see existing resources for details. -- Dmitry.

2 3

More Red Hat b0rkage?
by Mike Hearn 21 Jul '03

21 Jul '03

I know Wine has some issues with some kernel security patches and memory regions. Can anybody confirm that this won't cause issues: The Red Hat Linux 9.0.93 kernel includes new Exec-shield functionality Exec-shield is a security-enhancing modification to the Linux kernel that makes large parts of programs — including their stack — not executable. This can reduce the potential damage of some security holes. Exec-shield is related to the older "non-exec stack patch" but has the potential to provide much greater protection. Exec-shield's behavior can be controlled via the proc file system. The command used is: echo <value> > /proc/sys/kernel/exec-shield thanks -mike

2 1

Question about WINE and adding the "low-level" CD access APIs...
by Jonathan Wilson 21 Jul '03

21 Jul '03

Many copy protections use special tricks on the CDs (I dont know the details). Presumably these protections use some kind of lower-level API to access the data on the CD directly (instead of going through the file I/O calls). Currently TransGaming does something specific for each kind of copy protection to make it work. Would it be possible to implement these APIs in WINE and have them redirect to whatever low level APIs are provided by linux/x/whatever? That way (assuming the implementation was complete), any copy protection would work (i.e. when the protection says "give me this bit of data from the CD in this form", WINE hooks that, gets the relavent data and returns it to the application. Same could be said for protections that use the "boot blocks" to store licence data (such as CDilla Licence Manager), for those you could hook the "read from boot block" and "write to boot block" calls and store the data somewhere (preferably not the real boot block :) If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document. Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :) If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...

4 6

My wine turned to vinegar... vanilla wine isn't broken, is it?
by Gregory M. Turner 21 Jul '03

21 Jul '03

OK, this is a new problem to me... I'm not too familiar with the loader so I thought I'd see if anybody knew what was going on before I spent time trying to debug this myself. I recently decided that my wine installation had become too crufty, so I wiped out ~/c, and ~/.wine, and ran tools/wineinstall. This is with CVS wine... IOW, a 100% standard config. Everything seemed to go fine with wineinstall, but now, no matter what I try, I seem to be unable to run wine at all -- it more-or-less immediately segfautlts. I didn't change anything; aside from some truly trivial font path fixups, I have a completely vanilla ~/.wine/config and ~/c tree. Under gdb, I see the following if I try to run notepad (or any other thing): (gdb) up #1 0x4011ba3c in wine_dll_set_callback (load=0x400a7aa0 <load_library>) at loader.c:353 (gdb) print builtin_dlls[i].filename $6 = 0x400dcb95 "ntdll.dll" (gdb) down #0 map_dll (nt_descr=0x400f7b20) at loader.c:166 (gdb) bt #0 map_dll (nt_descr=0x400f7b20) at loader.c:166 #1 0x4011ba3c in wine_dll_set_callback (load=0x400a7aa0 <load_library>) at loader.c:353 #2 0x400a80c3 in BUILTIN32_LoadExeModule (main=0x0) at ../../relay32/builtin32.c:181 #3 0x403f5715 in __wine_process_init (argc=2, argv=0xbffff5f4) at ../../../wine/scheduler/process.c:578 #4 0x4011bc6a in wine_init (argc=2, argv=0xbffff5f4, error=0xbffff1a4 "", error_size=1024) at loader.c:427 #5 0x3c000540 in main (argc=2, argv=0xbffff5f4) at ../../wine/miscemu/main.c:33 #6 0x40237747 in __libc_start_main () from /lib/libc.so.6 (gdb) print ptr $7 = (void *) 0x41b (gdb) print base $8 = (void *) 0x0 It's deferencing the 0x41b pointer which is causing the segfault... Any ideas? If not, how should I try and debug this?... what is fixup_rva_ptr's (libs/wine/loader.c) all about? And, if this is what happens with a completely vanilla wine install, why doesn't "everybody" have this problem? Surely, I am missing something totally obvious? Thanks, -- "We must stop thinking of the individual and start thinking about what is best for society." -Hillary Clinton, 1993 gmt

4 5

Re: Mach-O Support in WineLib Loader
by Mike Hearn 21 Jul '03

21 Jul '03

Out of curiousity, how do you get around the linkage requirements of Mach-O, ie the fact that you can't both dlopen and runtime link to the same module? On Mon, 2003-07-21 at 13:08, Pierre d'Herbemont wrote: > Hi! > > This patch enables Mach-O (Darwin linker file format) support in > WineLib. > > Thanks, > > Pierre > > ModifiedFiles: > - loader/module.c > > ChangeLog: > - Add Mach-O (Darwin file format) support. >

2 1