Date: Tue, 12 Jan 93 04:30:10 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #12
To: tcp-group-digest
TCP-Group Digest Tue, 12 Jan 93 Volume 93 : Issue 12
Today's Topics:
CPU ID test code
DPMI, etc
Ethernet card selection advice needed (2 msgs)
help AND kf5mg's 'stupid but they work for me fixes'
Jehad, Jehad
Linux & KA9Q
MID - Revisited, finished, moving on...
MID dups problem - Revisited
NOS BBS problem - Message (2 msgs)
PMNOS - unzip
PMNOS1D (2 msgs)
Remote in JNOS 107b
UNSUBSCRIBE
Unwanted mail (2 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 11 Jan 93 15:16:26 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CPU ID test code
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
> Date: Sun, 10 Jan 1993 14:13:42 -0500 (EST)
> Message-Id: <930110141342.4fac@ids.net>
>
> This is what turned out to be what is known here as an "RTFM" problem.
> Borland C offers a "#pragma startup" directive which allows a function
> name to be specified that will be run ahead of main(). It should be
> easy to link in my assembly language CPU type checked so that it is
> called from a C language function referenced with the pragma. The rules
> for the pragma say that it has to take a void argument list and return
> void, and there is no official way to get it to terminate. However, we
> can probably follow the example in C0.ASM and have our C routine call
> the _exit() function if the wrong CPU is found.
Today morning I realized if startup code allows executing procedure
before main and it is specified by address and flags put in some memory
segment, a language should offer possibility to specify procedure to be
executed and I supposed it is some #pragma directive. Your mail I read
when came here saved me need to think which #pragma directive does it.
However, the directive is accepted but probably ignored by TC 1.5 and
2.0 and IT PRODUCES BAD CODE for TC++ 1.01 (seems startup calls offset
of DATA:_heaplen, causing crash). For BC 3.0 it works OK.
Borland says priorities 0-63 are reserved, but should use just 0!
I have put example program as CPUCHK1.ZIP on zfja-gate.
I'm just trying to implement another idea: modify NOS.EXE
73's, JT
------------------------------
Date: Mon, 11 Jan 93 09:41:51 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: DPMI, etc
To: jmorriso@ee.ubc.ca, tcp-group@ucsd.edu
> About the only real 286 solution might be to dredge up a copy of OS/2 1.3
> and TCP/IP. Dump in lots of RAM, and then we would get pre-emptive
> multitasking, threaded execution, etc. Has anyone tried this?
Funny you should mention OS/2, I just got some hate mail from Alan, must be
another Windows weenie. At any rate, I have had 4 versitcp-group@ucsd.eduns of
NOS for OS/2 1.3,
I believe the last release OS2NOSV4 is still at ucsd in some pertainant dir. If
you have only a 286 and really want preemptive multitasking than your choices
are few. Since IBM doesnt support 1.3 any longer neither do I. You dont need
that much memory, I was running with 4 meg just fine. If you want to dedicate
the 286 to NOS you might be better off using a JNOS for compatibility and
features. The fastest 286 I can think of was abt 12mhz, I wouldnt want to do
very much multitasking with only 12 mhz in a PM /windows environment.
What I had sent out last week and it never got back here, so the i-net monster
must of eaten it is that it would seem to me the most straight-forward way
to capitalize on above the line memory is to write the present device
interfaces as real live Device drivers. With the asy / ether and scc logic as
device drivers one can tell DOS to load them high thus freeing a substancial
amt of memory below the line. The effort required to do that would be minor
compared to the effort to use DPMI throughout NOS. Walt
------------------------------
Date: Mon, 11 Jan 93 18:58:19 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Ethernet card selection advice needed
To: crompton@NADC.NAVY.MIL (D. Crompton)
Hello, Doug
Our institute needs buy several new E. cards in nearest future.
Till now we are using Gateway's G/Ethernet 8, G/Ethernet 16 and
3Com 3C503 (8 bit) cards. Most important things for us are:
- high transfer speed: we found it depends on card memory size, the
few kB on 3C503 is insufficient, card should be rather 16-bit.
G/Ethernet 16 gives 250kB/s
- low price, if possible
- packet driver available
- thin (50 Ohm RG-58 coaxial) cable interface
Few weeks ago (15 Dec) Doug Crompton wrote about 3Com's 16-bit board
for $135, later (18 Dec): it is 3com Etherlink III, 'around $125',
Gateway sells it for $105; does anyone have experience with it
(transfer speed, how much on-board memory, reliability) ?
Is any 8-bit card for small price available ? (we have few old XT-s
and will probably need one or two e. cards for them).
Thanks for any info and 73's, JT
------------------------------
Date: Mon, 11 Jan 93 13:55:34 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: Ethernet card selection advice needed
To: JT@zfja-gate.fuw.edu.pl, crompton@NADC.NAVY.MIL
The etherlink III is around $125. It is ADVERTISED to be fast - faster
than any previous 16 bit card. The next Clarkson release WILL support it.
Sounds like a winner to me - but I have no actual experience with it!
Doug
------------------------------
Date: Mon, 11 Jan 93 14:09:16 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: help AND kf5mg's 'stupid but they work for me fixes'
To: TCP-Group@UCSD.Edu, kf5mg@vnet.ibm.com
Thanks Jack,
The lines -
if(strlen(cp) <= OBLEN )
strcpy(origbbs,cp);
Shouldn't it be '<' rather than '<=' - strlen does not count terminating
null, strcpy copies it. origbbs is defined as origbbs[OBLEN]. So if cp's
len really is OBLEN then origbbs will overwrite origbbs by 1 character.
Either delete the '=' or make origbbs[OBLEN+1]; as I see it????
This is also true for ODLEN and origdate.
The length will probably never be the max by this is inviting a problem.
Doug
------------------------------
Date: Mon, 11 Jan 93 10:03:13 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: Jehad, Jehad
To: tcp-group@ucsd.edu
> For better or for worse this computer uses a intel 386 cpu that
> is interupt driven. There is no magic way to do things any better than
> windows does to do what it does. Period.
>
> 73, karl k5di@k5di
Guys...Guys...
Boy I sure hope I didnt inadvertantly start another Jehad, Has it been 6 months
already??
There is no reason for people to get into a lather because OS/2 is popular,
trust me, Bill Gates sleeps just fine at night and so should we all. Linix and
other real operating systems are out there and garner a certain amt of
popularity. Windows is not a real operating system, its an operating
environment. WIndows does not multitask, the i386 supports virtual 8086 "boxes"
which look like multiple xt's running in one machine. That having been said,
Windows is somewhat popular as well. "Cant we all just get along" (Rodney King)
Walt
------------------------------
Date: Tue, 12 Jan 93 09:23:07 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Linux & KA9Q
To: tcp-group@ucsd.edu
A word of warning:
The standard KA9Q distributed for Linux is meant for people using
SLIP and terminal servers (mainly from before kernel slip appeared). It
crashes quite easily, especially the mailbox and has bugs in the mulport
repeater code.
Last time I tried it wampes was 'getting there', and was very much
a 'my god it works' version still needing all the tidying up doing. I've
not seen the current version but people say its quite neat and stable.
There's also my much hacked Linux KA9Q Net which has other oddities
added to it but isn't very distributable yet that gives you things like
AX.25 logins and bulletins forwarded to be read with trn.
Linux has proved stable although 20Mb is a more realistic minimum disk
space usage for a basic system. For anyone doing any compiling or other
work I nornmally reckon on 40Mb for Linux 60-70Mb for 386BSD. I've built
Linux for a 1Mb machine successfully (forget X, emacs or gcc tho), and
in 5Mb or so you can build a minimal dedicated KA9Q system. The trouble is
without a NOS port or further work we don't yet have the software to make
full use of this 8-)
Alan
------------------------------
Date: 11 Jan 1993 22:59:11 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: MID - Revisited, finished, moving on...
To: johan@ECE.ORST.EDU
[Originally posted 01/10/93.... don't ask me where it went!]
Here is the "absolute" fix to the MID problem. These few lines make a brand
new MID for each message (after the first) generated from an incoming message.
This works equally well with CC's, aliases, etc. The first message in a list
retains the original MID, all others get new numbers.
Ignore previous hack and apply this fix.
All changes are in SMTPSERV.C. The line numbers given are for WG7J107b.
insert lines with '>>', change lines with "**"
smtpserv.c at line 493
extern int Smtpquiet;
>> int index;
if ((Smtpmode & QUEUE) != 0)
smtpserv.c at line 528
#endif
>> index = 0;
** for(ap = tolist;ap != NULLLIST;ap = ap->next, index++){
smtpserv.c at line 584
}
>> if (index && htype(buf) == MSGID) {
>> fprintf (fp, "%s<%ld@%s>\n",Hdrs[MSGID],get_msgid(),Hostname);
>> } else
fputs(buf,fp);
73 from Brian A. Lantz KO4KS@KO4KS.#TPAFL.FL.USA.NA 3100813105
Internet: brianlantz@delphi.com
Amprnet: ko4ks@ko4ks.ampr.org [44.98.0.167]
------------------------------
Date: Mon, 11 Jan 93 10:27:20 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: MID dups problem - Revisited
To: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
> 1. You're preaching to the choir! That's why we are using NOS and not a
> "regular" BBS. It IS NOT a problem sending to standard BBSs, since NOS
> truncates the BID/MID to 13 characters if it is larger.
It IS a problem. Let's take a simple example. Suppose you have two
public message areas on a NOS system called 'wanted' and 'sale'.
These message areas are forwarded to other BBSs. Send a message via
SMTP to 'wanted' from one of many systems that use long MIDs. Now send a
second message to 'sale' from the same system. Chances are that the
first 13 bytes of both MIDs are identical and most mailers don't allow
the user to assign the MID. Only the first message will be forwarded
beyond the NOS system, the other will be rejected because the
receiving BBS thinks it's a dupe.
> 2. Whose idea? Don't ask me, I just try to make TNOS co-exist with the
> "standard".
The BBS 'standard' is the one that needs fixing, not NOS.
> 3. We need to generate a new MID because NOS handles aliases by using the
> same internal MID number for all messages from a common base message.
> Thus the problem that OTHERS reported. I simply gave you a way around it.
>
> 4. You STILL have the option of IGNORING the fix, and living with the
> problem! No skin off my back ;-)
>
> All I know is that the fix WORKS! Until something better comes along, feel
> free to use it or ignore it!
You're only trading one problem for another.
Tony
------------------------------
Date: Mon, 11 Jan 93 09:35:01 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: NOS BBS problem - Message
To: johan@ece.orst.edu
Here is the complete message that totally bombs NOS's BBS. It is
consistent! After all of the R: lines are received and just as
the subject and message ID comes in it locks the system with an
'invalid pointer' It requires a hard reset.
After the BBS that was sending me this deleted it from my queue
10 messages came im without a hitch. So something in the BBS is
not accepting something in this message - possible R line filtering?
This is 1.07b code - also 1.06 code WG7J.
Message follows - comments are from the BBS op.
Hi Doug,
Here is the only bulletin on my system with "earth" in the title.
28698 BN 1325 ALL W3QNS AMSAT 1 930109 1540 EARTHWINDS-BUL
R:930109/1533z 461@N3ACL.#EPA.PA.USA.NA Eagleville Z:19408
R:930109/1406z 393@N3ET.PA.USA [Allentown] Z:18103 $:48_UO22
R:930109/1014z 16212@K3RLI.#EPA.PA.USA.NA
R:930109/0954z 38255@NR3U.PA.USA.NA
R:930109/0821z 7552@W3AVK.#EPA.PA.USA.NA
R:930109/0656Z @:WA3WPS.#WPA.PA.USA.NA [EMPORIUM,PA] FBB5.14d #:4160
R:930109/0703Z @:K3MD.#WPA.PA.USA.NA [DuBois, PA] FBB5.14 #:18525
R:930109/0254Z @:W3YA.PA.USA.NOAM [State College] #:29685 $:48_UO22
R:930109/0239z @:W3KDC.MD.USA.NOAM Cresaptown #:1847 $:48_UO22
R:920108/1105Z @:N4YRZ.VA.USA.NA [Moscow Va,] - FBB5.14d #:16537
R:930104/0722Z @:N4ZKF.VA.USA.NA 48_UO22 #:20137
R:930103/2008Z @:KC7Y.AZ.USA.NA [Mesa,Az TELINK] FBB5.14d #:38182 Z:85204
R:930103/1210Z @:N7MRP.AZ.USA.NA [ FBB-TELINK - Phx,Az ] #:42885 Z:85016
R:930103/0727Z @:VE4KV.#WPG.MB.CAN.NA [Winnipeg] FBB5.14g #:53518
R:1230/1058 @: #:48 Z:00000
Subject: EARTHWINDS LAUNCH
Message-Id: <921228181039_70304.326_DHP47-1@CompuServe.COM>
The globe circling EARTHWINDS balloon is again ready for launch with
the new anchor balloon on site at Reno, NV. They have decided not to
house the anchor balloon in a new inflatable dome. Launch is currently
on hold due only to weather conditions locally. The weather may be more
cooperative this weekend or perhaps as early as Friday. Stay tuned!
Rich, n8iwj@amsat.org
**********************************************************************
Possibly the initial R: line is the problem. There is no call after the @:
It's been a while but I think my code handles that case. If NOS does
anything with the Message-Id: field, it is awfully long.
The bulletin is no longer queued to you.
73, John
***********************************************************************
Doug
------------------------------
Date: Mon, 11 Jan 93 11:07:14 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: NOS BBS problem - Message
To: crompton@NADC.NAVY.MIL (D. Crompton)
If you turn 'bulletin date on' for that earthwinds message, I think NOS might
accept the message. However, it will generate a bad SMTP Date header.
That's what happened here when the thing came in from our satellite gateway.
Tony
------------------------------
Date: Mon, 11 Jan 93 14:30:06 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: PMNOS - unzip
To: tcp-group@ucsd.edu
For those that maybe grabbed the new PMNOS1D but discovered they didnt have the
proper unzip, the OS/2 32 bit GNU unzip is available with the PMNOS1D?.zip
files at giskard.uthscsa.edu. Remember folks, Fri is the last day these files
will be available at giskard.uthscsa.edu, its easy to locate now, at ucsd it
may move around and I wont know where it is. Anyways, thanks Jack for providing
the unzip util. Also, for people experiencing problems with the Font Mgr, its
strange, some people are having major problems with it and for others it runs
flawlessly. I, personnally, only have problems with it occationally but it
works ok after a failure. Walt
------------------------------
Date: Mon, 11 Jan 93 07:53:28 EST
From: "Jon Maguire maguire@sppvm1.vnet.ibm.com" <MAGUIRE@SPPVM1.VNET.IBM.COM>
Subject: PMNOS1D
To: TCP-group@UCSD.edu
Where is the aforementioned? It's not at ucsd.edu incoming and I can't
get to wg7j. I'd sure like to get a copy.
-----------
Jon Maguire N1CQE/4 | ibm-vm: maguire@sppvm1 usib2tfc@ibmmail
Advantis | Packet: N1CQE@KC4LDT.#CLWFL.FL.USA.NA
Dept 8QD / Bldg PAV | voice: t/l:438-3038 external:(813)-878-3038
3105 W. M.L.King Blvd.| fax : t/l:438-3922 external:(813)-878-3922
Tampa, FL 33607 | AMSAT #21847 TAPR #2916 TPALAN BARS
| Internet: maguire@sppvm1.vnet.ibm.com
| IP 44.98.0.136 N1CQE-7.ampr.org
------------------------------
Date: Tue, 12 Jan 93 09:31:24 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: PMNOS1D
To: tcp-group@ucsd.edu
For UK people I've uploaded PMNOS1D and PKUNZIP onto sunacm.swan.ac.uk also
Alan
------------------------------
Date: Mon, 11 Jan 93 9:06:19 EST
From: John Ackermann AG9V <John.Ackermann@DaytonOH.NCR.COM>
Subject: Remote in JNOS 107b
To: A.D.S.Benham@bnr.co.uk
You (A.D.S.Benham@bnr.co.uk) write:
>
> I spent the weekend compiling 1.07b of JNOS to replace my current NOS (my own
> compile of JNOS 1.01).
> I use Borland C++ v3.0, compiling with 80186 instructions.
>
> Everything seemed to work fine, except for the "remote" command.
>
> Trying "remote g8fsl kick" gives the error "Unknown command g8fsl".
> But 'g8fsl' is supposed to be the host, not the command!
> Having checked that the command syntax hadn't changed between JNOS versions,
> I checked the 1.01 and 1.07 sources in the appropriate areas - identical!
I saw this problem with, I think, v1.05. It seems to be fixed in the
1.07 I'm running.
BUT... after much frustration, I finally came to the realization:
BC++3.0 WILL NOT reliably compile JNOS. None of the executables I
created of any version (well, at least 1.04 and up) would run for more
than a few hours without a hard crash.
I broke down and upgraded to 3.1 and my most recent compile of 1.07b has
been up for 4 days with no problems and lots of coreleft.
I don't know what the problem with 3.0 is, but 3.1 solves it.
John
------------------------------
Date: Fri, 8 Jan 93 9:45:44 CST
From: Douglas Drury <drury@STEPSUN.ARMY.MIL>
Subject: UNSUBSCRIBE
To: tcp-group@UCSD.EDU
UNSUBSCRIBE
------------------------------
Date: Mon, 11 Jan 1993 10:13:50 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: Unwanted mail
To: andy@mimuw.edu.pl
Although it doesn't solve the accepting mail to the user,
you could use a rewrite file or alias to change sp5wca@sp5wca to andy@sp5wca
and the rewrite file to change all unknown users to a single mail file.
milton
PS: In the AMPR community, not everyone will know your name but will know
your call by seeing you on the air, so I like to see call@call.ampr.org
be received by someone.
------------------------------
Date: Mon, 11 Jan 1993 19:18:19 -0100 (GMT-1:00)
From: andy@mimuw.edu.pl (Andrzej K. Brandt)
Subject: Unwanted mail
To: miltonm@inetnode.austin.ibm.com (Milton Miller)
Milton Miller wrote:
>PS: In the AMPR community, not everyone will know your name but will know
>your call by seeing you on the air, so I like to see call@call.ampr.org
>be received by someone.
Probably you are right, but mail to unknown users should be rejected, so the
sender would know that address he has is wrong. Currently such mail may simply
wanish without any trace.
And I really don't like mail adressed as call@call.ampr.org... (But that's my
personal opinion only)
--
73 de Andy SP5WCA
/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I
\-------------------+--------+-------------------+-------------------------/
------------------------------
End of TCP-Group Digest V93 #12
******************************
******************************