January 2004 - Wine-Devel - list.winehq.org

Re: Need help debugging ... Ddraw issue

by Duane Clark

Mike Hearn wrote: > On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote: > >>Use tools/findfunc rather than grep to find Win32 functions in the Wine >>tree. > > > Or better, make tags/make etags - I find this works very well. > Or: http://source.winehq.org/ident

Jan. 17, 2004

Re: winecfg: a patch to review

by Dimitrie O. Paun

On January 17, 2004 10:55 am, Chris Morgan wrote: > Shouldn't we be adding things that: > > - Won't be obsolete in the future > - A majority of users actually need to use I think you are correct. The settings that Mike mentioned were listed already under the regedit-only already. I think they should remain there. > I agree that [Version] should be an app specific setting, it is a > frequently used option. Maybe we can roll version settings and the Dll > settings tab together into an "Application" tab? I think this is a good idea. In general speaking, this per-app settings is a hack required by poor implementation. Windows doesn't need it, so we should be fine without it. Therefore: -- we should try to minimize it's use -- eliminate it in the future -- not encourage people to use it, unless required Thus cluttering the interface with it would be a bad plan IMO. Having it in a separate tab can keep us honest to not overuse it, and to more easily get rid of it in the future. -- Dimi.

Jan. 17, 2004

Re: GetShortPathName broken

by Eric Pouech

Stefan Leichter a écrit : > Hello, > > The function GetShortPathName is broken in current cvs. This short program > exhibits the problem: > ------------------------------------ > #include <stdio.h> > #include <windows.h> > #include <version.h> > > int main(int argc,char **argv[]) > { char buffer[0x104] =""; > DWORD retval; > retval = GetShortPathName("C:\\Program Files", buffer, sizeof(buffer)); > printf("%08x, %08x, %s\n", retval, GetLastError(), buffer ); > > return(0); > } > ----------------------------------------- > On win2k and wine "2004-01-14 CST" i get > 0000000b as retval and 00000000 from GetLastError() starting with wine > "2004-01-14 18:21:00 CST" up to current cvs i get 00000000 for retavl and > 00000002 from GetLastError(). > > So for my understanding the patch http://cvs.winehq.com/patch.py?id=10682 > broke the function. does the C:\Program Files exist in your settings ? I tried your small test here, and it return as expected (same values as you describe for 2k). What you seem to have is the return value when the directory 'Program Files' doesn't exist in your configuration, in which case it returns an error (2 = ERROR_FILE_NOT_FOUND) A+

Jan. 17, 2004

Re: winecfg: a patch to review

by Dimitrie O. Paun

On January 17, 2004 08:09 am, Mike Hearn wrote: > Don't forget the X11DRV settings, in particular: > > Desktop > UseXVidMode/UseXRandR > XRender vs core fonts Well, first off, I didn't know these (except for Desktop) were app-specific. I've marked them so now. However, they are not winecfg options, there are listed as regedit-only options in my list, so I don't think we should worry about them for now. Attached please find my latest version of the options.html list. This list needs to be kept up to date. Truth be told, it's hard to do so when it sits on my machine. It needs to be integrated into WineHQ. Maybe under Status? (I'll send a patch soon). But the main idea is that we've already discussed these things, and the conclusions of those discussions were distilled into this document. Let's work off of it, and try to keep it current. -- Dimi.

Jan. 17, 2004

Re: winecfg: a patch to review

by Chris Morgan

Shouldn't we be adding things that: - Won't be obsolete in the future - A majority of users actually need to use I'm wondering if enough users want to configure those options to make it worthwhile to implement. We should prioritize the functionality we need before we can say "use winecfg" to configure wine. The rest of the features can require the user to use regedit or edit the config file by hand. I agree that [Version] should be an app specific setting, it is a frequently used option. Maybe we can roll version settings and the Dll settings tab together into an "Application" tab? Chris On Saturday 17 January 2004 08:09 am, Mike Hearn wrote: > On Fri, 16 Jan 2004 22:03:31 -0500, Dimitrie O. Paun wrote: > > Here is the exaustive list of per-app settings that we currently have > > in winecfg: > > Don't forget the X11DRV settings, in particular: > > Desktop > UseXVidMode/UseXRandR > XRender vs core fonts > > are app-specific for sure, probably others. Of those you definately want > to be able to configure Desktop mode separately, at least until Alex's > desktop patch goes in. > > thanks -mike

Jan. 17, 2004

Problem with configure/config.cache

by Dominik Strasser

Hi, I am running into a problem, each time I rerun tools/wineinstall: wineinstall calls configure; configure finds a valid config.cache. On detction of the aRTS sound server it does the following: if test "${ac_cv_c_artsserver+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else # check for aRTS ... so if configure is called repeatedly, the else clause is not executed. But only in this else clause, ARTSC_CFLAGS and ARTSC_LIBS are set, which results in an uncompilable wine alsa driver because ARTSLIBS and ARTSINCL is set to those vars. Something similar happens in the detection of the asm keywords to be used in the stabs generation. I am not an autoconf guru, so I have no clue how to fix this. Regards Dominik

Jan. 17, 2004

Re: Implement LockWindowUpdate [take 3]

by Mike Hearn

On Fri, 2004-01-16 at 22:39, Alexandre Julliard wrote: > A DC would be concerned if it could have its visible region changed by > the fact that the lock window is set, so this would be basically any > DC used by the old and new lock windows and all their visible children. Is 'concerned' a technical term? I've not seen it in the Wine sources before. If so, is there a function anywhere to calculate the concerned DCs given a window? > > Could you have told me this when I first submitted my patch? I feel it's > > been a bit of a waste of time now - looking at the code it seems that > > inter-process invalidation is not trivial thing. > > Pretty much nothing in the painting code is trivial I'm afraid... At the moment the invalid region is stored in WND yes, and to implement this properly it would have to be moved into the server and manipulated using server RPCs? I'm not going to attempt this myself, just wondering what it'd take (and maybe somebody will see this thread and write a patch).

Jan. 17, 2004

Re: A question about winehq options

by Robert Reif

HardwareAcceleration, DefaultPlayback, and DefaultCapture are somewhere in the registry on 98 up but with different names. See http://www.osr.com/ddk/stream/pcdesign_29if.htm for a description of Hardware Acceleration. These registry entries are set by mmsys.cpl. I only have access to XP and it's mmsys.cpl doesn't work well in wine. Looking into my XP registry shows: HKEY_LOCAL_MACHINE\\SYSTEM\CurrentControlSet\\Control\\MediaResources\DirectSound\Mixer Defaults holds Acceleration, SRC Quality and Speaker Configuration. This is with XP with it's WDM driver model and I don't know how 98 handles this with it's VxD driver model. If someone with other than XP can look into this, we might be able to find the proper way to implement this in wine. What's in wine now is just a quick fix by me to allow hardware acceleration setting and default sound card selection but the proper way should be found in the long run. It also might turn out that each OS version does this differently and 95 down might not do this at all so a universal wine way might not be so bad. "Dimitrie O. Paun" wrote: > On January 16, 2004 09:59 pm, Dimitrie O. Paun wrote: > > Again, these are regedit-only options, no need to clutter winecfg. > > Of course, I was looking at the wrong part of the file when I wrote that. > Here is the list of DSound options we decided to put into winecfg: > > [DSound] > HardwareAcceleration > DefaultPlayback > DefaultCapture > EmulDriver > > Please note that EmulDriver is also settable per app as well, > but maybe we can ignore that as a first order approximation. > For special apps that need overriding, regedit works just fine. > > -- > Dimi.

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Frank.Schruefer＠t-online.de

Frank Schruefer wrote: > Hy Jason > > Really cool man! > I was following your posts here in real time and you almost found > solutions faster than > I could try them out, LOL! > > I can confirm that the screen switches and a picture shows up when using > full win-path > and the mouse acts weird. > Haven't tried commenting out anything yet. I'm trying to investigate > that GetCommandLine > thing. > So far I grep'd through the wine code but only found extern > GetCommandLineA decls. > Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: /*********************************************************************** * GetCommandLineA (KERNEL32.@) * * WARNING: there's a Windows incompatibility lurking here ! * Win32s always includes the full path of the program file, * whereas Windows NT only returns the full file path plus arguments * in case the program has been started with a full path. * Win9x seems to have inherited NT behaviour. * * Note that both Start Menu Execute and Explorer start programs with * fully specified quoted app file paths, which is why probably the only case * where you'll see single file names is in case of direct launch * via CreateProcess or WinExec. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ... But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func: [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source. I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned. But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config? Suggestions?

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Frank.Schruefer＠t-online.de

(REPOST, somehow this message yesterday didn't go through until now, strange! Sorry if you may get it twice.) Frank Schruefer wrote: > Hy Jason > > Really cool man! > I was following your posts here in real time and you almost found > solutions faster than > I could try them out, LOL! > > I can confirm that the screen switches and a picture shows up when using > full win-path > and the mouse acts weird. > Haven't tried commenting out anything yet. I'm trying to investigate > that GetCommandLine > thing. > So far I grep'd through the wine code but only found extern > GetCommandLineA decls. > Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: /*********************************************************************** * GetCommandLineA (KERNEL32.@) * * WARNING: there's a Windows incompatibility lurking here ! * Win32s always includes the full path of the program file, * whereas Windows NT only returns the full file path plus arguments * in case the program has been started with a full path. * Win9x seems to have inherited NT behaviour. * * Note that both Start Menu Execute and Explorer start programs with * fully specified quoted app file paths, which is why probably the only case * where you'll see single file names is in case of direct launch * via CreateProcess or WinExec. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ... But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func: [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source. I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned. But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config? Suggestions? -- Regards, Frank

Jan. 17, 2004

Re: Debugger doc pages

by Mike Hearn

On Sat, 17 Jan 2004 00:07:42 +0000, Jason Edmeades wrote: > Is it something about my machine but when I go to the online debugger > docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can > see absolutely nothing in the text boxes. I can highlight the text and > it appears to be in a minute font, and cut+paste into an editor shows me > the text is there, its just too small to be visible. > > I tried with mozilla and IE (both from a Windows machine). WORKSFORME with Firebird 0.7 on Fedora... is the font setup on that machine odd in any way?

Jan. 17, 2004

Re: Partial MDI rewrite

by Mike Hearn

On Fri, 16 Jan 2004 15:19:43 -0800, Alexandre Julliard wrote: > The critical section thing worries me, especially since you are doing > things that may require sending messages in there. I think you should > use the normal USER lock when locking is really necessary; note that > anything that is only accessed from the window procedure doesn't need > locking at all. One thing I didn't understanding looking at the DC code was the USER lock. Why does USER not use CRITICAL_SECTIONs like everywhere else, instead of these syslevel things? Are there MSDN docs on this or is it a purely internal thing?

Jan. 17, 2004

Re: Need help debugging ...

by Mike Hearn

On Fri, 16 Jan 2004 23:19:33 +0000, Jason Edmeades wrote: >> The disassembly of the failure shows we have written to eax, and info >> regs shows eax of 0x00. >> dis 0x4e4a20 shows the routine where the return value is set up in >> eax, and some debugging shows the initial problem is a path problem. You're significantly better at this than I am! "Some debugging" is a bit vague but I'll let you off that ;) I guess I just need to get better at reading disassemblies. > Hmmm. > > Following the path we are playing with back a bit, it is built up and > looks extremely like the command line (Since if I add command line > options, they are added as an array to where this comes from).. In fact, > I can get back to an address where at the very first breakpoint the full > path is in the place it will be eventually copied from. > > Now a simple test pgm: > void main(int count, char *argv[]) { > printf("Argv[0] = %s\n", argv[0]); > } > > Shows that you only get the program name when run, so it leaves the > question how the full path is supplied. Are you sure that's the prototype of the entry point? I suspect it's actually a WinMain as Andreas suggested... that would make sense, you don't need to make an API call to get the path then. > With some experimentation with a GUI pgm I think I stumbled upon the / > an answer: > Bug#1 - GetCommandLine() returns a full path on Windows but no path on Wine Doh. Well this should definately be fixed anyway (with a regression test), and it does sound a lot like the problem doesn't it? I expect we use this API (or similar) to set the parameters to WinMain. thankyou very much! I learnt something today -mike

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Mike Hearn

On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote: > Use tools/findfunc rather than grep to find Win32 functions in the Wine > tree. Or better, make tags/make etags - I find this works very well.

Jan. 17, 2004

Re: winecfg: a patch to review

by Mike Hearn

On Fri, 16 Jan 2004 22:03:31 -0500, Dimitrie O. Paun wrote: > Here is the exaustive list of per-app settings that we currently have > in winecfg: Don't forget the X11DRV settings, in particular: Desktop UseXVidMode/UseXRandR XRender vs core fonts are app-specific for sure, probably others. Of those you definately want to be able to configure Desktop mode separately, at least until Alex's desktop patch goes in. thanks -mike

Jan. 17, 2004

GetShortPathName broken

by Stefan Leichter

Hello, The function GetShortPathName is broken in current cvs. This short program exhibits the problem: ------------------------------------ #include <stdio.h> #include <windows.h> #include <version.h> int main(int argc,char **argv[]) { char buffer[0x104] =""; DWORD retval; retval = GetShortPathName("C:\\Program Files", buffer, sizeof(buffer)); printf("%08x, %08x, %s\n", retval, GetLastError(), buffer ); return(0); } ----------------------------------------- On win2k and wine "2004-01-14 CST" i get 0000000b as retval and 00000000 from GetLastError() starting with wine "2004-01-14 18:21:00 CST" up to current cvs i get 00000000 for retavl and 00000002 from GetLastError(). So for my understanding the patch http://cvs.winehq.com/patch.py?id=10682 broke the function. Bye Stefan

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Andreas Rosenberg

Hello guys, I'm watching this thread since yesterday. Perhaps I can give you a clue. > >I'm trying to investigate that GetCommandLine thing. > The one thing I couldnt answer is how the game 'gets' the command line. int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); Perhaps this way? Andy

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Jason Edmeades

>I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL! To be honest these things come down to luck sometimes, depending on what direction you start debugging! I was very lucky with this one - I ran them side by side on 2 machines, one under windows and one under wine, put breakpoints at the point of failure and worked backwards comparing the two. >I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. >Haven't tried commenting out anything yet. Weird. Mine trapped as soon as the splash screen was removed, so I had to do that commenting before I could get to the main menu. >I'm trying to investigate that GetCommandLine thing. The one thing I couldnt answer is how the game 'gets' the command line. It doesnt (didnt!) appear to use any API to do it, although I didnt spend long looking into this. I hit it in wine when i tried to think of what possible ways you could get to the command line and tested some of them. This would probably need some more work to find out exactly how this game does it (I doubt it accesses the PEB directly). As to the mouse problem, I dont know - I've had other games where the mouse behaviour is weird and jumpy, but never quite like that. Does turning on (or off) dxgrab make a difference? (Not booted into Linux just now). Does DK2 suffer from the same thing, or is there another problem? Jason

Jan. 17, 2004

Re: Need help debugging ...

by Eric Pouech

> PS Anyone know if MSDEV has the ability to debug pgms under wine yet? windbg used to run (it was a long time ago, and I didn't check recently). At least, the debugging API was ok. YMMV. > PPS I really wish the winedbg had a memory dump routine (bytes + > ascii)... is it possible with the cmd set available? check the 'x' command (x for examine, same syntax as gdb's) A+

Jan. 17, 2004

Re: Html Help

by Dimitrie O. Paun

On January 16, 2004 11:53 pm, Acke Carlsson wrote: > Looking in old mailing lists archive > > http://www.winehq.org/hypermail/wine-devel/2002/11/0885.html > > see on post E:7 Good catch! :) But E7 says we should add CHM support to our version of WinHelp. Anyway, launching a native app to do that is not such a bad idea, I'm just saying we should have a more structured approach to it... -- Dimi.

Jan. 17, 2004

Re: Html Help

by Acke Carlsson

On Friday 16 January 2004 16:24, Dimitrie O. Paun wrote: > On January 16, 2004 10:11 am, Martin Fuchs wrote: > > Why not just configure everything in the registry and use ShellExecute() > > to launch the correct applications this way? > > Even better. To be honest, I haven't looked into why we need this > apps, it's just that I'm a little concerned we're gonna end up > with too many :) Looking in old mailing lists archive http://www.winehq.org/hypermail/wine-devel/2002/11/0885.html see on post E:7 mvh Acke

Jan. 17, 2004

RE: dmesg error about pthreads

by PETREOLLE Sylvain

Hi Kevin, I have the same messages and was about to write to wine-devel. But I dont know what to do. -----Message d'origine----- De : Kevin DeKorte [mailto:kdekorte(a)yahoo.com] Envoyé : vendredi 16 janvier 2004 16:16 À : wine-devel(a)winehq.com Objet : dmesg error about pthreads On my FC1 system with the latest patches I'm getting this in the dmesg log. Been getting them for awhile. application bug: wine-pthread(4537) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated. wine -v Wine 20031212 Is this anything I need to worry about Kevin ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

Jan. 17, 2004

Re: Running Wine under MS SFU under Wine ... ?

by Gregory M. Turner

On Sunday 14 December 2003 10:05 pm, I wrote: > On Sunday 14 December 2003 09:02 pm, Dan Kegel wrote: > > I recently posted with problems running Microsoft's > > Services for Unix under Wine. I only tried it out > > of morbid curiosity, actually, and because MS was > > offering it for free. The free offer expired, but > > it's back again for a little while; slashdot.org > > seems to be running banner ads for it. I'd encourage > > any of you who even *might* be tempted to try this > > out to go order the CD-ROM. It would be way bitchin' > > cool if we could nest Wine and MS SFU (I seem to recall > > we can't nest Wine in Cygwin for some technical reason, > > but who knows, maybe SFU won't have the same problem). > > - Dan > > Don't get your hopes up; they are nothing to write home about. Perhaps I spoke too soon, although when I evaluated this long ago, it was probably true. MS has acquired (license to?) Interix and SFU3.5 is based on it; it is now available for download from Microsoft for free, I do not think it's supposed to be a limited-time offer this time. I recently learned that SFU (3.5, at least) is actually a Windows "subsystem," which supposedly should mean that it is not a compatibility layer like cygwin implemented on top of the Windows API. Could be fun, I definitely will give it a whorl presently... -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39

Jan. 17, 2004

Re: [winecfg] - audio tab w/autodetection, misc

by Chris Morgan

Revision of original patch. I'm getting odd errors when the registry transactions are occuring: err:winecfg:setConfigValue Unable to set configuration key Drivers in section Winmm to winejack.drv, res=1021 Is this expected as changing this option would require the registry functions to modify the config file, something they can't do? * En.rc, Makefile.in, drive.c, main.c, properties.c, properties.h, resource.h, winecfg.h, audio.c Chris Morgan <cmorgan(a)alum.wpi.edu> Add audio tab with first pass at autodetection of audio driver. Double clicking a drive entry brings up drive edit window. Chris On Monday 05 January 2004 01:17 am, Dimitrie O. Paun wrote: > On January 4, 2004 11:53 pm, Chris Morgan wrote: > > I wasn't sure what to do with the resource files so I went and copied the > > changes from the En.rc over to the rest of the rc files. > > Don't do that, it will hide the fact that the resource was not > yet translated properly. Just update the En.rc one, and let the > others be translated by the appropriate translators...

Jan. 17, 2004

Re: Try using the Mozilla Active X control in MSHTML

by Mike McCormack

Hi Dmitry, I didn't really have much time to do testing with it... tried to use it in place of IE6 and IE4's mshtml, but it didn't work. Using Mozilla to implement IWebBrowser seems to be the Right Way for me, as the Mozilla project is already trying to do that themselves... it's a common goal that we can work together on! It would be pretty cool if we could compile Mozilla as a winelib app, or figure out how to do get debugging info out of the control so we could see what needs to be fixed for it to work. I'm pretty interested to work on this too, but unfortunately there's other "real work" that I need to get done at the moment. Mike Dimitrie O. Paun wrote: > Perfect! I'm fairly excited about this stuff. > > BTW Mike, did you try to see if HTML Helps works with the > Mozilla control? We had a task to add CHM support to WinHelp, > but first we needed an implementation for IWebBrowser. > People were arguing that Mozilla is not that IE compatible, > and that using it for the IWebBrowser component will not work > for a lot of cases, but I still think this is the way forward. > Even if we chose in the future to have another IWebBrowser > implementation based on khtml, this will nicely fill in the > gap in the meanwhile, without any maintenance problems for us. >

Jan. 17, 2004