- Wine-Devel - list.winehq.org

Re: What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Robert Shearman April 2, 2003

April 2, 2003

> 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 April 2, 2003

April 2, 2003

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 April 2, 2003

April 2, 2003

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 April 2, 2003

April 2, 2003

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 April 2, 2003

April 2, 2003

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 April 2, 2003

April 2, 2003

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

Wine's goals
by Francois Gouget April 2, 2003

April 2, 2003

I propose the following WineHQ patch to present and clarify Wine's goals. I'm submitting this to wine-devel first to get a feel of whether that would be a good addition and whether that sounds reasonable and accurate enough. Index: templates/en/about.template =================================================================== RCS file: /home/wine/lostwages/templates/en/about.template,v retrieving revision 1.7 diff -u -r1.7 about.template --- templates/en/about.template 24 Mar 2003 22:49:03 -0000 1.7 +++ templates/en/about.template 30 Mar 2003 02:35:46 -0000 @@ -29,4 +29,70 @@ <a href="mailto:julliard(a)winehq.com">julliard(a)winehq.com</a>. For a list of current developers, see the <a href="?page=who">Wine Who's Who</a>.</p> + +<h1>Wine's Goals</h1> + +<p>As mentionned in many places, the primary goal of Wine is to make it +possible to run Windows applications on x86-based Unix systems. But there is +often confusion as to what this covers. So let's clarify things a bit: + +<ul> + <li>Wine does not try to be a better Windows than Windows. What this means + is that Wine will not try to extend, improve or 'fix' the Windows API in + an attempt to lure developpers into using it. While we think that it is + important to provide a way to reuse the legacy Windows applications that + are out there, we feel that for new developments there are better APIs + than Win32. + + <li>Wine Is Not a (CPU) Emulator. So no, we will not integrate a CPU + emulator in Wine any time soon. However we will do what we can to make it + possible to integrate Wine into a CPU emulation environment that would + provide the regular Unix services that Wine depends on. In such a scheme + both Wine and the Windows application would be run in that environment. + Two candidates that come to mind are <a + href="http://fabrice.bellard.free.fr/qemu/">QEMU</a> and + <a href="http://www.transitives.com/tech_overview.htm">Dynamite</a> from + <a href="http://www.transitives.com/">Transitives Technologies</a>. + + <li>Wine's goal is to provide replacements for just those DLLs and APIs + that are needed to run Windows applications. This means that we will not + provide replacements for DLLs that are always shipped together with an + application. This also means that implementing an API that no application + ever uses is not a priority. Similarly, until there are applications out + there that use the Win64 API, it will not be a priority. That being said, + we will certainly try to keep our options open and to improve our API + coverage as we can. + + <li>Making it possible to use Windows device drivers or VxDs on Unix is not + part of Wine's goals. Device drivers don't use the same API that Windows + applications do, and run in ring 0 instead or ring 3. To make it possible + to use them on Unix, one would have to hack the kernel, implement a + completely different API. In other words, this would be a completely + separate project. However, if you want to reuse Windows drivers on + non-Microsoft operating systems we recommend that you have a look at + <a href="http://www.reactos.com/">ReactOS</a>. + + <li>Wine is not an operating system or a desktop environment. So writing + device drivers, file or window managers that look like Windows, are not + part of Wine's goals. If you are interested in those, the best would be to + contribute to the <a href="http://www.kernel.org/">Linux</a>, + <a href="http://www.freebsd.org/">FreeBSD</a> or + <a href="http://www.reactos.com/">ReactOS</a> kernels, or to the + <a href="http://www.gnome.org/">Gnome</a> or + <a href="http://www.kde.org/">KDE</a> desktop environments. You will get + the added benefit that your contribution will then be usable by everyone, + not just by Wine users. + + <li>Wine's focus is on Unix operating systems, and to some extent Linux + because that is what most of our developpers are using. However we welcome + ports to other architectures such as + <a href="http://www.reactos.com/">ReactOS</a> or + <a href="http://bewine.beunited.org/">BeWine</a>, and will try to make + it possible for them to reuse as much of Wine as possible. After all, + reimplementing the Windows API is a big enough task that it is best if we + can all work together on it. +</ul> + + <p> </p> + -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

2 2

Wine
by Tuch April 2, 2003

April 2, 2003

I recently tried to install wine from src and ran into a problem. when it prompted me to enter the root password to do a "make install" I did so, and it proceeded to tell me that I entered an incorrect password. I tried this several times realizing it is possible to enter the password incorrectly, but each time gave the same result. Now I know the password was correct as I am the only user of this box and I installed Slackware 9.0 myself. As a request of your install app, I am e-mailing you this. Thanks Bill

1 0

Re: valgrind for WINE
by Eric Pouech April 1, 2003

April 1, 2003

Adam Gundy wrote: > a new version of the valgrind patch has been uploaded to sourceforge - > the only change is a small fix to the signal handling which should > prevent "signal handler frame" uninitialized errors. > > http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… > > comments? bug reports? success stories? did test it yet. As a global note, I think it would be appreciated breaking the patch in smaller bits... it makes it easier to track/follow what happens. For example, I don't see any reason for including the msvcrtd patches into this patch I think that Alexandre is currently integrating (bit per bit) your changes into wine. look for the patch about zeroing the request zones (which is another implementation of your structure packing), as well as local availability of the thread PID on a more minor side of things, I would keep the VALGRIND prefix in heap.c last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind) how are your patches doing on the "other side" (I mean valgrind's) ? A+ -- Eric Pouech

2 1

Re: resent: menu capture tracking fix
by Alexandre Julliard April 1, 2003

April 1, 2003

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > [I don't know why this wasn't applied, without any comment; > resending it] You don't really expect me to apply a patch that adds a #ifdef FUBAR_CODE, do you? -- Alexandre Julliard julliard(a)winehq.com

1 0