TCP-Group Digest 220791.1815
daily posting
Date: Sun, 21 Jul 1991 18:46:05 -0500
Subject: Compiling problems with TC++ v1.0 and NOS
Hello all,
I have solved my 'little' problem that I was having with compiling
NOS with TC++ v1.0.
For the benefit of other neophytes in the NOS realm, I will recount
the tale of mystery and mayhem. For the 'experts', you may go about
your business, unless you would like to muse over the follies of the
naive.
>From the word go I have had problems with compiling NOS under TC++.
The one problem that had me stumped for a few months was the error
that kept cropping up in various modules to the effect:
Error: Type mismatch in parameter 'parameter'.
For which the 'manual' states, and I quote:
"Your source file declared the function called via a function
pointer with a prototype, and the named parameter could not
be converted to the declared parameter type".
After many months of scratching my head, trying to understand the
aforementioned error message I came to three conclusions.
1. Borland does not know what they are doing.
2. I do not know what I'm doing.
3. You do not know what you are doing.
So I turned to my learned colleagues, the members of the tcp-group,
for some assistance in this intricate matter. What was the response
you may ask? Silence was all that was heard.
I therefore rolled up my sleeves, and set my mind to solve this
rite of initiation that has been set before me. After two days
of pounding on the keyboard, and waiting for my rusty old XT
to compile the problem code, I haps to come upon the thought
"What if I try and change the order of the include definitions".
After a few lightning fast keystrokes, and some more time waiting
for rusty to compile, success was mine at last.
So if you are having some problems compiling NOS with type mismatch
errors, try to put the include file that pertains the closest to
that source module under the global.h definition.
Example: For pc.c:
#define "global.h"
#define "pc.h"
...
...
I have always had problems with the way that the include files were
handled in NOS. It seems to me that the order of include file definition
should not matter, but it does in this case.
I would like to interject some thoughts on include files, but I won't
for two reasons:
1. It usually is not a good idea to give constructive criticism
when you are mad.
2. What good would it do anyway??? :-)
I hope that this helps some poor unfortunate like me, rise from the
ashes of dispair.
73's
Brian
ax25 : WD0EFL @ N0DAI.MN.USA.NA
internet : wd0efl @ g1xrl.vware.mn.org
----
From: "Milo S. Medin" (NASA ARC NSI Project Office) <me...@nsipo.nasa.gov>
Date: Sun, 21 Jul 91 18:56:31 -0700
Subject: tcp-group available via usenet?
Folks, I'm wondering if the tcp-group mail traffic is gatewayed to
a usenet newsgroup, so I could read it along with all my other
"large" mailing lists via xrn and friends? I can't seem to find it
on the NNTP servers I can access...
Thanks,
Milo
----
From: "Rob Mayfield, ASC" <XT...@Levels.UniSA.Edu.Au>
Date: Mon, 22 Jul 1991 17:23 +0930
Subject: Multiple DRSI Cards, and bcc2++ gs
Anyone know of any tricks in getting more than one drsi card to work under
pa0gri nos 1.7e using the scc driver ?? we can get one card working, although
it doesnt seem to be able to hear anything no matter what we do to the
tuning thereof. But when 2 cards are installed, and it beacons on power
up, it keys the xmittr with a single tone and _stays_ that way !! ad infinitum
We used the init command and then attached each channel 0-3 to our names and
other entries.
We worked out that the param commands want timings in ticks, 55ms ea or so.
Any ideas ???
Also, Ive tried making nos using borland turbo c++ v2.0, and it seemed to work
fine up till 1.7d, but 1.7e gets quemm exception errors always at the end
of the first received message on smtp, b4 it prints up the new mail from
banner .....
The only mods ive made are to change the compiler def in the makefile from
tcc to bcc ......
Could the tmp file drama's caused something in bcc2++ to crash and burn ??
Can anyone enlighten me as to the difference between tcc and bcc, will they
use the same libs for nos, or has tcc got diff ones ?? (it says on the box
"includes bcc2".
Ive been standing on the C diving board for a while now :-) .......
rgd's (73's) rob
_--_/\ rob mayfield [technical analyst][vk5 net44 co-or] australian
/ oz \ internet xt...@lv.sait.edu.au submarine
/ vk \ packet (ampr) vk5xxx@vk5xip.#sa.aus.oc corporation
\ __ / applelink aust0177 or aust...@applelink.apple.com
\_/ *_/ african swallow po box 46, henley beach +6182351377h
o *here! south australia, 5022 +6183487713w
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Thu, 18 Jul 91 05:09:05 EST
Subject: More on stabilizing NOS
(The following is a relayed posting on request from Rich Vitello, WA1EQU.
-- Mike Bilow, N1BEE, mik...@idsvax.ids.com)
Hi Mike, as you probably know, I follow the Internet tcp-group very closely.
However, since I do this via the amprnet (I receive the Internet files on the
amprnet and k2euh in NY) I can not respond via Internet, hence this message.
I wanted to comment on the "Stabilized" version of NOS dialog that's been
taking place on tcp-group ...personally I agree with John Ackerman - AG9V, if
your version of GRI turns out to be "stable" why not use that as the base?
I've been running it since you posted it, and before that I ran the previous
version which also seemed to run fine. As you know I'm not actually a switch
for the amprnet, however I am the smtp allne mail drop for the entire NE area
as well as being the local file server for all the tcp-group files going back
over four years (3.25 meg zipped.) As a result, my system handles tons of mail
and ftps which your version of GRI seems to do quite well.
I read your posting of concerns for establishing a "stabilized" version of NOS,
but perhaps using the latest and greatest is the answer. I am willing to
"volunteer" the advertising of such a version in the now famous New England TCP
Association newsletter "The NE TCPer". As you know, the "TCPer" as it's come
to be known, has circulation world wide and would reach many IPers that do not
have access to the Internet (a common complaint.)
Please post this to the tcp-group, as I mentioned I do not have access and so
others in the group won't be able to read about my offer to publish in
The NE TCPer. By the way, thanks for all work on NOS Mike, and to everyone
that's ever contributed to the tcp-group as these postings reach more people
than you'll ever realize.
73 from Rich Vitello WA1EQU [4.56.0.131]
President of The New England TCP Association
252 Stow Road, Harvard, MA 01451, USA
ax25 - wa1...@wa1phy.ma.usa
For more info finger upd...@wa1equ.ampr.org
(Here is my reply to Rich. -- Mike)
You're right, I suppose, about tcp-group being very widely read. I tend to
think of it as a small bunch of people, maybe 10 or 15, who actually post!
I will add your address (for the NE TCPer) and post your message.
I am honestly not anxious to become the distribution point for "the" stable
NOS version. First, I don't have FTP access to the Internet. I can get
around that by prevailing on friends of mine. I should also have full access
Real Soon Now, and that will cease to be a problem. At the moment, it is.
Second, the releases of GRINOS I have been distributing go through three sets
of hands before reaching the world: Phil Karn, KA9Q, then Gerard van der
Grinten, PA0GRI, then me. When either of them makes a change, I pretty much
have to follow along. This is one reason for the frequent updates.
Third, the version is not yet stable. While it is good enough for everyday
use, and is even running OK at the w1cg-9 switch, there are some serious
problems that are not generally known. For example, in the next release,
the stack space for the remote server is going to have to be increased.
Bernie, NU1S, managed to crash both me and switch.w1cg-9 by sending about
10 remote kicks to each of us on two separate occasions. The most serious
problem is that the memory allocator is no good. If NOS ever runs
sufficiently low on core, it tries to do a garbage collect, and all garbage
collects currently cause corruption of memory. While you can get around
this by (1) setting "mem eff on" which is now the default in GRINOS, (2)
setting "watchdog on" to reboot the computer in the event of a lockup, and
(3) making sure NOS never runs low enough on core, this remains a serious
problem that I do not yet know how to fix.
Fourth, my basic objection to AG9V's position is that he wants to get a
stable version going at the EXE level, while I want to do it at the source
level. Bdale has come in (as I assume you saw) and backed John, which has
to start me rethinking my position. But I am motivated a lot by having
watched compiled release after compiled release come out with no DRSI
drivers. It took me months to get hold of a decent version of NOS that
had both DRSI drivers and the "tcp timertype linear" command, and then
only because KA1JY made up a specially compiled version of G1EMM for me.
By the time I had modified G1EMM enough so that I could at least compile
it with the newer Borland compilers, PA0GRI 910531 came out and I found
it to be much better, at least from the perspective of the source code.
Fifth, I think Bdale is right in that the main requirement for a "stable
NOS" is tons of testing and validation. I do what I can, but I am not
engaged in any formal program. I try to keep a list of GRINOS users, but
it is now no longer you, me, Chas, and Don running GRINOS; we have had
people calling ChowdaNet from North Carolina (3) and London, England (1)
to download not only the EXEs for GRINOS, but also the source. And one
of the people who downloaded the source reports that his executables lock
up his machine, using exactly the same compiler, which concerns me.
My original objective was to get control of the program running in my own
machine, which was a source of endless frustration for me. Everything
else just sort of grew out of this by accident, and I now find myself at
the center of a lot of support problems. I don't mean that I mind having
users send me bug reports and legitimate problems, but the majority of
questions are things that should be handled by some kind of documentation,
which I don't have either, and requires me to go through the source code.
For example, Dave, KC1PR, has had a HAPN card for a while that he could not
use for TCP/IP because no one was able to tell him what the attach command
parameters were.
Another big problem with standardizing on the executable is that NOS'
most serious problem, memory exhaustion, will be made worse. Right now,
I can release different executables with the drivers needed for each
installation. I don't really do that, but I could. For example, if I
released a standardized exceutable without the HAPN drivers, there would
be two local users out of luck. I also don't really know what the demand
is in terms of features. When I started including HAPN support in GRINOS
for Dave's benefit, NT1L started using it on his HAPN card also. Until
then, I did not even know that anyone in New England owned a HAPN card.
Chas W1CG used to own a DRSI card like mine, but he got very frustrated
with it because, as I said, the executables kept coming out with only asy
support. He actually was sufficiently disgusted to sell the DRSI card and
buy a regular TNC. Now, I think the DRSI system is the greatest thing
since sliced bread, but it isn't much good without software.
I'm willing to concede that I even meet two of Bdale's three requirements,
as I am unmarried and reasonably skilled. But I only have free time on my
hands because the economy is terrible in New England. It's my name on the
company, so I am not in a position of having to get approval to play around
with ham radio software, but this is (I hope) temporary. I will always
have time to work on things like NOS, but not this much. I am not even in
danger of going out of business, so I suppose I am better off than people
like my friend Lynn, who was a research engineer in fiber optics with an
Ivy League master's degree -- until her employer folded. Now she is an
unemployed research engineer with an Ivy League master's degree.
I have probably been rambling on a bit here. I am not even sure that I
addressed the points you made. That's what you get for sending me mail
that I answer at 6:00 am.
-- Mike
----
From: jdco...@aplcomm.jhuapl.edu (Jack D.Colson)
Date: Mon, 22 Jul 91 08:39:26 -0400
Subject: Re: ka9q shutting down
----
From: crom...@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Mon, 22 Jul 91 10:13:25 EDT
Subject: Re: Multiple DRSI Cards, and bcc2++ gs
Rob,
You may already have the answer but I explained in an earlier
message that Gerard made a mistake in the code in 1.7e for BC2.0
compile. I am sure he will fix it in the next version but until
using Mike w's mkname.c as published here INSTEAD of Gerards will
work fine. I have compiled numerous copies and they run fine.
Gerard also acknowledged the problem late last week and I believe
he explained the problem.
Doug
----