1. RE: IRC client
Hi Chris,
I never got any code to work with an IRC server but I do remember
there was some discussion about it a few months ago. From memory
I think Kat had the basics working using euTcp4u.
I'm sure Kat will respond shortly with much more detail.
Regards,
Ray Smith
bensler at mail.com wrote:
> Hi all,
>
> I'm currently experimenting with LAN networking and have taken
> curiosity in attempting to build a simple IRC client.
>
> Can someone give me a simple example of establishing a client
> connection to an IRC server? Or perhaps there is already an IRC
> compatible client in the archives already and I've overlooked it.
>
> I've tried implementing a client connection, using eutcp4u, and it
> just hangs waiting for connection. I would assume I should be able to
> create a standard tcp connection, and from there I would send my numeric
>
> commands to verify my connection as an IRC client, and to logon, but I
> can't even get that far. I should note that I was attempting my client
> connection using Ray's client prog included with eutcp4u.
>
> Honestly, I have no idea what I'm doing :P So any help would be
> greatly appreciated.
>
> I have the IRC RFC's, but it doesn't describe any specific procedures
> for creating a connection, other than required logon commands and how
> they are processed.
>
> It's probably something very simple, or maybe I don't have my network
> set correctly. Though I'm able to create a connection using the eutcp4u
> client and server.
>
> Maybe someone can direct me to some more useful documentation, other
> than the IRC RFC protocol docs.
>
> TIA
> Chris
>
>
Ray Smith
http;//www.geocities.com/ray_223
2. RE: IRC client
- Posted by bensler at mail.com
Jan 05, 2002
Kat,
I'd be interested to see your program, working or not. All that I'm
really interested in is being able to establish a connection to the
server.
>From there, I'd like to make my own tracks.
Maybe you can just guide me to where I'm going wrong.
Is eutcp4u sufficient 'as is' in the archives, or does it require
modifications to make it work with IRC?
I've looked in the archives for your IRC.exw, but have turned up null.
Chris
Kat wrote:
> On 5 Jan 2002, at 4:45, bensler at mail.com wrote:
>
> >
> > Hi all,
> >
> > I'm currently experimenting with LAN networking and have taken
> > curiosity in attempting to build a simple IRC client.
> >
> > Can someone give me a simple example of establishing a client
> > connection to an IRC server? Or perhaps there is already an IRC
> > compatible client in the archives already and I've overlooked it.
>
> I did get a irc client going with tcp4u, and connected to sorcerynet and
>
> dalnet at the same time, in several channels at once on each net.
> Problem
> is, i got distracted while i was changing it over to use less cpu time,
> and
> broke it! I was also adding features like mirc, the events stuff, like
> on_text
> and on_notice, and on_ctcp, and etc.. It ran great, kept all the channel
> stuff
> separate thru the events, and separate based on net too, and yet the
> events
> could still access data from other servers and other channels.
>
> I'll try to get it going again....
>
> Kat
>
>
3. RE: IRC client
- Posted by bensler at mail.com
Jan 05, 2002
eureka :P
I found the tcp4u fix that Kat had posted back in July, I am now able
to connect to the server.
Now, to figure out how to log on!
Ray, you really should post an update of eutcp4u, with the needed fixes,
would save some trouble :)
I haven't looked into it, but perhaps it's a similar problem with
eulibnet, I wasn't able to connect with that one either.
here is Kat's fix..
I found two bugs in tcp4u:
line 505 in function tcp4u_connect()
connect_socket should be an atom, it goes outside the range of integers
lines:
495: port_addr = allocate(2)
496: poke(port_addr, port)
make them into:
port_addr = allocate(4)
poke4(port_addr,port)
That should be enough to get started. I don't have a gui yet, but that's
not
really on the list of things to do. Of course, until last nite, i wasn't
going to
write an irc client either.......
Kat
bensler at mail.com wrote:
> Kat,
>
> I'd be interested to see your program, working or not. All that I'm
> really interested in is being able to establish a connection to the
> server.
> >From there, I'd like to make my own tracks.
> Maybe you can just guide me to where I'm going wrong.
> Is eutcp4u sufficient 'as is' in the archives, or does it require
> modifications to make it work with IRC?
>
> I've looked in the archives for your IRC.exw, but have turned up null.
>
> Chris
>
>
> Kat wrote:
> > On 5 Jan 2002, at 4:45, bensler at mail.com wrote:
> >
> > >
> > > Hi all,
> > >
> > > I'm currently experimenting with LAN networking and have taken
> > > curiosity in attempting to build a simple IRC client.
> > >
> > > Can someone give me a simple example of establishing a client
> > > connection to an IRC server? Or perhaps there is already an IRC
> > > compatible client in the archives already and I've overlooked it.
> >
> > I did get a irc client going with tcp4u, and connected to sorcerynet and
> >
> >
> > dalnet at the same time, in several channels at once on each net.
> > Problem
> > is, i got distracted while i was changing it over to use less cpu time,
> > and
> > broke it! I was also adding features like mirc, the events stuff, like
> > on_text
> > and on_notice, and on_ctcp, and etc.. It ran great, kept all the channel
> >
> > stuff
> > separate thru the events, and separate based on net too, and yet the
> > events
> > could still access data from other servers and other channels.
> >
> > I'll try to get it going again....
> >
> > Kat
> >
> >
4. RE: IRC client
- Posted by bensler at mail.com
Jan 07, 2002
So far I am able to connect my IRC client, logon, join/part channels,
send msgs, quit a server and connect to a different one, and any other
RAW command I like. All in all it's mostly functional, but archaic :)
But I've ran into a small problem, rather an inconvenience. I see no way
of setting the timeout value for tcp4u_connect(). I think the timeout is
about 60 seconds, but I can't change it. This can get rather annoying,
I'd like to be able to set it much lower.
Any help is appreciated.
Also, I can't seem to be able to respond to PING's.
According to the telnet-IRC guide, the reponse is PONG <ip/socket>.
for example, this is what I am trying to do.
< PING :127.0.0.1
> PONG 127.0.0.1
Just now, I've thought maybe I should try a ctcp pong. I'll try in a
minute, but I already started writing :P
cheers!
Chris
5. RE: IRC client
On 8 Jan 2002, at 3:24, bensler at mail.com wrote:
>
> So far I am able to connect my IRC client, logon, join/part channels,
> send msgs, quit a server and connect to a different one, and any other
> RAW command I like. All in all it's mostly functional, but archaic :)
>
> But I've ran into a small problem, rather an inconvenience. I see no way
> of setting the timeout value for tcp4u_connect(). I think the timeout is
> about 60 seconds, but I can't change it. This can get rather annoying,
> I'd like to be able to set it much lower.
> Any help is appreciated.
>
> Also, I can't seem to be able to respond to PING's.
> According to the telnet-IRC guide, the reponse is PONG <ip/socket>.
> for example, this is what I am trying to do.
> < PING :127.0.0.1
> > PONG 127.0.0.1
>
> Just now, I've thought maybe I should try a ctcp pong. I'll try in a
> minute, but I already started writing :P
You prolly already found a ctcp pong will not work, the protocol is different.
This is my code for handling PING-PONG:
if equal(parsed_data[1],"PING") then
if equal(parsed_data[2],":" & server_name)
then msg(server_name,"PONG :"&server_name)
else msg(parsed_data[2][2..length(parsed_data[2])],"PONG
:"&server_name)
end if
puts(1,"PING :"&server_name&"\nPONG :"&server_name&"\n")
puts(logfile,"PING :"&server_name&"\nPONG :"&server_name&"\n")
flush(logfile)
data = ""
parsed_data = ""
end if
Kat
6. RE: IRC client
Hi Chris,
> But I've ran into a small problem, rather an inconvenience. I see no way
>
> of setting the timeout value for tcp4u_connect(). I think the timeout is
>
> about 60 seconds, but I can't change it. This can get rather annoying,
> I'd like to be able to set it much lower.
> Any help is appreciated.
The base library Tcp4u doesn't appear to have a way to change the
timeout on a connect.
You could look at the source code (available from the authors web
site for more information).
Regards,
Ray Smith
http;//www.geocities.com/ray_223
7. RE: IRC client
bensler at mail.com wrote:
Hi Chris (and Kat),
I have taken your advice and attempted to update euTcp4u.
I put the below changes into my source and tried to run my test
programs but they failed.
With the changes you have made can you run the "server.exw" and
"client.exw" that come with euTcp4u?
I left "connect_socket" as an atom but removed the second change and
my test programs work again.
Does your IRC code work if the second change is not used?
I might also wrap the UDP functions as well ... see how I go.
Regards,
Ray Smith
> Ray, you really should post an update of eutcp4u, with the needed fixes,
>
> would save some trouble :)
> I haven't looked into it, but perhaps it's a similar problem with
> eulibnet, I wasn't able to connect with that one either.
>
> here is Kat's fix..
>
> I found two bugs in tcp4u:
>
> line 505 in function tcp4u_connect()
> connect_socket should be an atom, it goes outside the range of integers
>
> lines:
> 495: port_addr = allocate(2)
> 496: poke(port_addr, port)
>
> make them into:
>
> port_addr = allocate(4)
> poke4(port_addr,port)
>
> That should be enough to get started.
Ray Smith
http;//www.geocities.com/ray_223
8. RE: IRC client
- Posted by bensler at mail.com
Jan 14, 2002
Now that I relook at Kat's fix, I'm surprised to find that she was
incorrect! Shame on you Kat :P
Socket variables should be atoms, but the second fix allocates 4 bytes
for the port, when it can never exceed 2 bytes.
So, yes, only the socket variables need to be changed to atoms.
Other than that, I've used every TCP routine in the lib, and have run
into no problems.
Chris
Ray Smith wrote:
>
> bensler at mail.com wrote:
>
> Hi Chris (and Kat),
>
> I have taken your advice and attempted to update euTcp4u.
>
> I put the below changes into my source and tried to run my test
> programs but they failed.
>
> With the changes you have made can you run the "server.exw" and
> "client.exw" that come with euTcp4u?
>
> I left "connect_socket" as an atom but removed the second change and
> my test programs work again.
> Does your IRC code work if the second change is not used?
>
> I might also wrap the UDP functions as well ... see how I go.
>
> Regards,
>
> Ray Smith
>
>
> > Ray, you really should post an update of eutcp4u, with the needed fixes,
> >
> >
> > would save some trouble :)
> > I haven't looked into it, but perhaps it's a similar problem with
> > eulibnet, I wasn't able to connect with that one either.
> >
> > here is Kat's fix..
> >
> > I found two bugs in tcp4u:
> >
> > line 505 in function tcp4u_connect()
> > connect_socket should be an atom, it goes outside the range of integers
> >
> > lines:
> > 495: port_addr = allocate(2)
> > 496: poke(port_addr, port)
> >
> > make them into:
> >
> > port_addr = allocate(4)
> > poke4(port_addr,port)
> >
> > That should be enough to get started.
>
>
> Ray Smith
> http;//www.geocities.com/ray_223
>
>
9. RE: IRC client
- Posted by bensler at mail.com
Jan 14, 2002
I should mention, in case it misses you for some reason..
All the socket variables in all the routines need to be atoms..
I came across about 4 or 5 instances where it needed to be fixed..
I'm sure there are more. I never went thru the lib and fixed them all.
I spose I should :P
Chris
Ray Smith wrote:
>
> bensler at mail.com wrote:
>
> Hi Chris (and Kat),
>
> I have taken your advice and attempted to update euTcp4u.
>
> I put the below changes into my source and tried to run my test
> programs but they failed.
>
> With the changes you have made can you run the "server.exw" and
> "client.exw" that come with euTcp4u?
>
> I left "connect_socket" as an atom but removed the second change and
> my test programs work again.
> Does your IRC code work if the second change is not used?
>
> I might also wrap the UDP functions as well ... see how I go.
>
> Regards,
>
> Ray Smith
>
>
> > Ray, you really should post an update of eutcp4u, with the needed fixes,
> >
> >
> > would save some trouble :)
> > I haven't looked into it, but perhaps it's a similar problem with
> > eulibnet, I wasn't able to connect with that one either.
> >
> > here is Kat's fix..
> >
> > I found two bugs in tcp4u:
> >
> > line 505 in function tcp4u_connect()
> > connect_socket should be an atom, it goes outside the range of integers
> >
> > lines:
> > 495: port_addr = allocate(2)
> > 496: poke(port_addr, port)
> >
> > make them into:
> >
> > port_addr = allocate(4)
> > poke4(port_addr,port)
> >
> > That should be enough to get started.
>
>
> Ray Smith
> http;//www.geocities.com/ray_223
>
>
10. RE: IRC client
On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
>
> Now that I relook at Kat's fix, I'm surprised to find that she was
> incorrect! Shame on you Kat :P
>
> Socket variables should be atoms, but the second fix allocates 4 bytes
> for the port, when it can never exceed 2 bytes.
Naturally, i would not have figured out the 2nd patch if i had not still had a
problem. Once i did this, everything ran fine. <shrug>
> So, yes, only the socket variables need to be changed to atoms.
> Other than that, I've used every TCP routine in the lib, and have run
> into no problems.
>
>
> Chris
>
>
> Ray Smith wrote:
> >
> > bensler at mail.com wrote:
> >
> > Hi Chris (and Kat),
> >
> > I have taken your advice and attempted to update euTcp4u.
> >
> > I put the below changes into my source and tried to run my test
> > programs but they failed.
> >
> > With the changes you have made can you run the "server.exw" and
> > "client.exw" that come with euTcp4u?
> >
> > I left "connect_socket" as an atom but removed the second change and
> > my test programs work again.
> > Does your IRC code work if the second change is not used?
No, it didn't. I still had a problem, which this patch took care of. However, i
dio not remember if it was a problem in tcp4u, or the 2-byte allocation code.
For normal web browsing on port 80, 2 bytes worked fine, i ran into problem
when using ports over 32767 for localhost connections, like 50004. Maybe
it's a problem with the sign bit on a signed 2byte signed integer? I don't just
remember, sorry, but the 4-byte allocation made it work like a breeze.
I still have not gotten my irc code working again. The actual connect part is
fine, as far as i can tell, but the server-specific logging into nested
sequences is the problem,, i wish we could get nested values in huge
sequences in debug, displayed as needed. The code to store data is like 8
lines, the code to display fields as i debug is 50+ lines. Doing an abort to get
a ex.err still doesn't show me enough. 
Kat
11. RE: IRC client
- Posted by bensler at mail.com
Jan 14, 2002
Still looking at that code..
port_addr = allocate(2)
poke(port_addr, port)
Wouldn't this poke only the 1st byte of the port value?
Chris
Kat wrote:
> On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
>
> >
> > Now that I relook at Kat's fix, I'm surprised to find that she was
> > incorrect! Shame on you Kat :P
> >
> > Socket variables should be atoms, but the second fix allocates 4 bytes
> > for the port, when it can never exceed 2 bytes.
>
> Naturally, i would not have figured out the 2nd patch if i had not still
> had a
> problem. Once i did this, everything ran fine. <shrug>
>
> > So, yes, only the socket variables need to be changed to atoms.
> > Other than that, I've used every TCP routine in the lib, and have run
> > into no problems.
> >
> >
> > Chris
> >
> >
> > Ray Smith wrote:
> > >
> > > bensler at mail.com wrote:
> > >
> > > Hi Chris (and Kat),
> > >
> > > I have taken your advice and attempted to update euTcp4u.
> > >
> > > I put the below changes into my source and tried to run my test
> > > programs but they failed.
> > >
> > > With the changes you have made can you run the "server.exw" and
> > > "client.exw" that come with euTcp4u?
> > >
> > > I left "connect_socket" as an atom but removed the second change and
> > > my test programs work again.
> > > Does your IRC code work if the second change is not used?
>
> No, it didn't. I still had a problem, which this patch took care of.
> However, i
> dio not remember if it was a problem in tcp4u, or the 2-byte allocation
> code.
> For normal web browsing on port 80, 2 bytes worked fine, i ran into
> problem
> when using ports over 32767 for localhost connections, like 50004. Maybe
>
> it's a problem with the sign bit on a signed 2byte signed integer? I
> don't just
> remember, sorry, but the 4-byte allocation made it work like a breeze.
>
> I still have not gotten my irc code working again. The actual connect
> part is
> fine, as far as i can tell, but the server-specific logging into nested
> sequences is the problem,, i wish we could get nested values in huge
> sequences in debug, displayed as needed. The code to store data is like
> 8
> lines, the code to display fields as i debug is 50+ lines. Doing an
> abort to get
> a ex.err still doesn't show me enough.
>
> Kat
>
>
12. RE: IRC client
- Posted by bensler at mail.com
Jan 14, 2002
I just downloaded the update, and it failed to connect my IRC client..
I am correct, it only pokes the first byte, you need to poke2 the port
value. I tested already, and it works.
Chris
bensler at mail.com wrote:
> Still looking at that code..
> port_addr = allocate(2)
> poke(port_addr, port)
>
> Wouldn't this poke only the 1st byte of the port value?
>
> Chris
>
>
> Kat wrote:
> > On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
> >
> > >
> > > Now that I relook at Kat's fix, I'm surprised to find that she was
> > > incorrect! Shame on you Kat :P
> > >
> > > Socket variables should be atoms, but the second fix allocates 4 bytes
> > > for the port, when it can never exceed 2 bytes.
> >
> > Naturally, i would not have figured out the 2nd patch if i had not still
> >
> > had a
> > problem. Once i did this, everything ran fine. <shrug>
> >
> > > So, yes, only the socket variables need to be changed to atoms.
> > > Other than that, I've used every TCP routine in the lib, and have run
> > > into no problems.
> > >
> > >
> > > Chris
> > >
> > >
> > > Ray Smith wrote:
> > > >
> > > > bensler at mail.com wrote:
> > > >
> > > > Hi Chris (and Kat),
> > > >
> > > > I have taken your advice and attempted to update euTcp4u.
> > > >
> > > > I put the below changes into my source and tried to run my test
> > > > programs but they failed.
> > > >
> > > > With the changes you have made can you run the "server.exw" and
> > > > "client.exw" that come with euTcp4u?
> > > >
> > > > I left "connect_socket" as an atom but removed the second change and
> > > > my test programs work again.
> > > > Does your IRC code work if the second change is not used?
> >
> > No, it didn't. I still had a problem, which this patch took care of.
> > However, i
> > dio not remember if it was a problem in tcp4u, or the 2-byte allocation
> > code.
> > For normal web browsing on port 80, 2 bytes worked fine, i ran into
> > problem
> > when using ports over 32767 for localhost connections, like 50004. Maybe
> >
> >
> > it's a problem with the sign bit on a signed 2byte signed integer? I
> > don't just
> > remember, sorry, but the 4-byte allocation made it work like a breeze.
> >
> > I still have not gotten my irc code working again. The actual connect
> > part is
> > fine, as far as i can tell, but the server-specific logging into nested
> > sequences is the problem,, i wish we could get nested values in huge
> > sequences in debug, displayed as needed. The code to store data is like
> > 8
> > lines, the code to display fields as i debug is 50+ lines. Doing an
> > abort to get
> > a ex.err still doesn't show me enough.
> >
> > Kat
> >
> >
13. RE: IRC client
On 15 Jan 2002, at 6:45, bensler at mail.com wrote:
>
> I just downloaded the update, and it failed to connect my IRC client..
> I am correct, it only pokes the first byte, you need to poke2 the port
> value. I tested already, and it works.
I remember now! there was no poke2 before! (or i didn't know of it.) So
instead of two pokes, i changed both lines to poke4, which doesn't hurt
anything.
Kat
> Chris
>
> bensler at mail.com wrote:
> > Still looking at that code..
> > port_addr = allocate(2)
> > poke(port_addr, port)
> >
> > Wouldn't this poke only the 1st byte of the port value?
> >
> > Chris
> >
> >
> > Kat wrote:
> > > On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
> > >
> > > >
> > > > Now that I relook at Kat's fix, I'm surprised to find that she was
> > > > incorrect! Shame on you Kat :P
> > > >
> > > > Socket variables should be atoms, but the second fix allocates 4 bytes
> > > > for
> > > > the port, when it can never exceed 2 bytes.
> > >
> > > Naturally, i would not have figured out the 2nd patch if i had not still
> > >
> > > had a
> > > problem. Once i did this, everything ran fine. <shrug>
> > >
> > > > So, yes, only the socket variables need to be changed to atoms.
> > > > Other than that, I've used every TCP routine in the lib, and have run
> > > > into
> > > > no problems.
> > > >
> > > >
> > > > Chris
> > > >
> > > >
> > > > Ray Smith wrote:
> > > > >
> > > > > bensler at mail.com wrote:
> > > > >
> > > > > Hi Chris (and Kat),
> > > > >
> > > > > I have taken your advice and attempted to update euTcp4u.
> > > > >
> > > > > I put the below changes into my source and tried to run my test
> > > > > programs but they failed.
> > > > >
> > > > > With the changes you have made can you run the "server.exw" and
> > > > > "client.exw" that come with euTcp4u?
> > > > >
> > > > > I left "connect_socket" as an atom but removed the second change and
> > > > > my
> > > > > test programs work again. Does your IRC code work if the second change
> > > > > is not used?
> > >
> > > No, it didn't. I still had a problem, which this patch took care of.
> > > However, i
> > > dio not remember if it was a problem in tcp4u, or the 2-byte allocation
> > > code. For normal web browsing on port 80, 2 bytes worked fine, i ran into
> > > problem when using ports over 32767 for localhost connections, like 50004.
> > > Maybe
> > >
> > >
> > > it's a problem with the sign bit on a signed 2byte signed integer? I
> > > don't just
> > > remember, sorry, but the 4-byte allocation made it work like a breeze.
> > >
> > > I still have not gotten my irc code working again. The actual connect
> > > part is
> > > fine, as far as i can tell, but the server-specific logging into nested
> > > sequences is the problem,, i wish we could get nested values in huge
> > > sequences in debug, displayed as needed. The code to store data is like 8
> > > lines, the code to display fields as i debug is 50+ lines. Doing an abort
> > > to
> > > get a ex.err still doesn't show me enough.
> > >
> > > Kat
> > >
> > >
>
>
>
14. RE: IRC client
Hi Chris,
Thanks for finding the bug!!!!
I have updated euTcp4u.ew and loaded it up on the web site.
Note: I had to rename the zip file because of proxy cache's.
Thanks again,
Ray Smith
bensler at mail.com wrote:
> Still looking at that code..
> port_addr = allocate(2)
> poke(port_addr, port)
>
> Wouldn't this poke only the 1st byte of the port value?
>
> Chris
>
>
> Kat wrote:
> > On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
> >
> > >
> > > Now that I relook at Kat's fix, I'm surprised to find that she was
> > > incorrect! Shame on you Kat :P
> > >
> > > Socket variables should be atoms, but the second fix allocates 4 bytes
> > > for the port, when it can never exceed 2 bytes.
> >
> > Naturally, i would not have figured out the 2nd patch if i had not still
> >
> > had a
> > problem. Once i did this, everything ran fine. <shrug>
> >
> > > So, yes, only the socket variables need to be changed to atoms.
> > > Other than that, I've used every TCP routine in the lib, and have run
> > > into no problems.
> > >
> > >
> > > Chris
> > >
> > >
> > > Ray Smith wrote:
> > > >
> > > > bensler at mail.com wrote:
> > > >
> > > > Hi Chris (and Kat),
> > > >
> > > > I have taken your advice and attempted to update euTcp4u.
> > > >
> > > > I put the below changes into my source and tried to run my test
> > > > programs but they failed.
> > > >
> > > > With the changes you have made can you run the "server.exw" and
> > > > "client.exw" that come with euTcp4u?
> > > >
> > > > I left "connect_socket" as an atom but removed the second change and
> > > > my test programs work again.
> > > > Does your IRC code work if the second change is not used?
> >
> > No, it didn't. I still had a problem, which this patch took care of.
> > However, i
> > dio not remember if it was a problem in tcp4u, or the 2-byte allocation
> > code.
> > For normal web browsing on port 80, 2 bytes worked fine, i ran into
> > problem
> > when using ports over 32767 for localhost connections, like 50004. Maybe
> >
> >
> > it's a problem with the sign bit on a signed 2byte signed integer? I
> > don't just
> > remember, sorry, but the 4-byte allocation made it work like a breeze.
> >
> > I still have not gotten my irc code working again. The actual connect
> > part is
> > fine, as far as i can tell, but the server-specific logging into nested
> > sequences is the problem,, i wish we could get nested values in huge
> > sequences in debug, displayed as needed. The code to store data is like
> > 8
> > lines, the code to display fields as i debug is 50+ lines. Doing an
> > abort to get
> > a ex.err still doesn't show me enough.
> >
> > Kat
> >
> >
Ray Smith
http;//www.geocities.com/ray_223
