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

glibc tracker bug
by Mike Hearn 02 Apr '03

02 Apr '03

Hi, As we've been getting quite a few reports of glibc 2.3.x related failures in bugzilla lately, it makes sense to mark them as dupes of a bug, so I've started duping them against bug #1343 http://bugs.winehq.com/show_bug.cgi?id=1343 That way, when these problems are sorted out, we won't have to go through and resolve them all manually. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 3

Re: ImageList - dirty hack
by Vitaliy Margolen 02 Apr '03

02 Apr '03

Is there are any reason why this one haven't been checked in? This is pretty close to what windows does. Vitaliy Margolen > Fix ImageList_Read. This hopefully fixes these ugly images mostly on tool bars. > I'll continue to work on ImageList since ImageList_Replace, ImageList_Add, > ImageList_GetImageInfo and perhaps some other functions doesn't work right. > Vitaliy Margolen > changelog: > - dlls/comctl32/imagelist.c > fix ImageList_Read - the root cause of ugly toolbar icons > Index: dlls/comctl32/imagelist.c > =================================================================== [skip]

1 0

Compiling Wine sources with duplicated include parameters
by Rolf Kalbermatter 02 Apr '03

02 Apr '03

While downloading and compiling the latest CVS sources I noticed that the command line for each (most?) source files reads like gcc -c -I. -I. -I../../include -I../../include ............. or similar This is not a serious problem but the duplication of the two include parameters strikes me as odd and definitely unnecessary, making the command line unnecessarily long. Seems like something in the makefile generation is causing this. Rolf Kalbermatter

5 8

Unexpected message from winebuild...
by Kevin Cousins 02 Apr '03

02 Apr '03

...when attempting to build a WineLib application. Remember, I'm attempting to get something that will run-time link against a native DLL, so I take my code, run it by "winemaker", run "./configure", then "make", all with options I believe to be appropriate. In particular, given export WINEDIR=/home/kevin/wine, the root of my Wine source tree checked out from winehq CVS yesterday, and export DLLINCDIR=/home/kevin/include, then from within the directory containing the C source code for my simple console app I execute the following: $ winemaker --cuiexe -I${DLLINCDIR} -I${WINEDIR} [...snip...] $ ./configure --with-wine=${WINEDIR} \ --with-wine-dlls=${WINEDIR}/libs/dlls --srcdir=`pwd` \ --with-wine-libraries=${WINEDIR}/libs/wine:${WINEDIR}/libs/uuid:${WINEDIR}/libs/unicode [...snip...] $ make [...snip...] Until make executes, there seems to be no obvious problem (at least to my eyes), and even then, as the compilation happens, I get a nice file called "prog.o" written. However, as "winebuild" executes, I see the following: --- LD_LIBRARY_PATH="/home/kevin/wine/libs/wine:/home/kevin/wine/libs/unicode:$LD_LIBRARY_PATH" /home/kevin/wine/tools/winebuild/winebuild -fPIC -o prog.exe.spec.c --exe prog.exe -mcui prog.o -L/home/kevin/lib -L/home/kevin/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool could not open .def file for advapi32 --- I don't believe I even need anything from advapi32.dll.so, let alone most of the other Wine DLLs mentioned on the winebuild command line. Even if I hack the generated Makefile so as to remove mention of any Wine DLLs on the winebuild command line, winebuild still complains about not opening "...a .def file for ntdll". On a related note, the configure script generated by winemaker complains about test linking against -L${WINEDIR}/dlls -lntdll.dll and subsequent equivalent builtin DLLs such as -lkernel32.dll and -luser32.dll. My quick hack is merely to clone the symbolic links in ${WINEDIR}/dlls to add a "lib" prefix, vis: $ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* ) lrwxrwxrwx 1 kevin 18 Apr 1 15:29 ntdll.dll.so -> ntdll/ntdll.dll.so lrwxrwxrwx 1 kevin 18 Apr 1 15:29 libntdll.dll.so -> ntdll/ntdll.dll.so $ That keeps configure happy, but I wonder what I'm doing wrong. This is Wine built from CVS as of 20030401 (i.e. yesterday). Suggestions? Particularly for the wanted .def files. They're %^*&@# builtin DLLs! -- Kevin.

2 1

Re: What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Robert Shearman 02 Apr '03

02 Apr '03

> what happend to the stdole32.tlb patch that Robert sent around 22.1? It was rejected on the grounds that we shouldn't have binary files in CVS and we can't generate the .tlb files at the moment. Rob

1 0

Agent and threads
by Rein Klazes 02 Apr '03

02 Apr '03

Hi, Agent news/email client spawns a new thread for each news/mail retrieval command. Something in the last week causes these threads not to be waited upon, leaving hundreds of <defunct> wine processes lying around. I wonder if this is a known issue with the new thread implementation work in progress, or if it is worth investigating? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

CVS Statistics for academic research
by Riccardo 'Jack' Lucchetti 02 Apr '03

02 Apr '03

Hi all, this message was originally sent to Alexandre Juilliard; I am resending this to the list on his suggestion. I am a wine user and a regular mailing list lurker. Beside that, however, I earn my living as an academic econometrician (halfway between an economist and a statistician) and I was considering the idea of doing some econometric research on open source development. At least initially, I would focus on Wine, for a number or reasons, not least the fact that the wine project is largely unknown in the economics community. My problem is that the data I need for my analysis can be theoretically extracted from the mailing list archives, but this definitely exceeds my VERY limited perl skills. The data I'd need would, ideally, be in the form of a CSV file, a typical record of which would be DATE,PN,PLA,PLD,PCN,CN,CLA,CLD where PN = number of patches received on day DATE PLA = number of code lines added in patches PLD = number of code lines deleted in patches PCN = number of patches contributors (ie number of coders submitting patches on that particular day) CN = CVS commits CLA = number of lines added in CVS CLD = number of lines deleted in CVS Of course, the longer the time span the data cover, the larger my sample, the happier I am. I understand this isn't trivial. Is there anyone out there willing to help me? I know some perl, so maybe all I need is to get started somehow. Thanks in advance, and keep up the good work! ---------------------------------------------------------- Riccardo `Jack' Lucchetti Dipartimento di Economia Università di Ancona jack(a)dea.unian.it http://www.econ.unian.it/lucchetti

1 0

Re: Unexpected message from winebuild...
by juraj 02 Apr '03

02 Apr '03

Hi Kevin, I had similar problem with winemaker when I used winemaker's --wrap option. I hacked winemaker script (see attachment) and managed to get rid of "...could not open .def file for...". If you see it, the difference is that .dll extension was removed from libnames in makefiles. I.e. there is only kernel32 instead of kernel32.dll, and so on. This helped me to get rid of problem with missing .def file.The second adjustment is related to incorrect generation of wrapper exe spec.c file. However, I'm not sure it's correct hack (that's the reason I didn't post it to wine-patches yet) since I have still troubles with running wrapped application - simple hello world example. The problem I have is that GetProcAddress couldn't find the WinMain() of my hello world app. After a little debugging and inspection of .spec.c file it seems the problem is with winebuild and not with winemaker (__wine_spec_exports is resolved to NULL and that's bad...). But I need to investigate little more yet. Anyways I got information from #winehq irc channel that winemaker is beeing deprecated, and that I should try to use winegcc with winewrap instead. But I'm not sure whether these two guys are able to cope with wrapping. I wasn't able to find some documentation about them and winewrap alone throws segmentation fault in my current build (updated & build today, about 3 hours ago). --Juraj Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.63 diff -u -r1.63 winemaker --- tools/winemaker 27 Mar 2003 18:36:27 -0000 1.63 +++ tools/winemaker 31 Mar 2003 20:53:53 -0000 @@ -1001,7 +1001,7 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32", "user32" ]; push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; @@ -1650,7 +1650,6 @@ my $path=$_[0]; my $target=$_[1]; my $app_name=@$target[$T_NAME]; - $app_name=~ s/\.exe$//; return generate_from_template("$path${app_name}_wrapper.c","wrapper.c",[ ["APP_NAME",$app_name],

1 0

What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Uwe Bonnes 02 Apr '03

02 Apr '03

Hallo, what happend to the stdole32.tlb patch that Robertsent around 22.1? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: FindFirstFileExW
by Mike Hearn 02 Apr '03

02 Apr '03

I ran my test case on 98, and that produced a return value of 2 as well (same as XP), so unless my test case is stuffed up, I think this patch is correct. The test is attached, it's extremely simple. On Tue, 2003-04-01 at 16:37, Mike Hearn wrote: > > That sounds awfully much like the already pretty well-known Win9x vs. NT > > incompatibility in file not found GetLastError values. > > Awwww suckage. I thought that fix was too easy. File not found > differences are new to me. Well I have a little test case for this, I'll > email it home and find out what it returns on Win98. > > If so, then, how do you find out what version of windows we're supposed > to be emulating, so I can adjust the return value accordingly? > > > Please make sure this is indeed what we should do; I really think > > you'd break some Win9x programs when simply doing such a general replacement. > > Hmm, well, the old value appeared to break some NT programs. > > > As such, I suspect you did not "Correct" the error code returned; > > instead, you only fixed it "to please the other half" of Windows programs. > > ;-) > > Right. So we need to change the return value depending on the setting of > winver? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0