RE: SML-NJ for CygWin32

RE: SML-NJ for CygWin32

[Gary Fuehrer]

Not a whole lot has happened.  The SML-NJ team has my stuff, but I
haven't heard where they are with it.  You probably know that 109.32
came out and the cygwin platform support is not in there yet.  This
worried me because they are trying to go golden soon.  On the cygwin
side, the exception handling changes are getting hard to follow.  It
seems like several parties are fooling with it without much coordination
of effort.  This worries me because I don't know what to expect for
beta19.  Let me check on some things, and I'll post some more answers.

Was there anything in particular you are hoping to see advanced right
away?

Gary

> ----------
> From: 	Andrew Stevens[SMTP:Andrew.Stevens@comlab.ox.ac.uk]
> Sent: 	Wednesday, October 15, 1997 10:20 AM
> To: 	Gary Fuehrer
> Subject: 	Re: SML-NJ for CygWin32
> 
> Hi Gary,
> 
> has there been any further progress on 
> the SML port to cygwin yet?
> 
> 	Andrew
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Gary Fuehrer]

> Hi Andrew,
> 
> Here are my instructions and patches for building SML-NJ version
> 109.30 under cygwin32 (NT only; can't work with win95).  Please get
> the SML-NJ distribution from:
> 	ftp://ftp.research.bell-labs.com/dist/smlnj/working/109.30
> The howto.txt file attachment in this e-mail indicates which files you
> need from that distribution.
> 
> If you manage to get CygWin32 setup and SML-NJ built and working, then
> you will experience one bug when using sml (or sml-cm) interactively.
> When an error is reported to the console, the sml-nj "-" prompt
> doesn't return like it should.  When this happens, type "<Ctrl>-Z
> <Enter>" and the prompt will return.  I'm certain the bug is in
> CygWin32 and not in SML-NJ.  I also suspect there's already a patch
> that fixes it.
> 
> I haven't tried to use Isabelle yet.  I might mention that I did port
> Pollack's LEGO to SML-NJ 109.28 for Win32.  The UNIXisms that I
> encountered in doing that port were UNIX paths and the use of symbolic
> links in the LEGO library.  I don't suppose those are the UNIXisms
> you're referring to, are they?  Anyway, the reason I did the port of
> SML-NJ 109.30 to CygWin32 was so that the POSIX stuff would be
> available in the basis library.  Even though there are a few POSIX
> functions in the basis that couldn't be implemented with the beta18
> version of CygWin32, I think it is highly unlikely that you will need
> what is missing or doesn't work.  To get an idea of what POSIX
> functions in the basis I left as unimplemented stubs, take a look at
> the "cygwin-missing.c" file in the attached 109.30-cygwin.tar.gz.
> Unfortunately, I don't know what CygWin32 functions are not working as
> advertised.
> 
> By the way, I've been curious about Isabelle it since I read some of
> Larry Paulson's papers and books about it.  From where can I download
> a copy of the code?  It sounds like you have a port for SML'97.  I
> imagined that Isabelle was still an SML'90 code.
> 
> Feel free to contact me directly with questions concerning my patches
> and instructions.  No reason to go through the gnu-win32 mailing list
> with your problems.
> 
> Gary
> 
> 
	<< Attachments not included for gnu-win32 mailing list >>




> ----------
> From: 	Andrew Stevens[SMTP:Andrew.Stevens@comlab.ox.ac.uk]
> Sent: 	Tuesday, September 09, 1997 3:42 AM
> To: 	Gary Fuehrer
> Subject: 	Re: SML-NJ for CygWin32
> 
> Gary,
> 
> Do you have your SML-NJ port available anyplace?
> I currently use the Win32 version to run Isabelle
> but a that involves some semi-unsatisfactory hackery in an
> emulation layer to deal with subtle UNIXisms in the Isabelle source.
> 
> I'd be glad to feedback any results I get running Isabelle
> under your port.
> 
> 
> 	Andrew
> 
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Sigbjorn Finne]

> > > 
> > > This is clearly incorrect behavior on the part of CygWin's gcc.
> > Dollar
> > > signs are not valid leading characters of C (or C++) identifiers.
> > > 
> Until this is fixed in the preprocessor, the work-around for building
> SML-NJ is to add a space separator between the "$" and the constant.  I
> will NOT submit this change to the SML-NJ team.  They would likely
> reject it anyhow (I would).


Hi, 

AFAIK, it is ANSI that forbids $ in ids. I'd expect this restriction
to be enabled via -ansi (as per gcc docs.) For whatever reason, the
gcc2 snap included in b18 doesn't pass -$ to cpp with -ansi..

 foo$ gcc -v
 Reading specs from
 c:\usr\H-i386-cygwin32\lib\gcc-lib\i386-cygwin32\cygnus-2.7.2-970404\specs
 gcc version cygnus-2.7.2-970404
 foo$ echo 'subl $FOO, %eax' | gcc -E -Wp,-P -DFOO=4 -
 subl $FOO, %eax
 foo$ echo 'subl $FOO, %eax' | gcc -E -Wp,-P -DFOO=4 -ansi -
 subl $FOO, %eax

Suggested workaround: use -Wp,-$

 foo$ echo 'subl $FOO, %eax' | gcc -E -Wp,-P -DFOO=4 -Wp,-$ -
 subl $4 , %eax

HTH,
--Sigbjorn
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Sergey Okhapkin]

Gary Fuehrer wrote:
> > > 2.	The signal handling in CygWin32 doesn't let me do the following:
> > > a.	Get and Set the "eip" register (or any register) of the
> > > excepting thread.
> > > b.	Ascertain the kind of floating point exception that occurred.
> > > The need is for "siginfo_t" and "sigcontext" parameters that can be
> > > optionally received and modified by signal handlers.
> I have a patch for exception.cc in winsup to add this functionality and
> fix a related bug.

I hope you made modifications in call_handler() and wrap assembly code? 
Current sources  contains all you need to implement this functionality:

  res = SuspendThread (OurhThread);
  debug_printf ("suspend said %d error %d\n", res, GetLastError());
  orig.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER;
  res = GetThreadContext (OurhThread, &orig);

  unsigned int *sp = (unsigned int *) orig.Esp;
  *(--sp) = orig.Eip;	/*  rethere = orig.Eip;*/
  orig.Eip = (unsigned) &&wrap;

  *(--sp) = oldmask;
  *(--sp) = n;
  *(--sp) = (DWORD) pfunc;
  orig.Esp = (DWORD) sp;
  SetThreadContext (OurhThread, &orig); /* Restart the thread */
  ResumeThread (OurhThread);
  /* It looks like a bug in Windows NT, but several waiting threads are not
     always released on SetEvent() without this sleep...
  */
  Sleep(1);
  PulseEvent (signal_arrived);
  WSACancelBlockingCall();
  return;
  /* This code is run in the standard thread space */
  /* Commented out instructions are emulated already */
 wrap:
  asm ("orl	$0x0,(%esp)\n"  /* probe out enough room to play */
      "orl	$0x0,-0x800(%esp)\n"
      "orl	$0x0,-0x1000(%esp)\n"
//      "pushl	_rethere\n"
//      "pushl 	_oldmask\n"
//      "pushl 	_sigarg\n"
//      "pushl 	_sigfunc\n");
      "pusha\n"
      "pushf\n"
      "pushl 	%ebp\n"
      "movl 	%esp,%ebp\n"
      "pushl	0xb*4(%ebp)\n"		// sigarg
      "movl	0xa*4(%ebp),%eax\n"	// sigfunc
      "call 	*%eax\n"
      "pushl	0xc*4(%ebp)\n"		// oldmask
      "call	_set_process_mask\n"
      "leave\n"
      "popf\n"
      "popa\n"
      "popl	_rethere\n"
      "popl	_rethere\n"
      "popl	_rethere\n"
      "ret");

The saved integer registers are accessible from signal handler. Save float 
context just near pusha/pushf and modify sigarg/sigfunc/oldmask offsets.

> > > 3.	There is no SIGVTALRM signal.
> SML-NJ doesn't seem to need this in order to function.  For now, I'm
> providing a dummy #define.

I don't know how to implement virtual timer on win32.

> > > 4.	"L_ctermid" is not defined (but "L_cuserid" is).
> I don't remember why SML-NJ needs this.  For now, I'm providing a dummy
> #define.  It's not critical.

L_ctermid define should be added to stdio.h, and ctermid() call should be 
added to winsup sources for POSIX conformance.

> > > 5.	The following definitions are not in the Posix sockets include
> > > files (only the Windows socket stuff)

The missing defines already added to headers.


--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Sergey Okhapkin]

Gary Fuehrer wrote:
> I turns out that technique won't quite work.  The exceptions that I need
> to handle start in "__cygwin_exception_handler" such as "integer divide
> by zero".  But the current source for "call_handler" is only good for
> dispatching events starting in "ctrl_c_handler".  For Beta 18, someone
> mistakenly thought that having "__cygwin_exception_handler" call
> "ctrl_c_handler" for its implementation would be a good idea.  While it
> was a good idea to have a common signal dispatcher, the current
> "call_handler" can't dispatch both kinds of events.  The reason is that
> "call_handler" assumes the current thread is not the excepting thread;

It's already fixed, but not a good way - __cygwin_exception_handler just 
raises a corresponding signal now and returns. The failed context is lost 
when call_handler is called.

> I'd be glad to make exceptions.cc a correct, POSIX.4 compliant signal
> dispatcher.  But to do it, I need the correct versions of exceptions.cc
> and signal.cc to start from.  The Beta 18 starting point that I have now
> is missing the new beta 19 stuff and the Sergey Okhapkin patches.  How
> can we coordinate this effort?

You'll need the entire current winsup sources - there was too many changes 
after B18. Ask Geoffrey.

> According to Geoffrey Noer, setitimer() and getitimer() are implemented
> in beta 19.  If I understand it correctly, that is the virtual timer and
> therefore SIGVTALRM will be available.

Only the real, but not a virtual timer is implemented.

> > L_ctermid define should be added to stdio.h, and ctermid() call should
> > be
> > added to winsup sources for POSIX conformance.
> >
> That's the way I see it, too.  Even a stub for ctermid() would be
> helpful for beta 19.

Geoffrey, please add the following lines to termios.cc (and to cygwin.din, 
of course):

extern "C"
char *
ctermid (char *s)
{
  static char buf[L_ctermid];

  if (u->self->ctty != -1)
    {
      sprintf (buf, "/dev/tty%d", u->self->ctty);
    }
  else
    buf[0] = '\0';
  if (s)
    strcpy (s, buf);
  return buf;
}

And #define L_ctermid 16 to stdio.h.

> > The missing defines already added to headers.
> >
> Which ones?  Beta 19?  Or one of your patches?

Both B19 sources and my patches.

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Gary Fuehrer]

Brad,

Shortly, I will e-mail you a couple of tar.gz files with the stuff you
need plus instructions.

I will mail this to anyone who wants it.  Just e-mail your request to me
directly (fuehrer@seabase.com) so we don't clutter up the gnu-win32
mailing list.  Please specify whether or not you want me to send a
pre-built cygwin.dll that includes my patches to winsup, as it is 544
kBytes uncompressed.

The SML-NJ team has accepted these changes and are incorporating them
now.  I'm working through this mailing list to get the CygWin32 changes
incorporated into beta 19.  My goal is to get SML-NJ 109.31 and CygWin32
beta 19 working together without patches.  We'll see how it goes.

Since I haven't pointed it out explicitly anywhere else, I just inform
everyone now:  SML-NJ can't work under CygWin32 on top of Win95.  Only
NT.  It's because the SML-NJ runtime for unix variants (of which
CygWin32 is one) depends on a functioning mmap().  And mmap() can't be
implemented by CygWin32 (or anyone else) for Win95 (see winsup/mmap.cc
for a special comment about Win95).

Thanks for your interest,
Gary

PS.  Denis, are you still interested?

> ----------
> From: 	Brad Porter[SMTP:Brad.Porter@MCI.Com]
> Sent: 	Sunday, August 24, 1997 1:22 AM
> To: 	Gary Fuehrer
> Subject: 	Re: SML-NJ for CygWin32
> 
> Do you have diff files or something I can use to get 109.30 to run
> under
> CygWin32 as well?
> 
> Thanks.
> 
> Gary Fuehrer wrote:
> 
> > I have now successfully gotten SML-NJ 109.30 to build and run under
> > CygWin32.  To accomplish this, changes had to be made to both
> cygwin.dll
> > (the winsup project) as well as to the SML-NJ runtime source code.
> The
> > changes to SML-NJ are just to add the necessary settings for the
> > CygWin32 platform.  I am now attempting to get the SML-NJ team to
> > incorporate those changes.  Because they are just additional
> settings to
> > support another platform, I anticipate the SML-NJ team will gladly
> > accept them.
> 
>     ...
> 
> 
> --
> Brad Porter
> 719-535-4135
> v622-4135
> 
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Gary Fuehrer]

> Sergey Okhapkin wrote:
> 
> ----------
> From: 	Sergey Okhapkin[SMTP:sos@prospect.com.ru]
> Sent: 	Sunday, August 24, 1997 12:09 AM
> To: 	'gnu-win32@cygnus.com'; Gary Fuehrer
> Cc: 	'Geoffrey Noer'
> Subject: 	RE: SML-NJ for CygWin32
> 
> Gary Fuehrer wrote:
> > > > 2.	The signal handling in CygWin32 doesn't let me do the
> following:
> > > > a.	Get and Set the "eip" register (or any register) of the
> > > > excepting thread.
> > > > b.	Ascertain the kind of floating point exception that
> occurred.
> > > > The need is for "siginfo_t" and "sigcontext" parameters that can
> be
> > > > optionally received and modified by signal handlers.
> > I have a patch for exception.cc in winsup to add this functionality
> and
> > fix a related bug.
> 
> I hope you made modifications in call_handler() and wrap assembly
> code? 
> Current sources  contains all you need to implement this
> functionality:
> 
	(Body of call_handler() here...)

> The saved integer registers are accessible from signal handler. Save
> float 
> context just near pusha/pushf and modify sigarg/sigfunc/oldmask
> offsets.
> 
I turns out that technique won't quite work.  The exceptions that I need
to handle start in "__cygwin_exception_handler" such as "integer divide
by zero".  But the current source for "call_handler" is only good for
dispatching events starting in "ctrl_c_handler".  For Beta 18, someone
mistakenly thought that having "__cygwin_exception_handler" call
"ctrl_c_handler" for its implementation would be a good idea.  While it
was a good idea to have a common signal dispatcher, the current
"call_handler" can't dispatch both kinds of events.  The reason is that
"call_handler" assumes the current thread is not the excepting thread;
one of the first things "call_handler" does is it suspends the excepting
thread.  But for any event starting in "__cygwin_exception_handler", the
current thread is the excepting thread.  Consequently, "call_handler"
never dispatches and never returns for events like "integer divide by
zero".

So, yes, I made modifications to call_handler() and the wrap assembly
code to get things to work.  But it's not worth sharing for these
reasons:

1.  My patch is an awful kludge on top of a mistake.

2.  I didn't take the time yet to provide the second and third arguments
to signal handlers for events that start in "ctrl_c_handler".

3.  The second and third arguments that I'm passing to the signal
handlers do not conform to POSIX.4 which it should and which wouldn't be
hard to do.

I'd be glad to make exceptions.cc a correct, POSIX.4 compliant signal
dispatcher.  But to do it, I need the correct versions of exceptions.cc
and signal.cc to start from.  The Beta 18 starting point that I have now
is missing the new beta 19 stuff and the Sergey Okhapkin patches.  How
can we coordinate this effort?

> > > > 3.	There is no SIGVTALRM signal.
> > SML-NJ doesn't seem to need this in order to function.  For now, I'm
> > providing a dummy #define.
> 
> I don't know how to implement virtual timer on win32.
> 
According to Geoffrey Noer, setitimer() and getitimer() are implemented
in beta 19.  If I understand it correctly, that is the virtual timer and
therefore SIGVTALRM will be available.

> > > > 4.	"L_ctermid" is not defined (but "L_cuserid" is).
> > I don't remember why SML-NJ needs this.  For now, I'm providing a
> dummy
> > #define.  It's not critical.
> 
> L_ctermid define should be added to stdio.h, and ctermid() call should
> be 
> added to winsup sources for POSIX conformance.
> 
That's the way I see it, too.  Even a stub for ctermid() would be
helpful for beta 19.

> > > > 5.	The following definitions are not in the Posix sockets
> include
> > > > files (only the Windows socket stuff)
> 
> The missing defines already added to headers.
> 
Which ones?  Beta 19?  Or one of your patches?

> --
> Sergey Okhapkin, http://www.lexa.ru/sos
> Moscow, Russia
> Looking for a job
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: SML-NJ for CygWin32

[Gary Fuehrer]

I have now successfully gotten SML-NJ 109.30 to build and run under
CygWin32.  To accomplish this, changes had to be made to both cygwin.dll
(the winsup project) as well as to the SML-NJ runtime source code.  The
changes to SML-NJ are just to add the necessary settings for the
CygWin32 platform.  I am now attempting to get the SML-NJ team to
incorporate those changes.  Because they are just additional settings to
support another platform, I anticipate the SML-NJ team will gladly
accept them.

The changes in winsup included a bug fix in mmap.cc and a patch to
exception.cc which adds functionality.  Another bug, the one I reported
below in gcc's preprocessor, has a workaround for the purposes of this
porting effort, but it would be very nice to get it fixed also.  Below
is my original posting to this news group and how I resolved or worked
around each one.

Here is my current list of issues and questions concerning CygWin32:

1. Will the preprocessor bug in the CygWin32 build of gcc be fixed in
beta 19? (see description of bug in point 1. of previous message below).

2. Will my fix for the mmap bug I described in my posting to gnu-win32
on 8/12/97 entitled "mmap(,,,MAP_PRIVATE,,) bug and fix" be incorporated
in beta 19?

3. What can we do to add my patch in exception handling that provides
the sig_info and sigcontext optional arguments to signal handlers like
is done in every other flavor of Unix?  Without intending any offense to
anyone at all, I might say that the exception handling code in the beta
18 exception.cc is rather poor and lacks the usual optional argument I
need (see point 2. of previous message below).  I know exception
handling has changed (improved) in beta 19.  I also know that Sergey
Okhapkin has some patches to the exception code in beta 18.  And now I
have a patch that adds the optional arguments and fixes another bug
(which I haven't yet reported).  Is there some way that the various
knowledgeable parties involved in the changes to exception.cc can
coordinate in order to get a "much better" version checked into beta 19?
At the very least, could we see the current beta 19 version of
exception.cc?

Thank you,
Gary

> ----------
> From: 	Geoffrey Noer[SMTP:noer@cygnus.com]
> Sent: 	Thursday, July 24, 1997 2:03 AM
> To: 	Gary Fuehrer
> Cc: 	noer@cygnus.com
> Subject: 	Re: FW: SML-NJ for CygWin32
> 
> I'm really sorry, but I'm not going to be able to look into this
> in detail.  Beta 19 when it comes out will fix a lot of
> signals-related
> issues so that may help.  But several of the calls you are missing
> still
> haven't been implemented yet so it won't solve all of your problems...
> -gjn
> 
> Gary Fuehrer wrote:
> > 
> > I am attempting to get Standard ML of New Jersey (version 109.29)
> built
> > and working under CygWin32 (version b18).  CygWin32 is excellent,
> and
> > I'm having only minor difficulties getting this to happen.  Would
> > someone consider the following problems I'm having and give me some
> > feedback as to how resolvable/impossible they might be?
> > 
> > 1.  SML-NJ builds an assembler source file by passing a bunch of
> macro
> > definitions and statements through gcc's preprocessor.  For x86,
> certain
> > assembly statements need to have a dollar sign before a numeric
> constant
> > (e.g. movl	$3, %eax).  Combined with C language macros, the
> > following kind of statements get passed to gcc when building the
> SML-NJ
> > runtime executable:
> > 	#define REQ_CALLC   3
> > 	:
> > 	movl	$REQ_CALLC, %eax
> > 
> > The expected output of the preprocessor is:
> > 	movl	$3, %eax
> > 
> > With the CygWin32 version of gcc, I get the following:
> > 	movl	$REQ_CALLC, %eax
> > 
> > It looks as if the dollar sign is being interpreted as part of the
> name
> > of a symbol, which is then not defined as a macro and hence remains
> > un-expanded.  In demonstration of this, I can add a space separator
> > between the dollar sign and the macro and things work:
> > 	movl $ REQ_CALLC, %eax  ==> preprocessor ==>  movl $ 3, %eax
> > 
> > This is clearly incorrect behavior on the part of CygWin's gcc.
> Dollar
> > signs are not valid leading characters of C (or C++) identifiers.
> > 
Until this is fixed in the preprocessor, the work-around for building
SML-NJ is to add a space separator between the "$" and the constant.  I
will NOT submit this change to the SML-NJ team.  They would likely
reject it anyhow (I would).

> > 
> > 2.	The signal handling in CygWin32 doesn't let me do the following:
> > a.	Get and Set the "eip" register (or any register) of the
> > excepting thread.
> > b.	Ascertain the kind of floating point exception that occurred.
> > The need is for "siginfo_t" and "sigcontext" parameters that can be
> > optionally received and modified by signal handlers.
I have a patch for exception.cc in winsup to add this functionality and
fix a related bug.

> > 
> > 3.	There is no SIGVTALRM signal.
SML-NJ doesn't seem to need this in order to function.  For now, I'm
providing a dummy #define.

> > 
> > 4.	"L_ctermid" is not defined (but "L_cuserid" is).
I don't remember why SML-NJ needs this.  For now, I'm providing a dummy
#define.  It's not critical.

> > 
> > 5.	The following definitions are not in the Posix sockets include
> > files (only the Windows socket stuff)
> > 	#    define SO_SNDBUF       0x1001          /* send buffer size
> > */
> > 	#    define SO_RCVBUF       0x1002          /* receive buffer
> > size */
> > 	#    define SO_SNDLOWAT     0x1003          /* send low-water
> > mark */
> > 	#    define SO_RCVLOWAT     0x1004          /* receive low-water
> > mark */
> > 	#    define SO_SNDTIMEO     0x1005          /* send timeout */
> > 	#    define SO_RCVTIMEO     0x1006          /* receive timeout
> > */
> > 	#    define SO_ERROR        0x1007          /* get error status
> > and clear */
> > 	#    define SO_TYPE         0x1008          /* get socket type
> > */
I don't remember why SML-NJ needs this.  For now, I'm providing dummy
#defines.  It's not critical.

> > 
> > 6.	This header file doesn't exist:
> > 			#include <netinet/tcp.h>
I don't remember why SML-NJ needs this.  For now I'm leaving it out.
It's not critical.

> > 
> > 7.	The following functions, declared in CygWin's header files, fail
> > to link:
> > 	getnetbyname
> > 	getnetbyaddr
> > 	fpgetround
> > 	fpsetround
> > 	pause
> > 	getgroups
> > 	ctermid
> > 	mkfifo
> > 	fchown
> > 	fpathconf
> SML-NJ doesn't seem to need these to funcion.  I made a mistake about
> needing fpsetround and fpgetround.  Some others are in beta 19 (ie
> getgroups, pause, fpathconf).  Posix library funcionality in SML-NJ
> for CygWin32 is reduced by what remains unimplemented (getnetbyname,
> getnetbyaddr, mkfifo, fchown, ctermid).
> 
> > 
> > 
> > I would appreciate any information you can give me on how these
> problems
> > will be resolved in future releases of CygWin32.
> > 
> > Thanks,
> > Gary
> > 
> 
> 
> -- 
> Geoffrey Noer
> noer@cygnus.com
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".