Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

TCP-Group Digest 240791.1815

1 view

Skip to first unread message

daily posting

unread,

Jul 24, 1991, 12:15:20 PM7/24/91

From: crom...@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 23 Jul 91 09:54:03 EDT
Subject: Re: PA0GRI v1.7e temp files

Yes Mike,

Absolutely fixed. I used your mkname.c module with Gerards 1.7e
(all tmp stuff removed from pc.c - it is already) and it works fine.
I have had a version running for a week with very heavy usage.

Gerard was trying to make a work all version for all compilers and
that is where the problems started.

Doug

----
From: wd0...@wd0efl.UCSD.EDU (Brian K. Teravskis)
Date: Tue, 23 Jul 1991 07:36:34 -0500
Subject: Configurable NOS

I've seen a lot of discussion on wanting NOS to work on all hardware
platforms, and trying to keep the size down.

One idea comes to my mind is: why not have a configuration program that
sets up NOS to run on a given machine. Many CAD programs do this to
handle the large number of graphics standards out there. I would think
this would be a way to customize NOS without:

1. Having all drivers within the executable code, thus having
a lot of excess baggage.

2. Having the user go out and buy the latest version of Borland
C++ to customize the program.

I think this would be a step to make NOS a little more accessable to
those who don't want to have to get into the 'nitty gritty' of NOS
to run the code on their rather 'plain Jane' PC.

Brian

AX25 : WD0EFL @ N0DAI.MN.USA.NA
internet : wd0efl @ g1xrl.vware.mn.org

----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Mon, 22 Jul 91 13:27:16 EST
Subject: RE: Multiple DRSI Cards, and bcc2++ gs

I run DRSI here, but with only one card. The reason your card probably
does not hear anything is that your "mem nibufs" count is too low; I have
to set is about 12 instead of the default of 5. I get the same behavior
as you if I do not do this. Obviously, this assumes that you have checked
the usual problems, such as interrupt conflicts.

Gerard circulated a message about the MKNAME.C module in v1.7e being bad;
Doug said that substituting my MKNAME.C module that is dated 9 July inside
its comments works OK for v1.7e, although I have not had a chance to do
anything yet with v1.7e. If you need a copy, I'll mail it on request so
I don't have to bother tcp-group with it again. (VK5XXX is already getting
his own copy.) The QEMM exceptions are probably being caused by the stack
getting bombed by the bad temp file code, as you suspected. The way I set
up my version of MKNAME.C, by the way, you can simply remove all references
to it in MAKEFILE and then the library versions of those routines will be
used; this will work without corrupting the stack, but temp file will be
created in the current directory and will not be deleted at file close if
the current directory is different than it was at file creation.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Mon, 22 Jul 91 12:18:54 EST
Subject: PA0GRI v1.7e temp files

I see from Gerard's message that there was some confusion between _MKNAME()
and __MKNAME(). The reason for this is that the library function has been
pascal very consistently, and part of the pascal convention is that the
underbar is not automatically prepended to the symbol as it would be with
the cdecl convention.

Before Borland C++ 2.0, which calls __MKNAME() from both tmpnam() and from
fclose(), it was possible to replace only the tmpnam() function and not have
to use the pascal convention for __MKNAME(). Since it was intended to
replace (or at least hide) the library function, the source code referenced
a cdecl _MKNAME(), which was translated to __MKNAME() by the cdecl convention
and given linker preference over the (pascal) library function.

This does not work anymore under Borland C++, which Gerard does not have.
Since fclose() is not replaced by anyone's fix, the __MKNAME() function must
be called with exactly the same stack set up and convention as the library
version of __MKNAME(). This means that __MKNAME() must be near pascal, and
that implies that it must be in the same code segment as fclose(). All of
this together is what makes my fix fairly convoluted, but it really does
work when implemented this way.

By the way, messing this up even slightly will probably bomb the stack and
result in machine lock ups, which Doug had been reporting. I wonder if this
is now fixed for him?

-
- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

(It's been over 95F every day here for more than a week! It's a good thing
my computer has a fan in it...)

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Mon, 22 Jul 91 13:14:54 EST
Subject: RE: Compiling problems with TC++ v1.0 and NOS

Brian, I tried sending you a lot of message about your problem with the
error messages about type mismatches when compiling NOS under TC++, but
your mail bounced. I would presume that lots of other people had similar
experiences with you, and therefore you might attribute the deafening
silence you have been getting in response to your questions to this much
more innocent fact.

Anyway, I had a lot of problems with G1EMM NOS under TC++, and I very much
sympathize with you. But the order of include statements is important.
If include statements are nested, which they are in NOS to a limited extent,
then processing the include statments in a different order will actually
generate different code. Serious and subtle problems can creep in when you
do this stuff. For example, if you have two statements of the form
"extern int something;" and "int something;", the linker is going to treat
them differently depending on the order in which they occur. This is
documented, by the way -- partly because you can change the compiler's
interpretation of "int something;" at the external level when the "extern"
keyword is not used. (Isn't C fun?)

The real cause of your error messages is that something is going haywire
in the function prototyping. For example, ANSIPROTO may be set wrong,
and __ARGS(x) may not be defined as it should be. But you have to hunt
this down. You can't just shoot craps with the include statements.

For what it's worth, PA0GRI NOS has been compiling reasonably nicely under
Borland C++ 2.0 as of version 1.7d, with my modifications to the temporary
file stuff. You don't need my temp file mods for Turbo C++ 1.01, only for
Borland C++ 2.0.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: Wood <TKW...@gordon-emh1.army.mil>
Date: Tue, 23 Jul 91 16:13:35 EDT
Subject: KPC-4 & NOS - Making Use of Both Ports For Gatewaying

TCP/IPers:

A note in the DUAL-PORT KPC-4 documentation says that an extra byte or bytes
can be used to identify to/from transmissions on either PORT1 or PORT2. (I
think it is a similar concept to the DRSI/N6TTO drivers mentioned in NOS
documentation.) The Kantronics documentations states that the (then) current
version of TCP/IP does not support this extra byte feature but that future
version may support it. Has this dual port feature been implemented in NOS or
should I go with BPQ code?

If this extra byte feature is implemented it seems like a good opportunity to
run a dual port 1200/2400 gateway from a single I/O port. My 386 at home has
just about run out of interrupts for extra serial cards (WEFAX card, modem,
mouse, TNC, etc.)

.
Tracy Wood
KD0UP

-----------------------------------------------------------------------------
MAIL: ELECTRONIC:
US Army Signal Center DDN : woo...@gordon-emh1.army.mil
Directorate of Combat Developments AUTOVON : 780-3782
Concepts & Studies Division COMM : (404) 791-3782
ATTN: ATZH-CDC (Studies:Tracy Wood) FAX: (404) 796-7977
Fort Gordon GA 30905-5090
------------------------------------------------------------------------------

----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Tue, 23 Jul 91 10:02:06 EST
Subject: Re: More on stabilizing NOS

John AG9V and I appear to be moving toward the same central position now.
I think he is right in that there should be a standard EXE, provided that
it is not stripped down in the name of reliability. In other words, the
standard EXE should have a list of features that are available, whether
a particular user wants them or not. Such features would include very
basic things, like the ability to act as SMTP and FTP client and server,
and also more advanced things, like POP and HOPCHECK. I also think that
expendable, memory-hungry features like the telnet/AX.25 mailbox ought to
be retained, although I would be open to argument on that.

I also agree with John's proposal, which I had in mind when writing my
earlier posting, that device support be made external to NOS, on the model
of the Clarkson Packet driver. This would substantially reduce code size
for any given user, would make porting and driver upgrading easier, and
would also solve a lot of annoying problems of NOS (such as how to run two
DRSI or SCC cards at the same time).

It seems to me that NOS is presently structured into three major components:
(1) the core, which includes the multitasking kernel and the memory allocator,
(2) the hardware drivers, and (3) the features and functionality, which
includes the clients and servers. A lot of the most difficult problems of
working with NOS relate to the interface between the hardware drivers and
the core, since both of these can become involved in asynchronous ("volatile")
actions and can be tough to debug. Clients and servers, generally, do not
act asynchronously, and are comparatively easy to work with.

Anyone who wants to dispute this is encouraged to first look through the code
and try to do a desk check on, say, COMMAND.ASM and SMTPSERV.C. In the first,
you will be scratching your head thinking, "Let's see. We're in an interrupt
service routine that reenables interrupts, so we could be processing in a
recursive call, so we can't touch this object in memory. Now we'll trick
DOS into using its critical error handling stack so that we can force DOS
to think that our PSP is current, which has the effect of doing a context
switch, but we'll have to preserve the old PSP in a reentrant way..." On
the other hand, the second module has logic in it like "He sent 'MAIL FROM'
so I guess I send "250 Ok."

So here's my position on stabilizing NOS:

1. Enhance its modularity. Make the hardware support external, so that NOS
must support only a public interface (in the object-oriented sense), like
the Clarkson Packet driver. We could even go further and let NOS do its
own dynamic loading of device support from disk, like MS Windows. This
way, we don't create a support nightmare for users, who wold still only
have to worry about what is in their AUTOEXEC.NET files. It would cause
problems if this device support were provided only through drivers that
had to be loaded in CONFIG.SYS at boot time.

2. With hardware support out of the way, the NOS core should be extensively
cleaned up. We should try to rely much less on operating system tricks
and the internals of the stack. Obviously, MS-DOS has its limits, but
I don't believe we are near them. In particular, I think it would be a
reasonable objective to make NOS overlay compatible, so that the major
features of NOS (clients and servers) could remain outside of core for
most of the time. This is not a small job.

3. At this point, when universal device support and memory exhaustion are
looked at as solved problems, I would see no reason to oppose making and
distributing a standardized executable. Most of the proliferation of
executables is a result of demand for different features, hardware
support, or memory limitations, so a clean, small, overlaid NOS, with
universal hardware support and all possible features, would eliminate
the motivation for having a lot of different versions.

4. We should not lose sight of the fact that TCP/IP is genuinely more
complicated than most amateur pursuits. Users now have enough trouble
building routing tables and so forth, which are not something that that
NOS makes difficult. Therefore, we should try to be very careful about
making NOS user friendly, or at least not downright user hostile. In
particular, good documentation is needed -- something very long and very
thorough, on the order of what AMSAT and ARRL publish. And it is clear
that good documentation would be easier with a standardized executable.

Well, John, what do you think? I'll await your reply, assuming that Phil or
someone paid by him does not stop in Rhode Island on the way from New Jersey
to California (it's kind of on the way) to bludgeon my computer with a
sledgehammer, in which case I won't await your reply.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: crom...@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Tue, 23 Jul 91 16:42:36 EDT
Subject: "MORE" problem

Ever since I can remember with both G1EMM and now PA0GRI NOS the "MORE" wait prompt seems to get corupted after the
code has been in use for awhile. I notice this at my switch station in Phila. It is most useful to have the screen
wait on this system as I am using a remote DOS port that I cannot use flow control on. After the system has been
running for awhile it no longer displays the "more" prompt nor waits in long listings of route, arp, ax heard etc.
Anyone have any ideas on where or why this is happenning?

Doug

----
From: an...@aspen.cray.com (Andy Warner)
Date: Tue, 23 Jul 91 17:33:11 CDT
Subject: RE: Compiling problems with TC++ v1.0 and NOS

Mike Bilow, N1BEE, writes...

> Brian, I tried sending you a lot of message about your problem with the
> error messages about type mismatches when compiling NOS under TC++, but
> your mail bounced. I would presume that lots of other people had similar
> experiences with you, and therefore you might attribute the deafening
> silence you have been getting in response to your questions to this much
> more innocent fact.
>
> [...]

Hmm, as the guy whose machine Brian's mail goes through, I'd like to hear
about the mail bounces. The machine that holds the MX record for mn.org
has had it's ups and downs recently, so if they were something along the
lines of "Unable to contact mailhost jhereg.osa.com - blah, blah, blah"
then that was the problem (and it should now be fixed). Other problems
(ie ones _I_ can fix) I'd like to hear about.

Thanks.
--
andyw. (W0/G1XRL)

an...@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: br...@ucsd.Edu (Brian Kantor)
Date: 24 Jul 91 05:26:17 GMT
Subject: Re: More on stabilizing NOS

I think that if you decide to produce a standardized version of NOS, you
ought to find some other name for it so that people won't confuse it
with the continually-changing real NOS where advances are being made,
which will, of course, be incompatable at the source code level.

Seems to me like trying to swim in ice. If that's your bag....
- Brian

----
From: rutgers!kb2ear!kb2...@UCSD.EDU
Date: Tue, 23 Jul 91 22:41:04 EDT
Subject: AX.25 Forwarding Problem

I am tring to forward mail to an MSYS BBS via the mbox forwarding and
have found that if there is more than one message in any given file the
when it tries to send the second message it sends:

SP Title. @ W2EMU < KB2EAR

It seems to send the last thing it got from the BBS.

Any one know why?

BTW nos version is v910618 (PA0GRI v1.7a)

Tnx,
--
Scott R. Weis KB2EAR
Internet: kb2...@kb2ear.ampr.org
Packet: KB2EAR @ NN2Z.NJ.USA.NA
Snail Mail: 10 Palmer Rd., Kendall Park NJ, 08824-1228
Phone: +1 908 297 0469

----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mik...@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Wed, 24 Jul 91 02:27:41 EST
Subject: NOS, Multitasking, and Overlays

I have been making quite a lot of noise lately about the idea of using code
overlays in NOS to ease the memory crunch. After some investigating and
playing around, I am at an impasse.

NOS has a multitaksing kernel which depends upon having complete control
of the stack. An overlay manager does not necessarily have to modify the
stack in a way incompatible with the multitasker, but Borland's VROOMM
does so. In particular, the VROOMM system implements overlaid modules in
such a way that there is a local stack within the overlay buffer, and a
prologue and epilogue are added to the code for an overlaid module such
that a stack switch is done when execution enters the overlaid module and
restored on exit.

All that is really required for an overlay manager is that a small "stub"
routine is maintained at the address to which control transfers on calling
an overlaid function, and this stub remains in memory at all times. These
stubs together form a kind of dispatch table, from which control is simply
transferred if the target overlay is loaded, or which runs some management
code that loads the overlay and then transfers control into it. It is
possible to do this without giving the overlaid module its own stack, and
it is even possible to do this without giving the overlay manager its own
stack. But not with the Borland-supplied VROOMM system, as far as I know.

There are commercial products around that can do this kind of overlay
management, such as PLink, but that is not a good way to go with NOS. What
I would like to know is:

1. Has anyone come up with some way of getting VROOMM to allow multitasking?
I can't really see how to do it, nor can Borland. But that does not prove
that it can't be done.

2. Is there a public-domain overlay management system in existence? There
are a number of public-domain multitaskers, such as CTASK, but I have not
seen a PD linker or overlay manager.

3. Does anyone have any better ideas?

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mik...@idsvax.ids.com (Internet)

----
From: kdre...@gdlvm2.vnet.ibm.com
Date: Wed, 24 Jul 91 09:24:28 EDT
Subject: NOS Stability

I like Mike's idea of runtime drivers for NOS. What about a configuration
file arrangement where clients and servers support could be requested as
well as drivers, etc. Maybe some sort of "mini" linker to create the
run time file from a list of available options? I know this is a LOT
of work, but with the combined energy that is evident here it should
be doable?

KK4L

----
From: "k1io@fn42jk 24-Jul-1991 0910" <gold...@carafe.enet.dec.com>
Date: Wed, 24 Jul 91 06:23:12 PDT
Subject: Re: More on stabilizing NOS

Well, I'll throw my vote in again... I think I raised this point at
a New England TCPers meeting a few months ago and the consensus was
that some people in this group (no names, Phil) would be violently
opposed to a "stable release" of NOS. But hey, since somebody raised
the point anyway...

Most hams do not write C code. Most hams don't have Borland C++ or
for that matter an old version of Turbo. If that's the entry price
for TCP, then we may as well go home and let AX.25 or, heaven help
us, Net-Scam rule the bands. What the heck -- the "new ARRL bandplan"
for 220 gives packet all of 120 kHz, in one spot, so obviously they
won't want experimentation on our bands anyway! :-(

If we are to see TCP grow to become a reasonable alternative to those
inferior technologies, we have to make it accessible. Period. Not
sources-only-and-you've-got-to-be-a-guru. Not "or beg your local
guru to compile it for you." It needs to be a plug-and-play package.
Like the old NET was getting to be.

Since we no longer have a single "keeper of the bits", I'd implore
at least one or two of the Guys With Compilers to do a little "release
engineering". Take the features and create an .exe, document what's
in it ("release notes" to go with the evolving bigger doc), and let
people play with it for a while. The patch bugs, retest and release.
In the meantime the group continues to work on future versions. The
release is in effect a stabilized snapshot for the masses.

Fifteen years ago I worked for a startup computer company whose PC,
far and away the most advanced of its day, was two months from release.
A year later, when I left, it was still two months from release, and
the company went Chapter 11 two months later. Some kind of release is
necessary!

Now my vote for the "to the masses" version would be to include the
core features, RSPF, POP, and async (KISS, SLIP) + packet driver support.
The AX.25 mailbox and Telnet pads are nice but not for end users so much
as for BBS-like servers, and I'd leave them out in the interest of
memory conservation (MS-DOS eats it!). But that's just a first pass.
What fits and runs in a stable manner with about 500k memory use or less
is a good start. Maybe a couple of released versions (small and large,
end user and server, or whatever) would be useful.
fred k1io

----
From: "John R. Ackermann" <j...@lawday.daytonoh.ncr.com>
Date: Wed, 24 Jul 91 8:10:14 EDT
Subject: Re: More on stabilizing NOS

[Regarding Mike's proposal to leave the ax25/mailbox intact]

I think the mailbox is a useful function, but is probably one of the
most glaring areas where we need to do real work on the documentation,
and where reliability is a critical factor (since interaction between
the mailbox and AX25 services like BBSs is going to open us up to much
criticism if things allegedly cause problems at the AX.25 end).

John

----

0 new messages