[nos-bbs] Questions related to JNOS 1.11f

[Barry Siegfried]

["Miroslav Skoric (YT7MPB)" <skoric at uns.ns.ac.yu> wrote]:

> Barry Siegfried wrote:
>
> > The reason that there is no such "manual" is because there are
> > limitless possibilities for "specific NOS usage".  Everyone has
> > different needs and therefore uses NOS in a different manner, which
> > means that everyone's CONFIG.H file must be specific in order to
> > provide what they require.
>
> Barry, you are right generally speaking.  But I am sure that all those
> "different needs" may be grouped into 5-6 main groups (mailbox on plain
> packet, mailbox for both packet and TCPIP, gateway/router, only router
> etc).

While there may be 6 or so "main groups" the problem is with the fine
details of what else you want the program to do.

> Of course, we all mostly dislike to document what we are doing while
> trying to setup and configure our own experimenting systems.  If
> opposite - a lot of experience would be documented and posted in a
> form of manual or something.

Some feel that writing good "end user" documentation is a very difficult
thing to do.  I am one of those people.  In fact, I think that actual
coding is easier than writing end user documentation.  What I do is
write technical "release" notes, which is something I somewhat picked
up from WG7J when he was still the chief JNOS programmer in the early
to mid 1990s.  While these notes are nowhere near what good documentation
would be for the end user, they are at least something.

About 10 years ago, a very enthusiastic and good friend of mine offered
to try and write user documentation for my NOS.  He lasted only about
a month when he realized the job was just too large, too complicated
and that he would never be able to finish.  The effort that Skip has
taken on is true yeoman's work because he has taken on the task of
documenting a program that vertically integrates so many functions
it can appear frightenly daunting.

> I myself keep maintaining a FBB howto document that I am sure is far
> from perfect but many told me that even then it helped to start with
> the software.

That is a very good thing that you do with FBB, Misko and no doubt,
the people who are the lucky recipients of your efforts are very
appreciative.  Fortunately, FBB does one thing and one thing only
really well so it makes it a bit easier to do it for FBB than it
is for NOS.

> > I have more than 20 different CONFIG.H files in the source code
> > directories here which hold them, and whenever I have to compile
> > a new or changed program I run a batch procedure that automatically
> > compiles all of them.  Then I have to distribute them after they
> > are compiled which is the fun part...
>
> That's great but if you (or somebody close to you) is able to document
> the features and/or installation procedure of what you have in your
> repositories, that might help the others and save you some time of
> answering to reinventing-the-wheels-type of questions.  :-)

It *might*, but my CONFIG.H looks a lot different from the JNOS
CONFIG.H.  It evolved in a somewhat different direction.

> > That is because SMTP has the distinction of being a service for
> > which the client and server are so dependent upon each other that
> > you literally cannot have one without the other.  And many of the
> > mail receive handling routines that are used in the mailbox use
> > subroutine mechanics that are common to the SMTP server as well.
> > So if you #undef SMTP mail handling then you will #undef mailbox
> > mail handling as well.
>
> Yes I know that now but I have learned that a hard way.  Once again,
> if I could find a manual having a warning on those details you discuss,
> it would be much easier to start.

Unfortunately, that is only one "detail" out of several thousand which
would need to be discussed in this manner.

> > I have my own CONFIG.H setup "reverse" from that kind of logic,
> > however to make it as difficult as possible to disable anything
> > you actually need for your configuration.  For instance, even if
> > you #undef the SMTP client or server, if you #define one of them
> > then the other is forcibly #defined and if you #define mailbox
> > mail handling then both the SMTP client and server are both forcibly
> > #defined as well.  This way you aren't left with a program that
> > won't do what you really want or need it to do.
>
> Do you think... they are "forcibly #defined" during the compilation
> process - regardless what is #defined (or not) within config.h ?
> Sounds interesting if during the compilation there is a 'watchdog'
> in a compiler - looking for what you might have set up as a wrong
> parameter (say, some mutually exclusive program options).

My NOS is so extremely heavily #ifdefed that if CONFIG.H isn't set up
"properly", about the only "watchdog" there is in the compiler is that
there will will be a missing subfunction at link time which will create
a linking error.

To provide "forcible #defining" mechanics you need to make an addition
to your CONFIG.H so that, if the code for "B" is dependent upon the code
for "A", then you put something of this nature further down in the
CONFIG.H file:

#ifdef B
#define A
#endif

This way, even if you "#undef A" above in the file, when the compiler
gets to these lines it will forcibly #define "A" to provide the
necessary support for "B".  I know that there already must be some of
this in the JNOS CONFIG.H because I got the original idea to do this
from JNOS circa 1993.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+