Thread View: dnet.ham
1 messages
1 total messages
Started by daily posting
Tue, 09 Jul 1991 16:15
TCP-Group Digest 090791.1815
Author: daily posting
Date: Tue, 09 Jul 1991 16:15
Date: Tue, 09 Jul 1991 16:15
836 lines
34479 bytes
34479 bytes
From: "Chris Cox W0/G4JEC" <g4jec@g4jec.ampr.org>
Date: Mon, 8 Jul 1991 19:55:45 -0500
Subject: Automatic local network problem with 0618
I have found a bug which I haven't seen anyone else mention yet. Any
automatic route created by way of a netmask doesn't work. For some reason it
sets the subnet address to be identical to the interface's address, with the
correct number of significant bits, however, it is unusable. You need to add
a manual entry for the local network subnet address. This wasn't the case in
the 1130 release. I suspect the problem is in iproute.c, which has been
changed quite a bit to include hashing of the routing table.
e.g. Configure an interface with a subnet mask of 0xfffffc00 & IP address of
147.202.4.1
Produces an automatic routing table entry of:-
Dest Len Interface Gateway Metric P Timer Use
147.202.4.1 22 ec0 0 0 0
This subnet cannot be sent to. Doing so, for example with a ping 147.202.4.3,
produces no transmission, and ipOutNoRoutes gets incremented. To use that
local subnet, a manual "route add 147.202.4/22 ec0" needs to be executed.
If you remember to work around this little problem, it seems to work OK...
Has anyone already found the cause of this problem? If so, please let the
group know - I don't want to unnecessarily reinvent the wheel :-) :-)
ttfn
Chris Cox W0/G4JEC
chrisc@moron.vware.mn.org g4jec@g4jec.ampr.org g4jec@g4jec.vware.mn.org
11th Hour Contest Group (North American Chapter) Minneapolis, MN EN34ju
----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Mon, 8 Jul 91 15:39:16 EDT
Subject: NOS? Points....
Just so nobody gets confused (who would do that!) the sequence for
making the F3 key back into a last command recall is:
fkey 61 ^b - note the ^b is the up arrow (above 6) and not control
This does map control b to whatever key number precedes it. It does not
have to be F3. You could just use the control B sequence on the keyboard.
Has anyone had problems with the AX routing 'feature' of NOS. It logs
auto routes based on the route that an ax25 user comes in. The problem
is that this route stays forever. If a user accidently uses a digi in
then NOS logs this and forever attempts connects via this route, wether
or not it is correct. This feature should have some lifetime or at least
be smart enough to know that if someone comes in direct to go back direct.
Doug
----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Mon, 8 Jul 91 10:53:00 HST
Subject: Re: Some questions from the weekends romp thru Switzerland, Hawaii, etc.
> I have some general questions arising out of the linking going on last
> weekend.
stuff deleted.
>
> - NET/ROM over axip links. Well I have confirmed it works. I played around
> with defining an axip session over the house ethernet and the node broadcasts
> were updating the tables at both ends as per normal. The links seem to be
> ok and I was able to generate NET/ROM sessions both ways.
>
> Anybody else want to try it as well? minnie.vk1xwt and bbs.vk1xwt will
> both be running netrom on all axip interfaces during the next link (probably
> next weekend) so plug in your routes and give it a try! :-)
>
We can give it a try from here.
>
> - PA0GRI NOS0618 BBS functions.
> Another thing I noticed was that normal AX25 users logged into the
> MBOX seemed to get the privleges assigned to "anonymous" in the /ftpusers
> file. Also it seemed that as a normal user you could change your "area"
> to anyone elses. ie log in as vk1zdj and change your area with "a vk1kcm"
> and read messages for vk1kcm.
I believe this works only if you've got 'sysop' priviledges. The
normal users at this end can't do that (at least I haven't been able
to figure out how :-) ).
>
> When does the "read Y/N" part of a message get updated? I noticed that
> there is no record of users reading a message. When they log out and then
> log back in, all the message they had previously read were marked "unread"
> again. :-( Is there a way around this? It would be nice as I'm looking
> at using NOS to replace MSYS as my BBS software.
Again, only if you're a 'sysop'. For the 'normal' user, the 'read'
flag is recorded into the message so that things work properly. I
believe the reason for this is that the sysops can maintain the public
message areas without flagging all the messages as read. The normal
users can then read through the message area normally. Perhaps Anders
can comment on this more thoroughly?
----
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Date: Mon, 08 Jul 91 08:58 CDT
Subject: Re: Why is the ampr.org namespace flat?
Ed Vielmetti writes:
> Well, there's another complication. By changing your IP address, you
> need to propogate name server information out and around the world
> that lets people who know you by your name find out what address you
> are currently at.
> Host name to address mappings are usually relatively long-lived, on
> the order of months to years. If people are trying to find you, you
> run the risk of them caching the old address, using that, and finding
> no one there. If you're moving around a lot, keeping that
> name-to-address mapping up to date is going to be hard.
Performance Systems, Inc. has faced this same problem with their dialup
Internet service. Each time you connect to their network, you're assigned
a random IP address from their pool. They automagically update their
name servers with your address for the duration of that connection.
The catch? This is only suitable for outgoing Internet use; you can't
telnet or FTP to a host whose only connection is through that service.
You can get Internet mail, but it's a POP-based system.
I don't know if the model could be extended to the amateur model, but this
seems like a reasonable start.
...Jay, K5ZC
----
From: sidney@borland.com (Sidney Markowitz)
Date: Mon, 8 Jul 1991 09:10:11 PDT
Subject: Re: tmpname(), __MKNAME()
+-- On Jul 4, 7:23am, R.E. Janssen (PE1CHL) wrote:
> I think a better idea would be for someone who has good relations with
> Borland to try to convince them that the temporary file handling needs
> a fix, and that we already have the fix available.
I see it's time to introduce myself... I'm in Languages R&D at
Borland, and I'm trying out NOS ka9q to provide routing through our
SLIP connection to the Internet. Eventually I would like to get
Internet mail integrated with our internal LAN-based e-mail and have
some sort of PC-based news reading and posting. (By the way, any
suggestions on how to do this on a Novell network would be
appreciated).
Anyway, I'm not familiar with the details of the problem engendered by
the change in the RTL between TC++ 1.01 and BC++ 2.0, but if some one
person could put together a message that explains it clearly and the
suggested solution and e-mail it to bugs@borland.com, it will be
looked at by the right people.
-- sidney markowitz <sidney@borland.com>
----
From: "John R. Ackermann" <jra@lawday.daytonoh.ncr.com>
Date: Mon, 8 Jul 91 13:45:58 EDT
Subject: Stabilizing NOS?
A modest proposal:
The work being done by the NOS developers is nifty, but I think we're
overlooking something important by not coming out with an updated
"standard" NOS to be distributed to the wider community.
Maybe we should consider breaking NOS into two versions...
First, create a client-oriented version that doesn't include all
the fancy protocols, but is stable, well documented, and will fit
into memory.
Second, continue development of a server/router oriented NOS that
adds the additional goodies (maybe some of the client functions could be
deleted from it to help with the memory problems?).
I lack the time and talent to do the programming, but I'll volunteer
to do documentation cleanup, packaging, and distribution if we can debug
a base version and come up with rough docs.
John Ackermann AG9V
jra@lawday.daytonoh.ncr.com
----
From: Andrew Heybey <ath@ALLSPICE.LCS.MIT.EDU>
Date: Mon, 08 Jul 91 10:33:41 -0400
Subject: Executable NOS with NTP available
I've compiled a version of NOS including NTP. I used the
configuration that was in the config.h that came with the 910614
version of NOS, except that I turned NNTP off because I ran out of
space in the data segment. This is probably my fault (I use 8k of
lookup tables in addition to all the globals used by xntp), but I have
neither the time nor the inclination to try to whittle down the usage
of initialized data right now.
The binary and my (extremely sketchy, uh, concise) README on how to
set up ntp under NOS are available for anonymous FTP from
allspice.lcs.mit.edu:pub/ath/nosntp.bin.tar.Z
I have compiled in the packet driver interface to NOS, so this
executable will work with any network board for which there exists a
packet driver.
Questions, bug reports, etc. about the implementation of
NTP under NOS are welcome. Questions about how to get NOS running
with your particular PC and network board are not.
andrew
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Fri, 5 Jul 91 10:14:01 EST
Subject: Filtering junk from ax25 heard lists
Unattended switches which are left running for days and even weeks often
get very short of memory. That the seemingly harmless "ax25 heard" lists
were responsible was originally suggested by Rich Serafin, K3UU, although
he was looking for a memory leak. My guess is that what happens is that
a junk callsign gets through every so often, and is then permanently
listed on the heard calls data structure. A call that is heard once uses
the same amount of memory as a call that is heard 10000 times. The main
New England switch, wb6nil.ampr.org, is a good example: if the (J)heard
command is issued within a telnet session, pages and pages of calls will
come back, of which easily 95% are junk, and most of the junk has lower
case or extended (graphic) characters in it.
A simple fix for this intercepts the logging functions, refusing to list
callsigns that cannot be callsigns. I have also taken this one step
further, and have put in a command to let the user completely disable the
ax25 heard functions. I would be interested in comments on this.
While most of the local users in New England have been very supportive,
saying that they consider the ax25 heard lists to be of little use in
most cases and of no use at an unattended switch, I am reluctant to take
the code out completely, as there are obvious stub routines which are
planned to use the ax25 heard data for routing metrics. I have therefore
written this code so that it filter junk calls, but defaults to logging
real calls as before.
These diffs show the changes needed to implement the N1BEE ax25 filter.
All listings below are based on PA0GRI NOS_0618v1.7a, which uses KA9Q
NOS 910618 as a base and is dated as modified by PA0GRI on 910625.
This code makes the following functional changes to NOS:
1. If the symbol AXHEARD_FILTER is defined during compilation, code
will be included in the logsrc() and logdest() functions which
prevents logging of callsigns unless they are made up entirely of
characters which are valid for a callsign. Valid characters for
an AX.25 callsign are upper case letters, digits, and the space.
2. A new command, "ax25 filter <0|1|2|3>", is created in the AX25CMD.C
module. This takes a bit-mask argument that selectively enables or
disables logging of source or destination callsigns heard. This
has no effect unless AXHEARD_FILTER was defined for compilation.
In any case, logging defaults to all logging enabled, for reasons
of compatibility with prior NOS versions.
3. Another new command, "ax25 hearddest", is created so that the list
of destination callsigns heard can be displayed. The code for this
already existed in NOS, but there was no command to access it.
-- Mike Bilow, n1bee@n1bee.ampr.org [44.104.0.20]
N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mikebw@idsvax.ids.com (Internet)
Comparing files AX25.H (original) and AX25.H (modified)
***** AX25.H (original)
180: #define NAX25 10
181:
182: /* In ax25.c: */
***** AX25.H (modified)
180: #define NAX25 10
181:
182: /* These are bit masks for axheard filtering -- N1BEE */
183: #define AXHEARD_PASS 0 /* log both src and dest callsigns */
184: #define AXHEARD_NOSRC 1 /* do not log dest callsigns */
185: #define AXHEARD_NODEST 2 /* do not log src callsigns */
186: #define AXHEARD_STOP 3 /* do not log any callsigns */
187:
188: /* In ax25.c: */
*****
Comparing files AX25CMD.C (original) and AX25CMD.C (modified)
***** AX25CMD.C (original)
12: ** string using UI frames.
13: */
***** AX25CMD.C (modified)
12: ** string using UI frames.
13: **
14: ** 91/06/27 Mike Bilow, N1BEE
15: ** Added FILTER command for ax heard control
16: **
17: */
*****
***** AX25CMD.C (original)
34: static void axflush __ARGS((struct iface *ifp));
35: static int doaxflush __ARGS((int argc,char *argv[],void *p));
***** AX25CMD.C (modified)
38: static void axflush __ARGS((struct iface *ifp));
39: static int doaxfilter __ARGS((int argc,char *argv[],void *p));/*N1BEE*/
40: static int doaxflush __ARGS((int argc,char *argv[],void *p));
*****
***** AX25CMD.C (original)
92: };
93:
94: static struct cmds Axcmds[] = {
***** AX25CMD.C (modified)
97: };
98:
99: extern int axheard_filter_flag; /* defined in axheard.c -- N1BEE */
100:
101: static struct cmds Axcmds[] = {
*****
***** AX25CMD.C (original)
99: "digipeat", dodigipeat, 0, 0, NULLCHAR,
100: "flush", doaxflush, 0, 0, NULLCHAR,
***** AX25CMD.C (modified)
106: "digipeat", dodigipeat, 0, 0, NULLCHAR,
107: "filter", doaxfilter, 0, 0, NULLCHAR, /* N1BEE */
108: "flush", doaxflush, 0, 0, NULLCHAR,
*****
***** AX25CMD.C (original)
101: "heard", doaxheard, 0, 0, NULLCHAR,
102: "irtt", doaxirtt, 0, 0, NULLCHAR,
***** AX25CMD.C (modified)
109: "heard", doaxheard, 0, 0, NULLCHAR,
110: "hearddest", doaxdest, 0, 0, NULLCHAR, /* N1BEE */
111: "irtt", doaxirtt, 0, 0, NULLCHAR,
*****
***** AX25CMD.C (original)
390: }
391: static int
***** AX25CMD.C (modified)
399: }
401: /* This function below is all new by N1BEE 910627 */
402: static int
403: doaxfilter(int argc,char *argv[],void *p) {
404:
405: if(argc >= 2) {
406: setint(&axheard_filter_flag,"ax25 heard filter",argc,argv);
407: } else {
408: tprintf("Usage: ax25 filter <0|1|2|3>\n");
409: }
410:
411: tprintf("Calls heard logging by source ");
412:
413: if(axheard_filter_flag & AXHEARD_NOSRC)
414: tprintf("disabled, ");
415: else
416: tprintf("enabled, ");
417:
418: tprintf("by destination ");
419:
420: if(axheard_filter_flag & AXHEARD_NODEST)
421: tprintf("disabled\n");
422: else
423: tprintf("enabled\n");
424:
425: return(axheard_filter_flag);
426: }
427:
428: static int
*****
Comparing files AXHEARD.C (original) and AXHEARD.C (modified)
***** AXHEARD.C (original)
5: */
6: #include "global.h"
***** AXHEARD.C (modified)
5: */
6: #include <ctype.h> /* N1BEE */
7: #include "global.h"
*****
***** AXHEARD.C (original)
11: #include "timer.h"
12:
13: static struct lq *al_create __ARGS((struct iface *ifp,char *addr));
***** AXHEARD.C (modified)
12: #include "timer.h"
13:
14: /* This block sets up junk filtering from ax25 callsigns -- N1BEE */
15: #define iscallsign(c) ((isupper(c)) || (isdigit(c)) || (c=='\x20'))
16: #define AXHEARD_FILTER /* include code for axheard list filtering */
17: #define AXHEARD_TRACE 8 /* undocumented debugging tool */
18: int axheard_filter_flag = AXHEARD_PASS; /* default */
19: #define AXACHKLEN (AXALEN-1) /* we do not check the SSID byte, since
20: all possible values are legal */
21:
22: /* When AXHEARD_FILTER is defined, (1) callsigns are not logged
23: unless they are made up entirely of valid AX.25 callsign
24: characters, and (2) logging of source, destination, or both
25: may be disabled for valid callsigns also. -- N1BEE 910627
26: */
27:
28: static struct lq *al_create __ARGS((struct iface *ifp,char *addr));
*****
***** AXHEARD.C (original)
123: if((lp = al_lookup(ifp,addr,1)) == NULLLQ)
124: if((lp = al_create(ifp,addr)) == NULLLQ)
***** AXHEARD.C (modified)
138: #ifdef AXHEARD_FILTER
139:
140: if (axheard_filter_flag & AXHEARD_NOSRC)
141: return;
142:
143: {
144: register unsigned char c;
145: register int i = 0;
146: while(i < AXACHKLEN) {
147: c = *(addr+i);
148: c >>= 1;
149: if(axheard_filter_flag & AXHEARD_TRACE)
150: printf(" %02X=%c",c,c);
151: if(!iscallsign(c)) {
152: return;
153: }
154: i++;
155: }
156: }
157: #endif
158:
159: if((lp = al_lookup(ifp,addr,1)) == NULLLQ)
160: if((lp = al_create(ifp,addr)) == NULLLQ)
*****
***** AXHEARD.C (original)
135: register struct ld *lp;
136:
137: if((lp = ad_lookup(ifp,addr,1)) == NULLLD)
***** AXHEARD.C (modified)
171: register struct ld *lp;
172:
173: #ifdef AXHEARD_FILTER
174:
175: if (axheard_filter_flag & AXHEARD_NODEST)
176: return;
177:
178: {
179: register unsigned char c;
180: register int i = 0;
181: while(i < AXACHKLEN) {
182: c = *(addr+i);
183: c >>= 1;
184: if(axheard_filter_flag & AXHEARD_TRACE)
185: printf(" %02X=%c",c,c);
186: if (!iscallsign(c)) {
187: return;
188: }
189: i++;
190: }
191: }
192: #endif
193:
194: if((lp = ad_lookup(ifp,addr,1)) == NULLLD)
*****
***** EOF
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Fri, 5 Jul 91 09:59:04 EST
Subject: DGROUP overflow in PA0GRI NOS
Here's one for the Believe It ot Not people...
Compiling PA0GRI NOS with a lot of CONFIG.H options enabled, I received a
linker error message that I knew perfectly well existed, but which I never
actually expected to see: "Error: Group DGROUP exceeds 64K!" This means
that some initialized and uninitialized data have to be tossed out of the
near data segment. There are a few possible solutions.
1. Change to compiling in "huge" model. This produces very slow code.
2. Redefine some of the group names using the "-z" compiler switch. This
may introduce subtle bugs when library routines do not know what to do.
Also, this is not properly selective about what stays in the near data
segment and what gets expelled.
3. Iteratively determine a new automatic far data threshold and authorize
the compiler to use it. SInce NOS is ordinarily compiled in large
model anyway, there should be no detectable speed penalty.
Using the Borland C++ 2.0 compiler, I chose the last option. After trying
a threshold of 1023 bytes without success, I dropped to 255 bytes and was
able to recover enough space in DGROUP to link successfully. This requires
adding the switch "-Ff=255" to CFLAGS in the MAKEFILE and recompiling all
modules. (Use the "-B" switch when invoking MAKE for the first time after
modifying the MAKEFILE.)
Here is what DGROUP looked like when I was done:
59E50H 6829BH 0E44CH _DATA DATA
6829CH 6829DH 00002H _CVTSEG DATA
6829EH 682A3H 00006H _SCNSEG DATA
682A4H 682A4H 00000H _CONST CONST
682A4H 682BBH 00018H _INIT_ INITDATA
682BCH 682BCH 00000H _INITEND_ INITDATA
682BCH 682BCH 00000H _EXIT_ EXITDATA
682BCH 682BCH 00000H _EXITEND_ EXITDATA
682BCH 69C81H 019C6H _BSS BSS
69C82H 69C82H 00000H _BSSEND BSSEND
Here is what got kicked out of DGROUP that would otherwise have been in it:
59A30H 59A30H 00000H _FARDATA FAR_DATA
59A30H 59B30H 00101H TTYDRIV5_FAR FAR_DATA
59B40H 59B40H 00000H IPROUTE5_FAR FAR_DATA
59B40H 59D3FH 00200H AX255_FAR FAR_DATA
59D40H 59E47H 00108H DRSI5_FAR FAR_DATA
59E50H 59E50H 00000H 82505_FAR FAR_DATA
59E50H 59E50H 00000H SLIP5_FAR FAR_DATA
59E50H 59E50H 00000H _FARBSS FAR_BSS
Here is the detailed breakdown of the FAR_DATA and FAR_BSS classes,
showing the source modules with which the data are associated:
59A3:0000 0000 C=FAR_DATA S=_FARDATA G=(none) M=c0.ASM ACBP=68
59A3:0000 0101 C=FAR_DATA S=TTYDRIV5_FAR G=(none) M=TTYDRIV ACBP=68
59B4:0000 0000 C=FAR_DATA S=IPROUTE5_FAR G=(none) M=IPROUTE ACBP=68
59B4:0000 0200 C=FAR_DATA S=AX255_FAR G=(none) M=AX25 ACBP=68
59D4:0000 0108 C=FAR_DATA S=DRSI5_FAR G=(none) M=DRSI ACBP=68
59E5:0000 0000 C=FAR_DATA S=82505_FAR G=(none) M=8250 ACBP=68
59E5:0000 0000 C=FAR_DATA S=SLIP5_FAR G=(none) M=SLIP ACBP=68
59E5:0000 0000 C=FAR_BSS S=_FARBSS G=(none) M=c0.ASM ACBP=68
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mikebw@idsvax.ids.com (Internet)
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Sun, 7 Jul 91 14:35:51 EST
Subject: NOS Source by Dial-Up Line
I maintain reasonably current copies of NOS source on the ChowdaNet BBS,
(401)331-0334, 300-9600V.32, 8N1. The modem that answers that line is
usually a Hayes Ultra 9600, which does V.32, V.42bis, MNP5, and lots of
other great stuff, but call hunting may also connect you with a Telebit
Trailblazer that will do 19200PEP or 2400v.42bis/2400MNP5. If you want
to get the Trailblazer exclusively, dial (401)274-5817 (until July 10) or
(401)331-0907 (after July 10).
The TCP/IP files are available in area "N". KA9Q sources are given
filenames beginning like "9Qyymmdd.ZIP"; the latest is probably
9Q910618.ZIP, which is the base for PA0GRI NOS. Gerard van der Grinten
gets his initials for PA0GRI NOS; his version 1.7a is GG910618.ZIP.
A version of PA0GRI NOS that I actually use to compile under Borland C++
2.0 is available as GRIBEE04.ZIP.
There are also executables made from GRIBEE04.ZIP source in small and
large versions. The small version omits several drivers, including DRSI
and HAPN, and some features such as Van Jacobsen compression. These
executables are GRINOS.ZIP and GRINOS-S.ZIP for the large and small
versions, respectively.
First time users may download up to three files totaling not more than
1 MB. Users are generally verified on a next-day basis. There are no
fees asked or accepted.
ChowdaNet BBS is a ham radio oriented system with about 1300 files, most
related to radio, electronics, or computer programming. We also have
current and archival versions of major packages, such as G8BPQ, W0RLI,
and AA4RE software.
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mikebw@idsvax.ids.com (Internet)
P.S. To Cap'n Walker: Take those parentheses out of your "From" line.
They mess up the reply command on my mailer.
----
From: "Jay Farlow WB9MDS, 72737,157" <72737.157@CompuServe.COM>
Date: 09 Jul 91 01:54:50 EDT
Subject: Re: Stabilizing NOS?
On Mon, 8 Jul 91 13:45:58 EDT, jra@lawday.daytonoh.ncr.com wrote:
>Maybe we should consider breaking NOS into two versions...
>
>First, create a client-oriented version that doesn't include all the fancy
>protocols, but is stable, well documented, and will fit into memory.
>
>Second, continue development of a server/router oriented NOS that adds the
>additional goodies (maybe some of the client functions could be deleted
>from it to help with the memory problems?).
>
>I lack the time and talent to do the programming, but I'll volunteer to
>do documentation cleanup, packaging, and distribution if we can debug a
>base version and come up with rough docs.
This is a great idea. I just helped a guy put NOS on the air for the first
time, and he would really have appreciated such a package. Also, I
frequently hear from interested beginners on CompuServe and FIDONET. I'll
volunteer to edit/proof the docs, after John has them "cleaned up."
73,
Jay Farlow
Amateur: wb9mds@n9bac.in.usa.na
Fidonet: 1:236/10.6
Compu$erve: 72737,157
Internet (choose one):
wb9mds@k9iu.ucs.indiana.edu
Jay.Farlow@p6.f10.n236.z1.fidonet.org
72737.157@compuserve.com
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Fri, 5 Jul 91 09:17:23 EST
Subject: One more shot at __MKNAME()
Rob is right: DON'T remove the declaration of __MKNAME() as pascal or
things will fail. However, it is possible to do things like that to trick
the linker into letting you make a far call to a near function. That's
legal in C for a cedecl function, since the caller can clean up the stack
as long as it knows that the function is going to do a near return. But
that is not legal for a pascal function. What has to be done is to put
in an override in the MAKEFILE that lets __MKNAME() be in the _TEXT
segment instead of the PC_TEXT segment; then the library's tmpnam() and
fclose() can call it properly. I will geto this in the next day or so.
In the meantime, just comment out __MKNAME() and tmpnam() in PC.C --
it is not that big a thing, folks.
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mikebw@idsvax.ids.com (Internet)
----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <mikebw@idsvax.ids.com>
Date: Sun, 7 Jul 91 14:35:51 EST
Subject: NOS Source by Dial-Up Line
I maintain reasonably current copies of NOS source on the ChowdaNet BBS,
(401)331-0334, 300-9600V.32, 8N1. The modem that answers that line is
usually a Hayes Ultra 9600, which does V.32, V.42bis, MNP5, and lots of
other great stuff, but call hunting may also connect you with a Telebit
Trailblazer that will do 19200PEP or 2400v.42bis/2400MNP5. If you want
to get the Trailblazer exclusively, dial (401)274-5817 (until July 10) or
(401)331-0907 (after July 10).
The TCP/IP files are available in area "N". KA9Q sources are given
filenames beginning like "9Qyymmdd.ZIP"; the latest is probably
9Q910618.ZIP, which is the base for PA0GRI NOS. Gerard van der Grinten
gets his initials for PA0GRI NOS; his version 1.7a is GG910618.ZIP.
A version of PA0GRI NOS that I actually use to compile under Borland C++
2.0 is available as GRIBEE04.ZIP.
There are also executables made from GRIBEE04.ZIP source in small and
large versions. The small version omits several drivers, including DRSI
and HAPN, and some features such as Van Jacobsen compression. These
executables are GRINOS.ZIP and GRINOS-S.ZIP for the large and small
versions, respectively.
First time users may download up to three files totaling not more than
1 MB. Users are generally verified on a next-day basis. There are no
fees asked or accepted.
ChowdaNet BBS is a ham radio oriented system with about 1300 files, most
related to radio, electronics, or computer programming. We also have
current and archival versions of major packages, such as G8BPQ, W0RLI,
and AA4RE software.
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA (AX.25)
mikebw@idsvax.ids.com (Internet)
P.S. To Cap'n Walker: Take those parentheses out of your "From" line.
They mess up the reply command on my mailer.
----
From: FABSOLON%ESOC.BITNET@CUNYVM.CUNY.EDU
Date: Tue, 09 Jul 91 09:20:39 CET
Subject: tmpfile() again ...
Here below a message that I got from the local BBS in Luxemburg.
TCPIP @ALL de:DK5DC 06.07.91 14:32 60 5255 Bytes
tmpfile() again...
*** Bulletin-ID: 06710ADB0BQ ***
910706/1420z DB0GE , 910706/1401z DB0IZ , 910706/1347z DK0MWX
910706/1342z DB0EAM, 910706/1333z DB0BQ
de DK5DC @ DB0BQ
I don't really understand the panic around that fixup overflow in C++ 2.0.
I ran into that error when I rewrote the memory managment to use the C++
routines. (Was just curious if that would give me some relief from the
evergoing memory shortage, well, it did and it works quite stable...).
Okay here's my solution to the TMP problem:
1. take the code as suggested by PE1CHL some time in 1990.
/*----------------------------------------------------------------------*
* same as getenv(), but return "" instead of NULL when it does not exist*
*-----------------------------------------------------------------------*/
char *getnenv (name)
char *name;
{
char *rv;
if ((rv = getenv(name)) == NULL)
rv = ""; /* NULL replaced by "" */
return rv;
}
/*----------------------------------------------------------------------*
* low-level routine used by tmpnam,fixed to use TMP env. variable *
*-----------------------------------------------------------------------*/
char *pascal __nmkname (char *tmpname,unsigned tmpnum)
{
char *tmpdir,*p;
static char staticname80|;
if (tmpname == NULL)
tmpname = staticname;
p = tmpdir = getnenv("TMP"); /* get tempdir name */
if (p0| != '\0')
p += strlen(p) - 1; /* point to last character */
sprintf(tmpname,"%s%sTMP%u.$$$",tmpdir,
((*p != '/' && *p != '\\')? "\\":""),
tmpnum);
return tmpname;
}
unsigned int _tmpnum = 0;
/*----------------------------------------------------------------------*
* new tmpnam function. *
* calls above routine to generate the name, but *
* is otherwise the same as the tmpnam() in the library. *
*-----------------------------------------------------------------------*/
char *tmpnam (char *name)
{
do {
if (_tmpnum == 0xffff)
_tmpnum = 2;
else
++_tmpnum;
name = __nmkname(name,_tmpnum);
} while (access(name,0) != -1);
return name;
}
2. write two more little mickey mouse functions as follows...
/*----------------------------------------------------------------------*
* tmpfile() to circumvent the FIXUP Overflow error of the Turbo C++ *
* linker. Note that remtmp() below has to be registered as an atexit() *
* function in main() DK5DC *
*-----------------------------------------------------------------------*/
FILE *tmpfile(void)
{
char maxname64|;
tmpnam(maxname); /* make the name */
return(fopen(maxname,"w+b")); /* return FILE * */
}
/*----------------------------------------------------------------------*
* routine to remove all existing tmpfiles. *
* this is always called on exit() DK5DC *
*-----------------------------------------------------------------------*/
void remtmp(void)
{
char tname80|;
char *tpath;
struct ffblk ff;
tpath = getnenv("TMP"); /* get tmp */
if (tpath!=0)
sprintf(tname,"%s\\*.$$$",tpath); /* and build template */
else
sprintf(tname,"*.$$$");
/*-------------------------------------------------------------------*
* scan the affected directory for any tmpfile,close and nuke 'em *
*--------------------------------------------------------------------*/
fcloseall(); /* close all files first */
if (findfirst(tname,&ff,0x27))
return;
do {
sprintf(tname,"%s\\%s",tpath,ff.ff_name);
unlink(tname);
}while(!findnext(&ff));
}
3. In main.c, look for a good place during the genesis of NOS and insert
the following statement:
main()
{
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads