Date: Tue, 16 Feb 93 04:30:13 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 #44
To: tcp-group-digest
TCP-Group Digest Tue, 16 Feb 93 Volume 93 : Issue 44
Today's Topics:
16554 UART
Mail Path to JT
stat()
stat() et. all
Stat - Hello wake up !
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, FEB 15 1993 09:23:17
From: Carlton Ellis <CELLIS%BROCK1P.bitnet@CUNYVM.CUNY.EDU>
Subject:
To: <tcp-group@ucsd.edu>
Sub Carty Ellis KA2Y
------------------------------
Date: Mon, 15 Feb 93 15:53:12 MST
From: wbaggett@NMSU.Edu
Subject: 16554 UART
To: TCP-Group@UCSD.Edu
Sorry for the noise, but does anybody here know anything about the 16554
UART? I ran across a 4 port serial i/o card that lets you choose from a
wide range of i/o addresses and IRQ's. The box says it uses the 16554 and
then says it is 16550 compatible. The question is, **really**??, including a
working fifo? I have never seen that chip mentioned before, and it is not in
any of the catalogs I have.
Direct replies are fine. If anybody else wants to know what if any answers
I get, E-mail me direct and I will send same to you.
Thanks much. Tim, AA5DF, wbaggett@NMSU.edu
------------------------------
Date: Mon, 15 Feb 1993 08:19:19 PST
From: David_Shalita.ES_AE@xerox.com
Subject: Mail Path to JT
To: tcp-group@ucsd.edu
I am trying without success to send mail
to JT@zfja-gate.fuw.edu:pl. Please forward this message to him.
Hello JT:
Please send me a short note so I can find the proper mail address back to you.
Thanks, Dave
------------------------------
Date: Mon, 15 Feb 93 22:10 GMT
From: Ian Campbell <softice@cix.compulink.co.uk>
Subject: stat()
To: crompton@nadc.navy.mil, kz1f@legent.com, tcp-group@ucsd.edu
In <24721.9302100918@pyr.swan.ac.uk> Alan Cox writes:
> stat can be a bit funny on Borland 3.0 - stat of a drive root fails
> for example. Also stat on a novell directory reports both the file
> and directory bits being set. You just trust the directory one.
> I don't know if 3.1 fixed these odd cases.
> Thats my experience anyway with straight BC3.0 and no patches or
> upgrades on it.
Checked 3.1 and stat() on drive root appears to work and reports the
directory bit set.
Ian
softice@cix.compulink.co.uk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
------------------------------
Date: Tue, 16 Feb 93 10:30:28 CET
From: dk5dc@vnet.ibm.com
Subject: stat() et. all
To: TCP-GROUP@ucsd.Edu
Alan writes:
>> stat() I somehow think will stay in all of the compilers for a long time
>> its in POSIX, and its unix since somewhere near day 1. I'd also suggest not
>> using findfirst() but using opendir() closedir() and readdir() which are
>> _standard_ directory reading facilities.
k1zf writes:
> Posix, find me a posix compliant compiler for DOS/WINDOWS/OS2 architectures.
> Find me a posix version of NOS.
> I am familiar with IBM, microsoft and Borland c compilers, I have never seen a
> "standard" oppendir(), closedir() and readdir().
> Alan, the ANSI standards
> committe, for right or wrong, did not include stat().
> Walt
I played with the ....dir() functions introduced in BC++.
In my Opinion, those guys lack *essential* information.
I mean, it does not make any sense to use those function for
the benefit of getting just a name and a bunch of strange
fields like _d_magic.......
No filesize, no filedate, no nothin.......
For me, it looks like a typical comittee construct:
lots of participating people, few with practical experience
Peter DK5DC/AA6HM
------------------------------
Date: Tue, 16 Feb 93 10:02:36 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Stat - Hello wake up !
To: tcp-group@ucsd.edu
There are times when people annoy me.. I shall try not to make this
a flame. Walt KZ1F claims to know borland c compilers and has
never seen a standard opendir() closedir() readdir(). Could have
fooled me, dunno how all my programs using opendir() could
possibly compile unchanged on Borland C.
You don't know a POSIX complaint compiler, I've yet to meet one
I admit, but GCC for OS/2 is pretty close.
Findfirst() and findnext() are a pair of almost PC only calls.
A summary from the machines I use
Type findfirst opendir stat
IBM PC Y Y Y
(DOS/Windows/BC)
CBM Amiga(GCC) N Y Y
Linux(GCC) N Y Y
SYS5.4 (CC) N Y Y
Get the idea.
In addition emulating the MSDOS findfirst/next calls in most
operating systems isn't possible because DOS times are accurate
to only 2 seconds and the years begin in 1980. It is trivial
to write a unix stat() call in terms of the DOS findfirst/next
interrupts.
I think it's rather obvious which way to go, especially since
contrary to some people's belief NOS gets ported onto other
things than DOS - AmigaNOS for example, and bits of it keep
getting added to things like the Unix NET.
KA9Q in the DOS world has already got itself trapped and dependant
on a paticular species of a paticular compiler. If anything the
way forward with NOS is a specify set of standard facilities
locked firmly away in machine specific subdirectories and a
standard commonly found set of functions for acheiving most
things - it's even mostly there.
Alan
------------------------------
End of TCP-Group Digest V93 #44
******************************
******************************