April 2002 - Wine-Devel - list.winehq.org

RE: su to root failure in wineinstall

by Medland, Bill

> -----Original Message----- > From: Enrico Horn [mailto:farmboy1(a)subdimension.com] > Sent: Monday, April 22, 2002 2:58 AM > To: wine-devel(a)winehq.com > Subject: Re: su to root failure in wineinstall > > > Hi, > On Saturday 20 April 2002 21:23, Thomas Hardman wrote: > > Wine build complete. > > > > Performing 'make install' as root to install binaries, > enter root password > > Password: > > /bin/bash: - : unrecognized option > > > > Either you entered an incorrect password or we failed to run > > 'make install' correctly. > > If you didn't enter an incorrect password then please report this > > error to wine-devel(a)winehq.com. > > > > Installation failed, aborting. > > earthops:/usr/src/wine-20020411$ > > That is an error(typo?) in wineinstall > Find this line in wineinstall: > if ! su root -c"$sucommand" > > and put a space between -c and "$sucommand" > > That should do it. And if that doesn't work then find the line where it adds ldconfig to sucommand and explicitly specify /sbin/ldconfig (or wherever yours is) Bill > > Enrico > farmboy1(a)subdimension.com >

April 22, 2002

RE: bug?

by Medland, Bill

> -----Original Message----- > From: Rikard Björklind [mailto:olof(a)linux.nu] > Sent: Saturday, April 20, 2002 5:38 AM > To: wine-devel(a)winehq.com > Subject: bug? > > > Hi, I tried to use ./tools/wineinstall: > > Performing 'make install' as root to install binaries, enter > root password > Password: [here I wrote the password] > /bin/bash: - : unrecognized option > > What's wrong? > > Probably failed to run the ldconfig. Check the /etc/ld.so.conf to see that the location of the wine lib directory is included (probably /usr/local/lib) and su root and run /sbin/ldconfig. Bill

April 22, 2002

Re: Wine not releasing CDROM

by lawson_whitney＠juno.com

On Mon, 22 Apr 2002, Oliver Sampson wrote: > Howdy, > I'm seeing a strange behavior and I thought I'd let the Devel > community know about it: > > While using Agent v1.8, and while having a CD in my CD tray (although > unmounted!), if I start agent under wine, I'm able to open and close > my CD tray. However, if I try to use the attachment window to attach > something, the CD-ROM drive spins up, and I'm unable to open it. Even > if I attach nothing, the CD-ROM drive is claimed by wine so that I > can't eject the Drive. Once I exit agent, the drive is released so > that I can open the drive. Note that the CD-ROM was never mounted. > Even a check during the blocked period shows no mounted device, even > though the "eject' command says "device busy." > > Interestingly, when I just tried this again for this email, I noticed > the following output messages (It seems that there are some floppy > drive assumptions, also.) If you don't want Wine to attempt raw device access, don't give it a "Device" = in the [Drive X] entry, I think. Your average Windows app is inquisitive and tries to look at all drives that have defined devices. > > Oliver > > ---output---- > err:dosfs:DRIVE_ReadSuperblock Couldn't open device '/dev/fd0' for > drive A: ! (no permission) > err:dosfs:DRIVE_ReadSuperblock Can't read drive volume info ! Either > pre-set it or make sure the device to read it from is accessible ! > Perhaps you have not properly edited or created your Wine > configuration file. > This is (supposed to be) '/home/olsam/.wine/config' ;; MS-DOS drives configuration ;; ;; Each section has the following format: ;; [Drive X] .... ;; "Device"="/dev/xx" (only if you want to allow raw device access) Lawson If you don't want my peaches, then don't shake my tree.

April 22, 2002

Wine not releasing CDROM

by Oliver Sampson

Howdy, I'm seeing a strange behavior and I thought I'd let the Devel community know about it: While using Agent v1.8, and while having a CD in my CD tray (although unmounted!), if I start agent under wine, I'm able to open and close my CD tray. However, if I try to use the attachment window to attach something, the CD-ROM drive spins up, and I'm unable to open it. Even if I attach nothing, the CD-ROM drive is claimed by wine so that I can't eject the Drive. Once I exit agent, the drive is released so that I can open the drive. Note that the CD-ROM was never mounted. Even a check during the blocked period shows no mounted device, even though the "eject' command says "device busy." Interestingly, when I just tried this again for this email, I noticed the following output messages (It seems that there are some floppy drive assumptions, also.) Oliver ---output---- err:dosfs:DRIVE_ReadSuperblock Couldn't open device '/dev/fd0' for drive A: ! (no permission) err:dosfs:DRIVE_ReadSuperblock Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible ! Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '/home/olsam/.wine/config' err:dosfs:DRIVE_GetLabel Invalid or unreadable superblock on /dev/fd0 (A:). err:dosfs:DRIVE_ReadSuperblock Couldn't open device '/dev/fd0' for drive A: ! (no permission) err:dosfs:DRIVE_ReadSuperblock Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible ! Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '/home/olsam/.wine/config' Invalid or unreadable superblock on /dev/fd0 (A:). Maybe not FAT? err:dosfs:DRIVE_ReadSuperblock The filesystem is not FAT !! (device=/dev/cdrom) err:dosfs:DRIVE_GetLabel Invalid or unreadable superblock on /dev/cdrom (D:). err:dosfs:DRIVE_ReadSuperblock The filesystem is not FAT !! (device=/dev/cdrom) Invalid or unreadable superblock on /dev/cdrom (D:). Maybe not FAT? fixme:listview:LISTVIEW_UnsupportedStyles LVS_EDITLABELS fixme:listview:LISTVIEW_UnsupportedStyles LVS_SHAREIMAGELISTS ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

April 22, 2002

Re: [PATCH] Big winsock2 / overlapped patch

by Martin Wilck

On Fri, 19 Apr 2002, Sylvain Petreolle wrote: > > I know the patch is much too big but I have no time > > now to split it into > > pieces before next week. > If the patch is too big, then gzip it and send it > as an attachment :) I didn't mean to say it's too big for an email :) What I meant was it is big for humans to read & understand, and too big for Alexandre to apply as a single chunk. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 22, 2002

dlls/kernel/comm.c build failure

by Gerald Pfeifer

The following patch revision 1.56 date: 2002/04/21 22:06:09; author: julliard; state: Exp; lines: +24 -0 <wine(a)gc2.kloepfer.org> Faster serial speed cases for non Linux systems. broke dlls/kernel/comm.c on FreeBSD 4.5 (and probably all non-Linux systems) /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o comm.o comm.c comm.c: In function `SetCommState': comm.c:1063: `CBR_230400' undeclared (first use in this function) comm.c:1063: (Each undeclared identifier is reported only once comm.c:1063: for each function it appears in.) gmake[2]: *** [comm.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/kernel' gmake[1]: *** [kernel/kernel32.dll.so] Error 2 apparently because CBR_230400 is not #defined in include/winbase.h. The patch below fixes this, but I suppose it's not what will go in finally... Gerald ChangeLog: Only use CBR_230400 and CBR_460800 if they have been defined. Index: dlls/kernel/comm.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/comm.c,v retrieving revision 1.56 diff -u -3 -p -r1.56 comm.c --- dlls/kernel/comm.c 21 Apr 2002 22:06:09 -0000 1.56 +++ dlls/kernel/comm.c 22 Apr 2002 06:44:43 -0000 @@ -1060,13 +1060,17 @@ BOOL WINAPI SetCommState( #endif #ifdef B230400 case 230400: +#ifdef CBR_230400 case CBR_230400: +#endif port.c_cflag |= B230400; break; #endif #ifdef B460800 case 460800: +#ifdef CBR_460800 case CBR_460800: +#endif port.c_cflag |= B460800; break; #endif

April 22, 2002

minor regression testing patch

by Paul Millar

Hi, Found attached bug. Curiously, the test doesn't fail even if wine is pretending to be Windows 95 :) ChangeLog: Fixed typo "Major" -> "Minor" BTW, After the patch, the test for WIN98 or later is: #define WIN98_PLUS(version) (version.dwMajorVersion==4 && \ version.dwMinorVersion>0) but, MS's documentation: http://msdn.microsoft.com/library/en-us/sysinfo/sysinfo_49iw.asp suggests something more like: #define WIN98_PLUS(version) \ ( (version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) && \ ( (version.dwMajorVersion > 4) || \ (version.dwMajorVersion==4 && version.dwMinorVersion>0))) Is this more correct? ---- Paul Millar

April 21, 2002

Re: Enhancements and fixes for the rich text edit control

by Duane Clark

Just out of curiosity, since it has not shown up in CVS, is this patch from Chuck likely to be incorporated? It is working significantly better than the current code for me, at least. If there are problems with it, how about some words of guidance, so that he will be encouraged to keep working on it? The richedit stuff really needs it.

April 21, 2002

Q: using GDI printer from Linux using Wine?

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it possible to configure Linux to use a GDI printer (with no native Linux support) using Wine? Does Wine support GDI printing already? - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzCgU0ACgkQpm53PRScYyhbZACbBRK9ozAMv1HT6GL8+ND5NZtK G6oAoJqwzVvVd2IrERjMJAiRmCxCVLHo =bb79 -----END PGP SIGNATURE-----

April 21, 2002

Re: su to root failure in wineinstall

by Enrico Horn

Hi, On Saturday 20 April 2002 21:23, Thomas Hardman wrote: > Wine build complete. > > Performing 'make install' as root to install binaries, enter root password > Password: > /bin/bash: - : unrecognized option > > Either you entered an incorrect password or we failed to run > 'make install' correctly. > If you didn't enter an incorrect password then please report this > error to wine-devel(a)winehq.com. > > Installation failed, aborting. > earthops:/usr/src/wine-20020411$ That is an error(typo?) in wineinstall Find this line in wineinstall: if ! su root -c"$sucommand" and put a space between -c and "$sucommand" That should do it. Enrico farmboy1(a)subdimension.com

April 21, 2002

Re: ALSA driver

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > yes an no. since we don't have a proper install (and detection) > mechanism > in wine, I was more leaning to having a single ALSA driver, that would > compile into 0.5 or 0.9 (depending on the headers found on the system). That's the best solution assuming you can also compile it to support both 0.5 and 0.9 if you have all the necessary headers, and detect which version to use at run-time. If this is not possible we need two separate drivers, otherwise it won't be possible to build a binary package that works for everybody. -- Alexandre Julliard julliard(a)winehq.com

April 21, 2002

Re: ALSA driver

by Eric Pouech

> I don't think that this is the right way. IMHO, there should be one 0.5 > and "current" alsa module for wine - they really have different apis. > They have common features and an almost identical name, but that's it. > It would be cleaner to copy you code completely into a separate alsa-0.9 > ( or current or whatever) module and compile and install it separately. yes an no. since we don't have a proper install (and detection) mechanism in wine, I was more leaning to having a single ALSA driver, that would compile into 0.5 or 0.9 (depending on the headers found on the system). I agree that #ifdef:ing in the code is a bad idea. A+

April 20, 2002

Re: ALSA driver

by Eric Pouech

> But I think > many users, well at least me, would be rather disappointed at being > expected to run 0.5 (assuming that would be required). I don't object having a 0.9 driver at all. But I consider today having a 0.5 is more important than a 0.9 (even if it's for a short (1 year ?) period of time) A+

April 20, 2002

Re: ALSA driver

by Joerg Mayer

On Sat, Apr 20, 2002 at 09:42:12PM +0200, Eric Pouech wrote: > > BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to > > port your code to it. > ok, but keep both 0.5 and 0.9 inside and also protect 0.9 code when only > the 0.5 headers will be available. I don't think that this is the right way. IMHO, there should be one 0.5 and "current" alsa module for wine - they really have different apis. They have common features and an almost identical name, but that's it. It would be cleaner to copy you code completely into a separate alsa-0.9 ( or current or whatever) module and compile and install it separately. 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.

April 20, 2002

Re: ALSA driver

by Joerg Mayer

On Sat, Apr 20, 2002 at 09:40:31PM +0200, Eric Pouech wrote: > > OK, that is mostly the disappointment speaking > > that I still won't be able to run wine with Alsa. > The point is on the current installed base of ALSA drivers ... > It just means that 0.9 installed base is almost 0 (in percentage). With Suse 8.0 now shipping 0.9 and 0.9 being in the 2.5 development kernels, the userbase will start to grow fast. > So, spending time right now on 0.9 is not the top priority (at least for > me). That is your privilege as author :-) So there is one more sound module for wine to be written, as the api has changed significantly between 0.5 and 0.9. > OTOH, since the OSS emulation in ALSA 0.5 is broken, the point is whether > we fix it (using a pure ALSA 0.5 driver in Wine), or let users live with > that (TG has disabled the HAL support Yeah, I guess I automatically assumed that alsa 0.9 would be broken with respect to mmap too :-/ 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.

April 20, 2002

Re: ALSA driver

by Duane Clark

Eric Pouech wrote: > the point is not whether 0.5 is technically better than 0.9 (or the > other > way around). The point is on the current installed base of ALSA drivers > in the field, how many are 0.5 and how many are 0.9. > Mandrake and Suse (at least) have been shipping 0.5 for more than one > year, whereas 0.9 is brand new. Perhaps not quite brand new, at least in "computer years" ;) In any case, I think that it is not unreasonable to expect someone wanting to run wine with sound to install 0.9. Relative newbies might get a bit of a shock at having to recompile their kernels to get ALSA. But I think many users, well at least me, would be rather disappointed at being expected to run 0.5 (assuming that would be required). ...just my opinion though.

April 20, 2002

Re: ALSA driver

by Eric Pouech

Marco Pietrobono a écrit : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 20 Apr 2002, Eric Pouech wrote: > > > after Gav and Ove clarified the license details, lets go back to the > > technical bits > > this driver is against ALSA 0.5 interface. It will provide the bare bone > > wave part, but not yet the mixer part nor the MIDI. Moreover, it should > > also support the mmap interface (this was part of the code that needed > > to be checked and revisited, and David should be looking into this) > > well, this seems a good start nevertheless. > > I've just a little doubt. From what I've understood from the alsa-devel > list, it seems that the ALSA 0.5 has been declared dead almost officially. > They are not supporting it anymore, more over they are actively pushing > the new 0.9 interface and library. IIRC, they want to get out a rc1 next > week, or like. see my answer to Joërg about this. > BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to > port your code to it. ok, but keep both 0.5 and 0.9 inside and also protect 0.9 code when only the 0.5 headers will be available. A+

April 20, 2002

Re: ALSA driver

by Eric Pouech

> Sigh, Suse 8.0 just moved fom 0.5 to 0.9 - the Alsa developers regard > 0.9 as more stable and having less bugs than 0.5. Why spend all that > time on an obsolete driver? OK, that is mostly the disappointment speaking > that I still won't be able to run wine with Alsa. the point is not whether 0.5 is technically better than 0.9 (or the other way around). The point is on the current installed base of ALSA drivers in the field, how many are 0.5 and how many are 0.9. Mandrake and Suse (at least) have been shipping 0.5 for more than one year, whereas 0.9 is brand new. It just means that 0.9 installed base is almost 0 (in percentage). So, spending time right now on 0.9 is not the top priority (at least for me). OTOH, since the OSS emulation in ALSA 0.5 is broken, the point is whether we fix it (using a pure ALSA 0.5 driver in Wine), or let users live with that (TG has disabled the HAL support in dsound just because of that and it's a PITA) A+

April 20, 2002

su to root failure in wineinstall

by Thomas Hardman

Wine build complete. Performing 'make install' as root to install binaries, enter root password Password: /bin/bash: - : unrecognized option Either you entered an incorrect password or we failed to run 'make install' correctly. If you didn't enter an incorrect password then please report this error to wine-devel(a)winehq.com. Installation failed, aborting. earthops:/usr/src/wine-20020411$ -- T. Jr. Hardman thardman(a)earthops.org

April 20, 2002

Re: ALSA driver

by Marco Pietrobono

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 20 Apr 2002, Eric Pouech wrote: > after Gav and Ove clarified the license details, lets go back to the > technical bits > this driver is against ALSA 0.5 interface. It will provide the bare bone > wave part, but not yet the mixer part nor the MIDI. Moreover, it should > also support the mmap interface (this was part of the code that needed > to be checked and revisited, and David should be looking into this) well, this seems a good start nevertheless. I've just a little doubt. From what I've understood from the alsa-devel list, it seems that the ALSA 0.5 has been declared dead almost officially. They are not supporting it anymore, more over they are actively pushing the new 0.9 interface and library. IIRC, they want to get out a rc1 next week, or like. BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to port your code to it. [snip] > then, an ALSA final should be written. As the ALSA interface has greatly > evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be > rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will > be no need for ALSA 1.0, as most of the current distros ship with either > OSS or ALSA 0.5. I'm not so sure. It seems that the next versions of SuSE and Mandrake will contain ALSA 0.9, I don't know Red Hat plans on this one, as well as others' but I can check... bye, /pietrobo - -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. - ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8wamUJdpOg6vRQxoRAoyZAJ9kiYZ0AWGhbY8n4Lg33HJWGaaaZACeIUeB W9eGTd5p3tS9CGY5dv+nS3Y= =PdnE -----END PGP SIGNATURE-----

April 20, 2002

Re: ALSA driver

by Joerg Mayer

> then, an ALSA final should be written. As the ALSA interface has greatly > evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be > rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will > be no need for ALSA 1.0, as most of the current distros ship with either > OSS or ALSA 0.5. Sigh, Suse 8.0 just moved fom 0.5 to 0.9 - the Alsa developers regard 0.9 as more stable and having less bugs than 0.5. Why spend all that time on an obsolete driver? OK, that is mostly the disappointment speaking that I still won't be able to run wine with Alsa. 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.

April 20, 2002

Re: ALSA driver

by Eric Pouech

Marco Pietrobono a écrit : > > Hi, > > I'm starting to work on a native ALSA driver for wine. Since I > remember that Marcus was working (or was planning to work) an that one > too, I would like to know if there is already something to work on or to > contribute to, or if I need to start from scratch. > > If there is nothing already written, I would like to discuss what kind > of approach we should use with ALSA programming, since FWIK there should > be two way to use it: we can use the ALSA devices directly, just like it > has been done with OSS, or we can use the alsalib to avoid all direct > references to the kernel devices and ioctl, but this solution will add a > dependency on the alsalib library itself to wine. Of course, we could > add a configure option/check to allow its use at compilation time, > but... after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this) basically, this would allow to turn on mmap (which greatly enhances the dsound playback quality) on all soundcards (some OSS emulations for ALSA don't allow a correct mmap on the OSS mmap interface, so directly using the ALSA mmap interface should take of it) work will still be done on the installation stuff (basically, the registry must be written with either ALSA or OSS driver, depending on the installed interface on Linux) then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5. A+

April 20, 2002

bug?

by Rikard Björklind

Hi, I tried to use ./tools/wineinstall: Performing 'make install' as root to install binaries, enter root password Password: [here I wrote the password] /bin/bash: - : unrecognized option What's wrong?

April 20, 2002

Wine server request serialization IS broken

by Laurent Pinchart

Hi, I finally manage to understand where the problem comes from. And unfortunately there's a pretty serious inter process communication problem. CreateProcess waits until the child process initialization is done. This is handled by the server, which receives a init_process_done request from the child process, and then 'wakes' the parent process. My parent process calls SetThreadContext right after CreateProcess returns. Unfortunately, that's done in the middle of a wine server call from the child process (after it has sent the init_process_done request, but before he has read the reply). This causes some other server calls to be made, and a desynchronization to occur. I'll try to have a look at the code to find a way to fix that. As I don't have a global view of all the wine architecture, I'll probably forget a lot of side effects, so I'd appreciate very much if someone more experienced than me could give me a few advices. Thanks in advance. Laurent Pinchart

April 20, 2002

Re: ALSA driver

by Ove Kaaven

On Fri, 19 Apr 2002, Gavriel State wrote: > Ove Kaaven wrote: > > On 19 Apr 2002, Marco Pietrobono wrote: > > > > > >> I'm starting to work on a native ALSA driver for wine. Since I > >>remember that Marcus was working (or was planning to work) an that one > >>too, I would like to know if there is already something to work on or to > >>contribute to, or if I need to start from scratch. > > > > You must be mistaken, Eric Pouech was working on the ALSA driver. This > > driver is also pretty much complete, just bugfixes remain. Unfortunately, > > it's currently in the cold slimy clutches (from the LGPL-Wine perspective) > > of TransGaming staff, who might not want to part with it without getting > > some of that glorious LGPL code in Wine relicensed in exchange... > > Actually, we have no official claim over the ALSA driver - we offered to > sponsor Eric Poech's development, but he asked that we put it into another > sponsorship instead. Hmm. I guess some of my attempts at humor failed here... I never said that Eric had given us the code or that he couldn't submit it to wine if he wanted to, only that someone at transgaming was trying to finish it, so my message isn't strictly untrue, just very badly presented... I expected Eric to explain the real situation himself, but I suppose I can try to not add to the confusion in the future... > It is true though that TransGaming's David Hammerton 'has his clutches' on > the code - he's been working on it with Eric in his spare time. That said, > I just checked and while his hands are kind of cold, they didn't appear > to be at all slimy. Not even after lunch? > David said that he might try to check it into the ReWind tree this weekend. OK.

April 19, 2002