wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: debugger fix
by Jon Griffiths 05 Feb '01

05 Feb '01

> So, does anyone have a hint on how to go about supporting > VirualProtectEx/VirtualQueryEx on other provesses? Looking into this, the VirtualEx functions work within the address space of the target process. At user level I can't see any way to support this from the sever or any other process external to the target. What I had in mind was a service thread request that would have the target process preform the call itself. Is there any reason _not_ to use the service thread of the target process to perform cross-process virtualAlloc/Protect etc? Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

1 0

The printer setup dialog
by Duane Clark 05 Feb '01

05 Feb '01

Howdy, Since I see there has been a fair amount of activity on the printer stuff lately, I thought I would try submitting this patch to hopefully fix some things in the printer setup dialog box. I have been using this patch unchanged for about six months, on a couple of different applications under wine. The patch contains two chunks. The first chunk attempts to fix these problems in the Paper Size and Source combo boxes: 1) Every time the printer setup dialog is opened, the settings are set back to garbage settings. 2) If the paper size or source is changed, and then the printer is changed, the new printer does not get the new size and source settings even though it appears to from the dialog. The second chunk simply attempts to make the Landscape/Portrait buttons do something. They were there and could be clicked on, and all the supporting code for actually printing in a landscape orientation was there, but the actual code for making the buttons invoke something was for some mysterious reason missing. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.34 diff -u -r1.34 printdlg.c --- dlls/commdlg/printdlg.c 2001/01/22 02:13:58 1.34 +++ dlls/commdlg/printdlg.c 2001/02/05 00:13:50 @@ -373,8 +373,30 @@ /* query the dialog box for the current selected value */ Sel = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETCURSEL, 0, 0); if(Sel != CB_ERR) { - oldWord = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETITEMDATA, Sel, - 0); + /* we enter here only if a different printer is selected after + * the Print Setup dialog is opened. The current settings are + * stored into the newly selected printer. + */ + oldWord = SendDlgItemMessageA(hDlg, nIDComboBox, CB_GETITEMDATA, + Sel, 0); + if (dm) { + if (nIDComboBox == cmb2) + dm->u1.s1.dmPaperSize = oldWord; + else + dm->dmDefaultSource = oldWord; + } + } + else { + /* we enter here only when the Print setup dialog is initially + * opened. In this case the settings are restored from when + * the dialog was last closed. + */ + if (dm) { + if (nIDComboBox == cmb2) + oldWord = dm->u1.s1.dmPaperSize; + else + oldWord = dm->dmDefaultSource; + } } if (nIDComboBox == cmb2) { @@ -873,6 +895,16 @@ break; } + case rad1: /* Paperorientation */ + if (lppd->Flags & PD_PRINTSETUP) + lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + break; + + case rad2: /* Paperorientation */ + if (lppd->Flags & PD_PRINTSETUP) + lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + break; + case cmb1: case cmb4: /* Printer combobox */ if (HIWORD(wParam)==CBN_SELCHANGE) {

1 0

Re: PATCH: "Manual" trays for ppd
by Huw D M Davies 04 Feb '01

04 Feb '01

On Sat, Feb 03, 2001 at 07:21:54PM +0100, Marcus Meissner wrote: > Hi, > > The ppd also has Tray1,Tray2,Tray3 ... Now where should those map to? I think these should go to DMBIN_USER, DMBIN_USER+1, etc. So if the lookup of the standard names fails, we just start allocating bin numbers from DMBIN_USER. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1(a)physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK

1 0

Re: debugger fix
by Ulrich Weigand 04 Feb '01

04 Feb '01

Eric Pouech wrote: > > Could you send me the libwinspool.drv.so file that objcopy > > is choking on? I'd like to look whether there's something > > strange with that. > here it is... (I've used libpsapi.so instead, because it's smaller, but > effects are the same) Well, one difference I see is that yours has a .rel.stabs section, while mine doesn't. Now I don't quite understand why stabs need to be relocated, but I guess this could be a source of confusion. In any case, after I strip the stabs data using objcopy --strip-debug, I can subsequently use objcopy -N without problems. The problem might be caused by the objcopy -L step not correctly updating the debug info. Could you try adding a --debugging argument to objcopy in both localize_imports and strip_imports? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

Re: psdrv: map Courier New to Courier
by gerard patel 04 Feb '01

04 Feb '01

At 05:40 PM 3/2/01 +0600, you wrote: <snip> >I cannot get this patch to apply. I've tried it with a CVS pull from >earlier today and one from 1/29. With both, I get: > >patching file include/winspool.h >Hunk #1 FAILED at 957. >1 out of 1 hunk FAILED -- saving rejects to file include/winspool.h.rej <snip> This file is supposed to display where the problem is. If it's not obvious, the problem is with tab expansion - it happens with cut & paste from Netscape. Try with patch -l Gerard

2 1

Re: debugger fix
by Eric Pouech 03 Feb '01

03 Feb '01

Ulrich Weigand wrote: > > Eric Pouech wrote: > > > thanks for taking a look at it. unfortunately, I couldn't really test > > your patches. when run, roughly 4/5 of the .so files did would generate > > this type of error > > ../../tools/strip_imports libwinspool.drv.so > > objcopy: styEor1D: File truncated > > Strange. Could you try using 'strip' instead of 'objcopy' in > strip_imports? (Only there, in localize_imports it must be objcopy.) tested with binutils 2.9.1 and 2.10.1 and I get the same error... even when changing objcopy by strip did some strace on the operation, and it seems that there's some mixup in the section reading / writing > > From a pure conceptual point of view, the build process definitively > > grows more and more complex (I'm not sure Alexandre would accept another > > tool or an extension to winebuild for it). However, if I got what you intend > > correctly, it means that an import symbol would be defined as: > > - no trace in stabs > > - listed in .dynamic section, as a local symbol. > > No, I mean no trace in stabs *and* no dynamic symbol either. [long explanation deleted] thanks, that what I thought at first, but got abused by the first outputs made out of the patch... > However, my method has admittedly also a serious disadvantage: > it makes heavy use of GNU-specifc tools (and apparently even > there are version problems ...). :-( I'm not sure it's a version issue. looks more I have something broken somewhere... still have to figure out where :-( however, it would be great if someone else could try Ulrich's patch to see if I'm the only one with BAAAAAAAAD results... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

Re: debugger fix
by gerard patel 03 Feb '01

03 Feb '01

At 06:24 PM 3/2/01 +0000, you wrote: <snip> >however, it would be great if someone else could try Ulrich's patch to see >if I'm the only one with BAAAAAAAAD results... I tested Ulrich's patch on current Cvs on a vanilla Suse 7.0 (gcc 2.95.2, binutils 2.9.5) The patch applied all right, built fine (I had to chmod +x strip_import though). I can run ForteFreeAgent with the patched Wine; the debugger starts all right and I can go to a breakpoint using the <dll name in uppercase>.<api> trick. Gerard

2 1

Re: PATCH: afm loader
by Joerg Mayer 03 Feb '01

03 Feb '01

Moin Marcus, you codeed some thing like this in a few places: > + char afmfn[256]; > + strcpy(afmfn,afmdir); directories and filenames may be longer than 256 charaters. If you use such a value you should at least use strncpy or use FILENAME_MAX from stdio.h (if that's the right one). Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

ReadFile() and WriteFile() choke on non-zero lpOverlapped.
by Eric Kohl 03 Feb '01

03 Feb '01

Hello! I'm currently debugging a database-application that uses the M$ Jet Engine 3.5. This db-engine does not behave very well. It opens an exisisting database-file (FILE_FLAG_OVERLAPPED is *not* set) and reads or writes using calls to ReadFile() and WriteFile() with non-zero lpOverlapped pointers. In this case calls to ReadFile() or WriteFile() return FALSE. IMO ReadFile() and WriteFile() should check whether FILE_FLAG_OVERLAPPED is set. Unfortunately there is no method to retrieve the full file attributes from wineserver. Is a new server call required? Best regards, Eric Kohl

2 1

Microsoft Wine????
by Owen Rudge 03 Feb '01

03 Feb '01

Hi, This is what happens when you use the native Windows SHELL32.DLL and choose About Wine from the System menu...... <see http://www16.brinkster.com/orudge/mswine.gif for screenshot> Hmmmm..... has Microsoft taken over Wine too...... :-) The app I was running, BTW, is something I've made called Notebook, and seems to run fine. Owen Rudge http://www.osplus.co.uk/ http://www.owenrudge.com/ http://www.owenrudge.co.uk/ http://www.transporttycoon.uk.tt/ http://www.savedgamemanager.uk.tt/

1 0

ReadFile() and WriteFile() choke on non-zero lpOverlapped.
by Eric Kohl 03 Feb '01

03 Feb '01

1 0

Re: psdrv: map Courier New to Courier
by Ian Pilcher 03 Feb '01

03 Feb '01

Huw D M Davies wrote: > > Great! Well the Windows 2000 PS driver stores the font sub table > under the value name "TTFontSubTable" in the printer driver's > PrinterDriverData registry key. To do this we need to implement > Get/SetPrinterData (if you give me a couple of days I'll do it). The > data associated with TTFontSubTable is just a set of 2n \0 > terminated strings the final one terminated by 2 \0 > (i.e. REG_MULTISZ). The actual configuring should go on in the > printer setup property sheet. Hmmm, fancy learning a little of the > Win32 api? > I think I can probably handle reading the registry. (Although from what little I've seen of the Win32 API, even that could be a night- mare.) I think we should also allow the Wine config file to override what's in the registry. > > hdavies(a)codeweavers.com should work. Could you also send me the > output of --debugmsg +psdrv. Note if you're using ghostscript to > process the output then the fonts will look about 15% larger, that's > because GS's fonts are rather bigger than Adobe's and you're probably > using Adobe's AFMs. Other than that then I'm seeing Wine's Courier to > be about another 15% larger than the output from Windows. > I think I may have overstated how large Courier is printing, at least in relation to other Type 1 fonts. I had forgotten that the TrueType fonts I have converted to Type 1 tend to print somewhat smaller than the Adobe/Ghostscript fonts. (I do see the problem on both my Ghost- script-driven printer at home and the PostScript printers at work.) Since people seem to use Arial and Courier a lot, the problem is emphasized; content that uses monospaced fonts also tends to suffer more when it is unexpectedly wrapped. So I think its mixing the two that makes things look really odd. For my particular situation, mapping everything to the "TrueType" fonts is probably the way to go, so I'll be motivated to get the user-defined mapping working. Which leads me to another, more dangerous, thought. It seems to me that life would be simpler for everyone if we could bring some consistency to the way that Wine's display and print subsystems work with fonts. What about a section in the configuration file that related Windows, X, and PostScript font names? In the old style, I would have suggested something of the form: Windows Font = X LFD, PostScript font name This would seem to be relatively straightforward to implement, and it would bring a small measure of sanity to the area. (I currently have both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and the PostScript driver don't agree on what the font should be called!) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 2

Re: Notes and Java test on 20010112.
by David.Goodenough＠dga.co.uk 02 Feb '01

02 Feb '01

Well the good news is that this patch does indeed fix the Callout problem. Unfortunately we are then back to the original font problem, where (at least with the Sun JRE) we just get black squares instead of characters. The IBM JRE still has problems and never even displays the frame for the characters, let alone the characters. But this may still be due to the same underlying problem. Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> on 28-01-2001 11:43:03 PM To: gerard.patel(a)asi.fr (gerard patel) cc: David Goodenough/DGA/GB, wine-devel(a)winehq.com Subject: Re: Notes and Java test on 20010112. Gerard Patel wrote: > I did not include the trace as it's rather large (I can mail it to you > if you want...) but what happens is clear enough : the main exe loads > implicitely KERNEL32 but not USER - USER is loaded implicitely > by a DLL loaded by LoadLibrary. > So when the kernel initialisation is done, USER is not yet loaded. > It's unusual but seems perfectly valid IMO. > > What about adding a specific Wine call from User to Kernel to trigger the > initialization when USER is loaded ? (maybe there is already an > undocumented one - you are the undisputed master here :-)) Hmmm. Strictly speaking, if an app dynamically loads USER, it can also dynamically *unload* USER; we'd have to take care that we invalidate the Callout pointers if this happens. What do you think about the following solution? It just checks whenever any DLL is loaded or unloaded, whether the Callout pointers need to be updated ... Bye, Ulrich diff -ur wine-cvs/if1632/thunk.c wine-uw/if1632/thunk.c --- wine-cvs/if1632/thunk.c Wed Jan 3 22:51:30 2001 +++ wine-uw/if1632/thunk.c Mon Jan 29 00:35:49 2001 @@ -166,7 +166,7 @@ NE_MODULE *pModule; hModule = GetModuleHandleA( "user32.dll" ); - if ( hModule ) + if ( hModule && !Callout.PeekMessageA ) { #define GETADDR( name ) \ *(FARPROC *)&Callout.name = GetProcAddress( hModule, #name ) @@ -185,10 +185,24 @@ GETADDR( MessageBoxW ); #undef GETADDR } - else WARN("no 32-bit USER\n"); + if ( !hModule && Callout.PeekMessageA ) + { + Callout.PeekMessageA = NULL; + Callout.GetMessageA = NULL; + Callout.SendMessageA = NULL; + Callout.PostMessageA = NULL; + Callout.TranslateMessage = NULL; + Callout.DispatchMessageA = NULL; + Callout.RedrawWindow = NULL; + Callout.WaitForInputIdle = NULL; + Callout.MsgWaitForMultipleObjects = NULL; + Callout.WindowFromDC = NULL; + Callout.MessageBoxA = NULL; + Callout.MessageBoxW = NULL; + } pModule = NE_GetPtr( GetModuleHandle16( "USER.EXE" ) ); - if ( pModule ) + if ( pModule && !Callout.FinalUserInit16 ) { #define GETADDR( var, name, thk ) \ *(FARPROC *)&Callout.var = THUNK_GetCalloutThunk( pModule, name, \ @@ -201,5 +215,12 @@ GETADDR( UserSignalProc, "SignalProc32", word_lllw ); #undef GETADDR } - else WARN("no 16-bit USER\n"); + if ( !pModule && Callout.FinalUserInit16 ) + { + Callout.FinalUserInit16 = NULL; + Callout.InitThreadInput16 = NULL; + Callout.UserYield16 = NULL; + Callout.DestroyIcon32 = NULL; + Callout.UserSignalProc = NULL; + } } diff -ur wine-cvs/loader/module.c wine-uw/loader/module.c --- wine-cvs/loader/module.c Tue Jan 16 00:29:27 2001 +++ wine-uw/loader/module.c Mon Jan 29 00:30:20 2001 @@ -1432,6 +1432,9 @@ /* decrement the dependencies through the MODULE_FreeLibrary call. */ pwm->refCount++; + /* Update the kernel Callout tables */ + THUNK_InitCallout(); + RtlReleasePebLock(); SetLastError( err ); /* restore last error */ HeapFree ( GetProcessHeap(), 0, filename ); @@ -1526,6 +1529,9 @@ HeapFree( GetProcessHeap(), 0, wm->short_filename ); HeapFree( GetProcessHeap(), 0, wm ); } + + /* Update the kernel Callout tables */ + THUNK_InitCallout(); } /*********************************************************************** diff -ur wine-cvs/miscemu/main.c wine-uw/miscemu/main.c --- wine-cvs/miscemu/main.c Wed Jan 10 02:42:49 2001 +++ wine-uw/miscemu/main.c Mon Jan 29 00:36:05 2001 @@ -34,7 +34,6 @@ MESSAGE( "Cannot load user32.dll\n" ); ExitProcess( GetLastError() ); } - THUNK_InitCallout(); if ((instance = NE_StartMain( main_exe_name, main_exe_file )) < 32) { diff -ur wine-cvs/scheduler/process.c wine-uw/scheduler/process.c --- wine-cvs/scheduler/process.c Sun Jan 28 18:58:09 2001 +++ wine-uw/scheduler/process.c Mon Jan 29 00:36:17 2001 @@ -346,9 +346,6 @@ MODULE_DllProcessAttach( NULL, (LPVOID)1 ); RtlReleasePebLock(); - /* Get pointers to USER routines called by KERNEL */ - THUNK_InitCallout(); - /* Call FinalUserInit routine */ if (Callout.FinalUserInit16) Callout.FinalUserInit16(); -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

Re: psdrv: map Courier New to Courier
by Dmitry Timoshkov 02 Feb '01

02 Feb '01

Gavriel State <gav(a)transgaming.com> wrote: >It's at http://opensource.corel.com > >It hasn't been updated in quite a while, and the last import from >WineHQ was back in December '99, I believe. In addition to the >font/printing work, there may still be a few other outstanding fixes >that haven't made it into the Wine tree - but the only way to tell >is probably going to be manual inspection of the diffs. Yes, this is a pain to do for instance cvs log -N corelwine/windows/defwnd.c >defwnd.c.log then inspect it for some interesting log message, then do cvs log -N -r1.3 corelwine/windows/defwnd.c >defwnd.c.patch cvs diff -u -r 1.2 -r 1.3 corelwine/windows/defwnd.c >>defwnd.c.patch especially if the patch actually changed several files.

1 0

Re: psdrv: map Courier New to Courier
by Ian Pilcher 02 Feb '01

02 Feb '01

Gavriel State wrote: > > Just FYI, the corelwine tree has support for psdrv font mapping that > you might be able to use - it uses the wine config file rather than > the registry to store font aliases, but as I recall it was a pretty > minor change in the psdrv code. > This may be a stupid question, but where is the Corel Wine tree? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

3 2

Re: fix teb crash
by Andreas Mohr 01 Feb '01

01 Feb '01

On Thu, Feb 01, 2001 at 12:32:34AM +0100, gerard patel wrote: > At 12:12 PM 31/1/01 +0100, you (amohr(a)codeweavers.com) wrote: > >The terminated thread had done a SendMessage before, however, and when > >the receiving thread tried to reply to that SendMessage, the sending thread > >was gone, which resulted in a crash as queue->teb was invalid. > > <snip> > > I remember having looked at some crash akin to this one; I had > never the time to find the proper fix, but my impression was rather > that the problem was that Wine don't destroy windows when a thread > is terminated through TerminateThread(). Nope, I don't think so. The part doing this is: [cleanup] Call kernel32.443: GlobalFree(403b4864) ret=010043cd fs=02c7 Ret kernel32.443: GlobalFree() retval=00000000 ret=010043cd fs=02c7 Call kernel32.273: FreeResource(0101225c) ret=01004730 fs=02c7 Ret kernel32.273: FreeResource() retval=00000000 ret=01004730 fs=02c7 Call user32.500: SendMessageA(00000138,00000fa1,00000001,00000000) ret=01004777 fs=02c7 trace:relay:WINPROC_CallWndProc (wndproc=0x40751990,hwnd=00000138,msg=WM_USER+0ba1,wp=00000001,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_USER+0ba1,wp=00000001,lp=00000000) Call kernel32.685: TerminateThread(00000048,00000000) ret=01002f65 fs=008f err:win:UserSignalProc uCode: 32 err:system:UserSignalProc Ret kernel32.685: TerminateThread() retval=00000001 ret=01002f65 fs=008f Call user32.188: EndDialog(00000138,00000001) ret=0100307f fs=008f trace:dialog:EndDialog 0138 1 trace:relay:WINPROC_CallWndProc (wndproc=0x40722ac0,hwnd=00000228,msg=WM_KILLFOCUS,wp=00000138,lp=00000000) trace:win:GetClientRect (0,0 - 75,21) trace:relay:WINPROC_CallWndProc (wndproc=0x40751990,hwnd=00000138,msg=WM_CTLCOLORBTN,wp=0000005c,lp=00000228) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_CTLCOLORBTN,wp=0000005c,lp=00000228) trace:relay:WINPROC_CallWndProc (wndproc=0x1002f20,hwnd=00000138,msg=WM_CTLCOLOR This is a dialog with a progress bar, BTW. So it seems the progress bar is a separate thread of the dialog, which is probably also responsible for extracting files. And this worker thread does a SendMessage to the original thread, which then does a TerminateThread of the sending thread and an EndDialog to close the whole dialog. And after that the window proc returns and Wine wants to send the window procs result to the sending thread, only to discover that the originating thread doesn't *exist* any more and to crash ! That's why we need this fix IMHO. Andreas Mohr

1 0

Present status of DOS support
by Uwe Bonnes 01 Feb '01

01 Feb '01

Hallo, it seems that libwinedos.so is missing some functions on my system: hertz:/spare/bon/wine> wine -- /dosc/local/pkunzip.exe eagle-4.0g.exe ... fixme:win32:ELF_FindExportedFunction function GetCurrent not found: /spare/bon/wine/dlls/libwinedos.so: undefined symbol: GetCurrent fixme:win32:ELF_FindExportedFunction function LoadDPMI not found: /spare/bon/wine/dlls/libwinedos.so: undefined symbol: LoadDPMI ... Did I forget to configure something? But with a grep through the sources, I couldn't find a place were LoadDPMI was defined. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: WINE_UNICODE_TEXT
by Francois Gouget 01 Feb '01

01 Feb '01

On Mon, 29 Jan 2001, Jon Griffiths wrote: > Hi, > > This patch removes the warnings from the WINE_UNICODE_TEXT macro and fixes an > obscure (read: uninvestgated) bug where the value of WCHAR('x') + 1 is off by You mean WINE_UNICODE_TEXT('x')+1 != WINE_UNICODE_TEXT('y') ? I see why this could happen: gcc considers that the expression is of type WCHAR* and since sizeof(WCHAR)==2, it just adds two. > one. Currently 2-3 warnings are generated whenever TEXT() is used in Winelib > programs, depending on whether a string or char is the target. > > Only one warning remains, when using WCHAR('x') the result should be > explicitly cast to WCHAR to get rid of it. If you do this -Wall is blissfully > silent once again... Which means you get warnings too. I'm not too convinced about this patch especially because it does not return the proper type. On the other hand it seems what I did returns a WCHAR* (after a fashion). But it seems there's no really good solution (besides -fshort-wchar) :-(. If you are going to modify your source, I think casting TEXT('x') to WCHAR is not the solution. The solution is to not use TEXT (and equivalents) on characters. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 3

Re: signed char
by Uwe Bonnes 01 Feb '01

01 Feb '01

Josh DuBois writes: > { > - char *p = (char*) p_data; > + signed char *p = (char*) p_data; ^signed Shouldn't the cast be for the targert variable? 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

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