wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

Re: [Foxgui-users]Re: Wine fixes (1)
by Dimitrie O. Paun 22 Aug '03

22 Aug '03

On August 21, 2003 12:07 am, jeroen wrote: > > Ha! Well, I can't say that I disagree with you; however, if you're > actually shipping applications for Windows, you'd better test on the > real thing..... One thing the emulation won't tell you is whether > any oddball device driver issues crop up. This particularly happens > with OpenGL. I have had to add special directives to avoid hardware > accelerated OpenGL on Windows so that broken drivers may be circumvented. > > Interactions with other applications also must be tested; for example, > clipboard support. You will discover the weirdest things... It's a nice compliment (thank you!) to assume that Wine is such a good implementation of the Win32 API that one would assume to do no testing on Windows :) Unfortunately, we haven't gone that far (yet ;) ). Wine is good enough at the moment to allow for some development, but you will definitely run into problems, and you _will_ need to test the result on Windows, as you say. But regardless of utility, I still maintain a Wine port would be cool :) -- Dimi.

1 0

Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
by Jonathan Wilson 22 Aug '03

22 Aug '03

Looks good. This should enable apps like notepad to build out of the box on win32 with MingW or VC headers assuming port.h is copied over.

1 0

IPersistFile::Load() broken ? + WineLib queries
by Subhobroto Sinha 21 Aug '03

21 Aug '03

Respected members of the forum, I have a few queries, which I have tabulated under: First: (1) With Windows apps doing smoothly on Wine, I had thought of creating a little program which would resolve Windows shortcut (.lnk) files. The program behaved perfectly with NO glitches whatsoever with the Wine package of <20030217-23> which came with my SuSE 8.2 as RPM. I had also downloaded the Wine20030408 tarball, which I duly patched upto v20030813 (the latest), removed the installed RPM package and wineinstalled the source for Wine20030813. (The improvements made was immediately apparent, and I could run Norton 2000 Update Agent as well as install my own .msi packages !) However, my program (which resolved shortcuts) failed to work anymore ! Previously, to compile the source using WineLib(from Wine<20030217-23>) I had to make the following changes in my source code: (1) Replace IShellLink with IShellLinkA (2) Include the header "shlguid.h" With the latest WineLib(from Wine20030813), I did NOT have to make ANY changes to the original source however, but though the source compiled without any issues, it failed at the IPersistFile::Load() call ! To make debugging easier for you folks, I have prepared a ZIP Package called "WineShellDriverPak.zip" which contains the following software: (1) The source code "WineShellDriver.cpp" . (This compiles on VC6 AND WineLib without ANY modification) (2) The VC6 compiled EXE file "WineShellDriver.EXE". To make this program work, just pass the .lnk filename as command line arg, and if successful, it will write out the resolved path in a text file called "WineWorksResolvedPath.dat" (This ALSO failed to work under Wine20030813) (3) The previous "working" (it does NOT work anymore..) WineLib form ("linkresolve.exe.so") of this code. This had been compiled using Wine<20030217-23> which came with SuSE 8.2. It used to work fine. (4) A shortcut (Notepad.lnk) file for testing. It should resolve to "C:\WINNT\notepad.exe" Is it due to a BUG in the latest release, or did I do something wrong ? Second: (2) How do I REDUCE the size of WineLib compiled apps ? Those source code which compile to ~35KB using VC6, compile to ~900KB using WineLib. Currently, I have to "strip" the WineLib compiled apps, but often, this breaks them ! Any suggestions ? (3) How do I log the output to a file say "Winelog.log" of a command like: "$ wine --debugmsg +all winelibapp.exe.so -- commandline args" Redirection (>>) or pipes (|less) only captues the output given by "winelibapp.exe.so" and NOT that given by Wine. (I currently run Wine from the commandline using XTerm) Thank you for your time. Please keep up the good work ! Cheers Subhobroto Sinha ---------------------------- Help us to free ourselves! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Can someone take a look at msvcmaker for me?
by Steven Edwards 21 Aug '03

21 Aug '03

I have tried using MSYS perl and ActiveState perl and both give me the following error: isolation@PH33R /g/src/wine-dev/wine $ ./tools/winapi/msvcmaker Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 52. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 116. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 440. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1031. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1091. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1141. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1180. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1217. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1234. Execution of ./tools/winapi/msvcmaker aborted due to compilation errors. isolation@PH33R /g/src/wine-dev/wine

1 0

Re: patch 6
by puoti＠inwind.it 21 Aug '03

21 Aug '03

My email will never change. My email provider is the biggest in Italy, and it's very improbable that it will ever close, and even if I don't use it as an ISP any more, I will never change my email until I can use my current one. Of course, if you don't want email addresses in the source, just ignore that part of the patch.

1 0

Re: Build broken due to -lpthread
by Gerald Pfeifer 21 Aug '03

21 Aug '03

On Thu, 21 Aug 2003, Ulrich Spoerlein wrote: >> So perhaps we ought to use -lc_r instead of -lc and omit -lpthread on >> FreeBSD (or use -pthread)? > The "best" solution IMHO would be to have configure look for -lpthread > and put the value into @PTHREAD_LIBS@. Then the Wine port can just > s/-lpthread/${PTHREAD_LIBS}/g configure in the post-patch-target Please keep in mind that Wine should build as is (in CVS) without any FreeBSD-specific changes. I have been investing a lot of time and effort to reach that state and would like to keep it that way (and Alexandre agrees with that, as far as I know). As far as I can see, the ideal approach might be: o Check whether -lphtread exits/works and use it only, if it does. o Check whether -lc_r exists/works, and if it does, use that instead of -lc. These two are independent, and should work in general, that is, portably. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: patch 6
by Alexandre Julliard 21 Aug '03

21 Aug '03

"puoti\(a)inwind\.it" <puoti(a)inwind.it> writes: > Added my email next to my name in cmdlgtst /It.rc It's better to avoid putting email addresses in source files, they quickly become obsolete and nobody ever bothers to update them. Just put your name there, and people who want to mail you can look up your most recent address in the Changelog. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: evolution of file management
by Eric Pouech 21 Aug '03

21 Aug '03

in the process of separating ntdll from kernel32, one of the next hurdle if the implementation of NtCreateFile. Since it's rather a core API, some thoughts are needed. Moreover, there are a few shortcomings in current file handling we might want to address. The goal of this small RFC is to: 1/ gather all known shortcomings of current file implementation 2/ propose some solutions and roadmaps for the implementation feel free to add your own remarks to these lists. 1/ shortcomings --------------- 1.1) no dynamicity in DOS drive management: user should be able, in his/her session(1), to either change the mapping of a DOS drive letter, or mount a SMB share somewhere...) 1.2) mounting should be done session wide and not process wide, and of course shared across processes 1.3) ntdll and kernel32 are not separated regarding file management 1.4) devices (vxd and DOS) management is still a hack 1.5) it may be necessary to introduce a notion of filesystem for some operations (open, read, write, seek, close, dir_enum, ioctl) in order to support several FS (unix, smb...) 1.6) poor management of ejectable devices 1.7) short/long file name conversion should be consistent (across several processes in the same session, across several sessions) Note: (1) a session is linked to a running instance of the wineserver 2/ proposal ----------- 2.1 "path gates" (target: 1.1, 1.2, 1.3/partly, 1.4/partly, 1.6/partly) all file names will be handled using the NT-style: + DOS paths (C:\foo\bar) into \??\C:\foo\bar + network paths (\\station\foo\bar) into \??\UNC\station\foo\bar + DOS device names (CON) into \??\CON + NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0 + a VXD ?? (normally \\.\VFD) into \??\VFD the device concept will disappear and be replaced by a "path gate": in NT-Win32 name space, point where to convert from a NT-path to a Unix-path for example, assuming we have created a path-gate from \\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar will be transformed into the unix-path /mnt/windows/foo/bar the path-gate will hold the current options that the device currently does (case sensivity, fixed/removable...) path-gates will be stored in the server (they are session wide) management of VxD and devices could benefit from it: they could be path gates pointing to them selves (or nothing ?) 2.2 FS (target: 1.4/partly, 1.5/partly, 1.6/partly) I'm still wondering if we really need a FS (even a very simplistic one) in Wine 2.3 short/long file names (target 1.7) since current short file name management seems satisfactory, there's no need IMO to move short/long names conversion in the server -- Eric Pouech

5 8

GetLastError strangeness with FindClose
by Alex Pasadyn 21 Aug '03

21 Aug '03

Hi all, I observed a program that was bailing out with an absolutely baffling error message. I have traced it to its cause, but now I'm stuck. Basically, it was telling me that it had an error in FindNextFile of "success". I did a relay trace and found out that it was calling FindFirstFile, FindNextFile a bunch of times, FindClose, and then GetLastError. So, I put together a little test: #include <windows.h> #include <stdio.h> WIN32_FIND_DATA fd; HANDLE h; int main(int argc, char *argv[]) { h = FindFirstFile("*", &fd); if (h == INVALID_HANDLE_VALUE) { printf("Error finding first file: %d\n", GetLastError()); return 1; } printf("found file: %s\n", fd.cFileName); while (FindNextFile(h, &fd)) { printf("found file: %s\n", fd.cFileName); } FindClose(h); switch (GetLastError()) { case ERROR_NO_MORE_FILES: printf("all done!\n"); return 0; default: printf("Error finding next file: %d\n", GetLastError()); return 1; } return 1; } Now, on Windows, the output is: G:\testfnf>testfnf found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe all done! And with Wine the output is: [ajp@toaster testfnf]$ ~/wine/wine testfnf.exe found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe Error finding next file: 0 So, it looks like somewhere in FindClose Wine is resetting the last error. I started digging through there and the functions it calls but I was unable to find where it was getting reset. Can anyone shed some light on this? Is there any way to break on that value changing? Thanks, -ajp

6 10

Directx 8.1 sound bug
by puoti＠inwind.it 21 Aug '03

21 Aug '03

Anybody intrested may want to look at this http://bugs.winehq.com/show_bug.cgi?id=1670

1 0

Re: FAQ: When will Wine integrate an x86 CPU emulator?
by Mike Hearn 21 Aug '03

21 Aug '03

On Wed, 2003-08-20 at 21:42, Francois Gouget wrote: > + environment, Wine should only need minimal modifications. What > + performance you loose due to Wine running inside the emulator > + rather than natively, you gain in complexity inside of Wine. s/loose/lose/ - I'm not sure the second part of that sentance makes sense. What you lose in performance, you gain in complexity inside of wine? Shouldn't that be simplicity? Random tangent: at some point somebody needs to write an "msinterop" program that simply looks at the environment, the type of EXE file and then invokes: 1) Wine 2) Mono 3) Wine in QEMU 4) Wine and Mono in QEMU 5) Offers to download and install these programs if need be. Especially as we'll start seeing more and more programs that are partly unmanaged and partly managed (.net) code floating about, it's going to be harder to figure out what programs you need in order to make the exe run.

1 0

Re: stub for (undocumented) SHCreateLinks
by Dmitry Timoshkov 21 Aug '03

21 Aug '03

"Mike McCormack" <mike(a)codeweavers.com> wrote: > + 172 stdcall SHCreateLinks(long long long long long) > +HRESULT WINAPI SHCreateLinks( HWND hWnd, LPCSTR lpszDir, LPDATAOBJECT lpDataObject, > + UINT uFlags, LPITEMIDLIST *lppidlLinks) Then the spec entry should be 172 stdcall SHCreateLinks(long ptr ptr long ptr) -- Dmitry.

2 2

Re: patch 6
by Tom 21 Aug '03

21 Aug '03

puotiinwindit wrote: >this patch is licensed under the LGPL only (patch 5 is also LGPL only). >ChangeLog >Added Italian support to avifil32.dll >Fixed a typo in the english rc file in avifil32.dll > > > > > > Hi, umm.. the patches? :) Tom

1 0

Re: spec file syntax and automated generation
by Jon Griffiths 21 Aug '03

21 Aug '03

Hi Martin, > thanks for your info. I just wanted to forward my problem I posted on > wine-users - I do not know if wine-devel is the right place for this, so wine-devel is the place for any development issues, including problems with Winelib. Since someone may have the same problem(s) in the future, I'm also sending this to wine-devel (it serves as an issues archive for common problems). >I am currently having trouble building the DLLs of an application ported >from Win32 to Winelib - compiling, thanks to some hints from Dimi O. >Paun, now works fine, only(?) the final link __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Re: PATCH - some build fixes for w32api headers
by Alexandre Julliard 21 Aug '03

21 Aug '03

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > Changelog: Fixes for building with w32api headers on Mingw Why do you need to add stdarg.h everywhere? AFAICS it should be already included by the headers that require it. As a general note, it's a very good thing to test with other headers, but make sure that the problem is really on the Wine side before making changes. Being compatible with w32api is not a goal in itself for Wine, we have to be compatible with Microsoft; and if the Wine code works with the Microsoft headers but not with w32api then the bug is in w32api and should be fixed there. And in the case where the bug is really in Wine, this means there's an incompatibility in the Wine headers, since it builds fine with them and it shouldn't. So this means we have to fix the Wine headers too, not only the C files. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Small spanish keyboard fix
by Dmitry Timoshkov 21 Aug '03

21 Aug '03

"José Manuel Ferrer Ortiz" <jmfo1982(a)yahoo.es> wrote: > Hi again, attached you have a patch to the spanish > keyboard that adds support to write the Euro sign > using <Alt-GR> + <E>, as seen in newer spanish > keyboards. XFree86 4.3.0 has no this, which however should not prevent the Euro sign to work. Moreover, XFree86 project tends to leave only two characters per keysym for all keyboard layouts, not to add new ones. -- Dmitry.

1 0

uClibc and wine
by Felipe Wilhelms Damasio 20 Aug '03

20 Aug '03

Hi, I couldn't compile wine using the latest (0.9.20) version of uClibc. I installed the devel stuff and am using the /usr/i386-uClibc/gcc on my path, and then I get: gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -DDLLDIR="\"/mnt/usr/lib/wine\"" -D_REENTRANT -o port.o port.c port.c:597: warning: type defaults to `int' in declaration of `wchar_t' port.c:597: syntax error before '*' token port.c: In function `wine_rewrite_s4tos2': port.c:601: `str4' undeclared (first use in this function) port.c:601: (Each undeclared identifier is reported only once port.c:601: for each function it appears in.) make[1]: *** [port.o] Error 1 make[1]: Leaving directory `/home/felipewd/elipse/cvs/wine-20030115/library' make: *** [library] Error 2 If I change my path to use the default gcc location, it compiles fine. Does anybody have any ideas? Thanks in advance, Felipe

2 1

Re: winegcc
by puoti＠inwind.it 20 Aug '03

20 Aug '03

I'm trying to compile the bidi test progam posted on this list by Shachar Shemesh, you can find his post and his program here: http://www.winehq.org/hypermail/wine-devel/2003/08/0175.html this mail also got to wine-users, sorry about that.

2 1

Re: FAQ: Will there be a Windows version of Wine?
by Steven Edwards 20 Aug '03

20 Aug '03

Thanks Francois, I have been meaning to update some of the docs to answer these questions for a while. You put it much better and more to the point then I would have =). Steven --- Francois Gouget <fgouget(a)free.fr> wrote: > > > Changelog: > > * documentation/faq.sgml > > Tweak 'Will there be a Windows version of Wine?': > - Add a pointer to the MinGW project > - Fix the ReactOS case > - Explain the rational behind these porting projects > > > Index: documentation/faq.sgml > =================================================================== > RCS file: /home/wine/wine/documentation/faq.sgml,v > retrieving revision 1.13 > diff -u -r1.13 faq.sgml > --- documentation/faq.sgml 28 Jul 2003 19:06:10 -0000 1.13 > +++ documentation/faq.sgml 20 Aug 2003 20:24:25 -0000 > @@ -485,19 +575,26 @@ > </question> > <answer> > <para> > - Some people are working on getting Wine code to compile on Windows. > + Some people are working on getting Wine code to compile on Windows > + using one of the following projects as a basis: > </para> > <itemizedlist spacing="compact"> > <listitem> > <para> > - Cygwin (<ulink url="http:/www.cygwin.com"> > - http://www.cygwin.com/</ulink>) > + Cygwin > + (<ulink url="http:/www.cygwin.com/">http://www.cygwin.com</>) > + </para> > + </listitem> > + <listitem> > + <para> > + MinGW > + (<ulink url="http:/www.mingw.org/">http://www.mingw.org</>) > </para> > </listitem> > <listitem> > <para> > - Reactos (<ulink url="http://www.reactos.com/"> > - http://www.reactos.com/</ulink>) > + ReactOS > + (<ulink url="http://www.reactos.com/">http://www.reactos.com</>) > </para> > </listitem> > </itemizedlist> > @@ -505,9 +602,21 @@ > There's some progress, so a Wine version that's usable on Windows > might be available at some time. > </para> > + <para> > + Part of the rational for these projects is to find out areas where > + Wine portability is lacking. This is especially true of the > + ReactOS project which is a reimplementation of the Windows kernel > + and should thus be able to reuse most of Wine dlls. > + </para> > + <para> > + Another reason for pursuing these projects is to be able to > + replace a single Windows dll with its Wine counterpart. Besides > + being a good test for the Wine dll, this lets us detect cases where > + we made incorrect assumptions about how the dlls interact. > + </para> > </answer> > </qandaentry> > - > + > </qandadiv> > <qandadiv id="What-do-I-need-in-order-to-use-Wine"> > <title>What do I need in order to use Wine?</title> > > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > It really galls me that most of the computer power in the world > is wasted on screen savers. > Chris Caldwell from the GIMPS project > http://www.mersenne.org/prime.htm > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

PATCH try 2 - build libwine_unicode with w32api headers
by Steven Edwards 20 Aug '03

20 Aug '03

Ok now with clean w32api headers from CVS we can build unicode. This shouldnt break cross compiling or the *nix build but if it does please let me know. Also you can change WINVER >= 0x0500 to whatever as long as it is higher. Thanks Steven Changelog: Fix building libwine_unicode with w32api headers. Index: Makefile.in =================================================================== RCS file: /home/wine/wine/libs/unicode/Makefile.in,v retrieving revision 1.5 diff -u -r1.5 Makefile.in --- Makefile.in 27 Jun 2003 19:02:23 -0000 1.5 +++ Makefile.in 20 Aug 2003 06:13:25 -0000 @@ -4,7 +4,7 @@ VPATH = @srcdir@ LIBRARY = wine_unicode SOVERSION = 1 -EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT +EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT -DWINVER=0x0500 CODEPAGES = \ 037 \ Index: unicode.h =================================================================== RCS file: /home/wine/wine/include/wine/unicode.h,v retrieving revision 1.20 diff -u -r1.20 unicode.h --- unicode.h 27 Jun 2003 19:02:23 -0000 1.20 +++ unicode.h 20 Aug 2003 07:36:07 -0000 @@ -24,6 +24,7 @@ #include <stdarg.h> #include "windef.h" +#include "winbase.h" #include "winnls.h" /* code page info common to SBCS and DBCS */ __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 2

Re: spec file syntax and automated generation
by Jon Griffiths 20 Aug '03

20 Aug '03

Hi, <disclaimer> I havent read the wine-user posts.... >1. The winebuild manpage only mentions ptr, str, wstr, long and double >as valid Win32 function argument size information - is the amount and >kind of symbols really important, or is it just the amount of used stack >space? the type is used for dumping of parameters so its good to have it right. >I am not too familiar with assembler, but I would assume the first is >right, since two arguments are pushed on the stack, each using 32bit. Correct. Logical types are irrelevant, only the physical size matters. % __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

is anyone running windows 95, windows 98, windows ME or windows 2003?
by Jonathan Wilson 20 Aug '03

20 Aug '03

If so, I need you to run some kind of PE dumper that can dump exports (such as dumpbin from MS with the /exports switch on user32.dll and gdi32.dll from your version and send me the results, along with details of which version of windows you are running. I want this info because I am compiling a list of the different versions of windows and which functions are exported by user32.dll and gdi32.dll in each version.

4 3

Re: [Foxgui-users]Re: Wine fixes (1)
by Dimitrie O. Paun 20 Aug '03

20 Aug '03

On 20 Aug 2003, Doug Henry wrote: > > Added this one too. [As to why you'd want to run FOX under Wine while it > > runs natively under X11, I don't know....] > > > > If you cross-compile for windows under linux, it is useful to test under > wine. Its more convenient than rebooting or going to another machine > just for simple testing. Top 10 reasons you want Fox ported to Wine: 10. Windows sux 9. Microsoft is evil 8. Test windows features without rebooting (as Doug mentioned) 7. Keep development on Linux 6. Run valgrind on the Windows port 5. Make sure the Win32 part is portable to multiple implementations 4. Help find missing features/problems/etc. in Wine 3. Some people may prefer the Wine widgets to the GTK+ ones 2. wxWindows is already ported to Wine, Fox needs that too! ;) and the number one reason is: 1. It is just cool!!! (what geek can resist this sort of virtualization? :)) -- Dimi.

1 0

Re: winegcc
by puoti＠inwind.it 20 Aug '03

20 Aug '03

I've just updated via cvs, and I get this [ivan@my Wine]$ winegcc -mwindows 01-biditest.c /tmp/wappZjLo5B.spec.o(.text+0x1010a): In function `__wine_exe_main': : undefined reference to `WinMain' collect2: ld returned 1 exit status Error: gcc failed. Error: winewrap failed. [ivan@my Wine]$ winewrap returns a seg fault.

3 2

LPT1 support in DOSFS_OpenDevice
by E Lea 20 Aug '03

20 Aug '03

I'm trying to add LPT1 support to DOSFS_OpenDevice. The software that requires this functionality controls a parallel port plotter by sending LOGO-style ASCII commands. I have based my attempts heavily on the serial port support, although I don't think I really know what I'm doing. Can anyone explain to me what's required? I have tried to implement a server call to create a file descriptor to /dev/lp0 (read from ~/.wine/config) and return a handle to it, but after that (perhaps when wine starts using the handle) both the wine and wineserver processes die. I don't really understand handles and how they are used. Are more functions required other than a simple create_parallel()? How do handles work?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel