> > I am thinking about a new file transfer technique: SET FILE TYPE
> > INFOZIP which would first create a ZIP file, transfer it in BINARY
> > mode, and then UNZIP it. This would take care of the inefficiencies
> > associated with transfering hundreds of small files that fit within one
> > packet.
>
> We would certainly approve. The requirements are fairly loose. If you
> use the DLL (by linking it in if it exists or not if not) or call the
> executable as a subprocess, you don't even have to care about
> copyrights. And if you integrate the source code directly, all you
> need to do is to put the proper statements into the docs.
>
Thanks, Kai Uwe (and hello :-)
There are several problems with this scheme, though. My greatest quibble
with the ZIP approach is that the results are not truly transportable.
If I have a directory containing a mixture of text and binary files, and I
ZIP it, and then I transfer the ZIP file to another computer that uses a
different text-file format, then either the binary files or the text files
will be in the wrong format.
Obviously, Kermit has the same problem. The real solution here is to be able
for the software (ZIP or Kermit) to determine automatically, for each file,
whether it is text or binary. But in most common settings, that would be
impossible -- DOS, Windows, UNIX, etc. VMS lets us do this by inspecting the
record format (but even then, we are sometimes fooled -- e.g. VMS ZIP files
have a text-type record format, Stream_LF).
In DOS and Windows, I suppose we could go by filetype (e.g. ".TXT" is text),
but of course it is not reliable. In UNIX we don't even *have* filetypes.
We do have the "file" program in UNIX, but it guesses wrong more often than
not.
So I am not sure that having Kermit use ZIP format at the presentation layer
is a good idea. As for solving the other problem -- transferring a large
number of tiny files -- we already have a way to do this. The challenge is
to make it work more efficiently. The barrier to that challenge is the
Attribute refusal mechanism.
In the current scheme, we use sliding windows only during the data phase.
Now consider a wildcard transfer, with many files. If we were to allow
sliding windows during *all* phases of the transfer, then the sender might
have sent up to 32 packets of file data (potentially up to 9K each) before
receiving the attribute refusal. This is far LESS efficient that turning off
windowing during the filename-attribute phase.
When transferring between LIKE systems, ZIPping is a good way to solve this
problem, but otherwise it is likely to introduce more problems (corrupted
files) than it solves.
> > Also, Frank and I have always been troubled by the problems associated
> > with transfering directory trees from DOS/Unix to VMS since the
> > directory structures are so completely incompatible. How does Info-ZIP
> > handle the recreation of directory trees between these systems?
>
> Transparently. The / separators in archives are treated as "canonical"
> and are translated into the local separators of the actual OS, such as
> \ on DOS or OS/2, / on Unix and [.] on VMS.
>
I suppose we could do this too. In VMS C-Kermit, we could offer a "UNIX" mode
for filenames and paths -- incoming and outgoing. Ditto for Windows and OS/2,
where it's easy. So much for the presentation layer. We already support
automatic directory creation, so then it is simply a matter of adding the
ability to "recurse" to our filename expanders.
I'm not sure that this is the right way to solve the problem, because it
assumes that every other file system in the world can map to the UNIX file
system (a structural issue), and on a more simplicistic level, that directory
names can never contain slashes (or if they can, then we must introduce a new
kind of quoting rule for pathnames).
Anyway, this is all stuff for the distant future, not for now.
- Frank
27-Aug-96 14:33:19-GMT,2733;000000000001
Received: from ars.de (firewall.ars.de [194.97.120.113]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id KAA12640 for <fdc@WATSUN.CC.COLUMBIA.EDU>; Tue, 27 Aug 1996 10:33:16 -0400 (EDT)
Received: from jonas.ars.de by ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
id AA0160; Tue, 27 Aug 96 16:32:34 +0200
Received: by internal-host.ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be. -Russell Williams
27-Aug-96 18:25:10-GMT,3759;000000000011
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA25239 for <fdc@watsun.cc.columbia.edu>; Tue, 27 Aug 1996 14:25:08 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id NAA26159; Tue, 27 Aug 1996 13:24:12 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA06405; Tue, 27 Aug 1996 13:26:17 -0500 (CDT)
To: Zip-Bugs@LISTS.WKU.EDU, fdc@watsun.cc.columbia.edu, jaltman@columbia.edu
Subject: Re: Info-ZIP and C-Kermit
Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu
> Thanks, Kai Uwe (and hello :-)
Hi (and hi to Joe--we had e-mail years ago, but I don't remember what about),
> There are several problems with this scheme, though. My greatest quibble
> with the ZIP approach is that the results are not truly transportable.
> If I have a directory containing a mixture of text and binary files, and I
> ZIP it, and then I transfer the ZIP file to another computer that uses a
> different text-file format, then either the binary files or the text files
> will be in the wrong format.
Not so. As long as you can specify accurately which is which, UnZip can
do translations on the fly. (Of course, since I currently have Kermit
pegged as the world's second most portable program and UnZip as third,
I'm assuming you have a few ports that we don't, and those could be a
problem.)
Note that Zip currently *tries* to identify text vs. binary, but it fails
every now and then (especially on Windoze DLLs--it's only about 70% accurate
there, vs. maybe 97% on most files--at least for me). If you choose to make
use of Info-ZIP code directly, that's one area where you'd want to modify
the existing code.
> VMS lets us do this by inspecting the
> record format (but even then, we are sometimes fooled -- e.g. VMS ZIP files
> have a text-type record format, Stream_LF).
Hmm, I thought we had switched to fixed-512 for zipfiles. In any case,
stream-anything is pretty rare in VMS and could be treated the same way
as DOS or Unix.
> We do have the "file" program in UNIX, but it guesses wrong more often than
> not.
Depends on which version you're using... Darwin's is pretty good (if I
do say so myself :-) ).
> When transferring between LIKE systems, ZIPping is a good way to solve this
> problem, but otherwise it is likely to introduce more problems (corrupted
> files) than it solves.
Erm...well, nothing personal, but Kermit's "assume it's text unless told
otherwise" behavior has introduced plenty of problems and corrupted files
itself...
> I'm not sure that this is the right way to solve the problem, because it
> assumes that every other file system in the world can map to the UNIX file
> system (a structural issue), and on a more simplicistic level, that directory
> names can never contain slashes (or if they can, then we must introduce a new
> kind of quoting rule for pathnames).
So far, the Unix filesystem is *the* most encompassing of any we've
encountered. The / issue does come up on Acorn RISC OS, but one could
flag those filenames specially and swap with dots (which are what they
use for directory separators). The real problem comes when you move a
rich directory system to a lousy (DOS) or non-existent (TOPS-20) one
and have to deal with all sorts of translations, truncations and name-
collisions. One way or the other, user input is necessary then.
--
Greg Roelofs "Name an animal that's small and fuzzy." "Mold."
newt@pobox.com or http://pobox.com/~newt/
27-Aug-96 18:44:18-GMT,1418;000000000011
Received: from GRUMPY.USU.EDU (grumpy.usu.edu [129.123.1.86]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA02418 for <FDC@WATSUN.CC.COLUMBIA.EDU>; Tue, 27 Aug 1996 14:44:17 -0400 (EDT)
Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556)
id <01I8RR0YMB0WCE2FIO@cc.usu.edu>; Tue, 27 Aug 1996 12:43:37 -0600 (MDT)
> Well, by everyone's admission filenames alone are insufficient to
> distinguish binary from text files. Looking at the first N bytes (whether
> two for MZ or 512) is insufficient also (lines don't have to break at 80
> columns). On machines with rich attributes those attributes are insufficient.
> In short, what's text and what's binary is "in the eyes of the beholder",
> and a particular beholder isn't predictable (or fixed) in advance.
> The conclusion is glaringly obvious, isn't it. People must choose
> because machines cannot. And that, I believe, is the end of this story.
>
Absolutely, at least for most operating systems. Personally, I think it would
be interesting to design a new file system in which files could be tagged as
text or binary -- by the application that created them, and also (as an
override) by their (human) owners. When files were text, I think it would
also be a great boon to humankind if they could be tagged as to the character
set of encoding. To my knowledge, no file system has ever provided such a
service in the file system itself. "Binary" would mean, simply, that if the
file is to be transferred to another computer, no conversions should be done.
Conversely, "text" would mean that record-format and character-set conversions
should be done.
To reinforce Joe's point about inspection: a long time ago, somebody wrote a
Kermit program that decided if a file was text or binary based on whether it
contained any bytes with the 8th bit turned on. Sombody else checked for lots
control characters. None of this works when a text file is Latin-1, CP850,
UNICODE, Hebrew, Russian, Japanese, etc. On the other hand, I have seen Intel
executables composed of only printable ASCII characters. (We have one in the
Kermit archives somewhere but I can't put my finger on it at the moment...)
- Frank
27-Aug-96 14:33:19-GMT,2733;000000000001
Received: from ars.de (firewall.ars.de [194.97.120.113]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id KAA12640 for <fdc@WATSUN.CC.COLUMBIA.EDU>; Tue, 27 Aug 1996 10:33:16 -0400 (EDT)
Received: from jonas.ars.de by ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
id AA0160; Tue, 27 Aug 96 16:32:34 +0200
Received: by internal-host.ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be. -Russell Williams
27-Aug-96 18:25:10-GMT,3759;000000000011
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA25239 for <fdc@watsun.cc.columbia.edu>; Tue, 27 Aug 1996 14:25:08 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id NAA26159; Tue, 27 Aug 1996 13:24:12 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA06405; Tue, 27 Aug 1996 13:26:17 -0500 (CDT)
To: Zip-Bugs@LISTS.WKU.EDU, fdc@watsun.cc.columbia.edu, jaltman@columbia.edu
Subject: Re: Info-ZIP and C-Kermit
Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu
> Thanks, Kai Uwe (and hello :-)
Hi (and hi to Joe--we had e-mail years ago, but I don't remember what about),
> There are several problems with this scheme, though. My greatest quibble
> with the ZIP approach is that the results are not truly transportable.
> If I have a directory containing a mixture of text and binary files, and I
> ZIP it, and then I transfer the ZIP file to another computer that uses a
> different text-file format, then either the binary files or the text files
> will be in the wrong format.
Not so. As long as you can specify accurately which is which, UnZip can
do translations on the fly. (Of course, since I currently have Kermit
pegged as the world's second most portable program and UnZip as third,
I'm assuming you have a few ports that we don't, and those could be a
problem.)
Note that Zip currently *tries* to identify text vs. binary, but it fails
every now and then (especially on Windoze DLLs--it's only about 70% accurate
there, vs. maybe 97% on most files--at least for me). If you choose to make
use of Info-ZIP code directly, that's one area where you'd want to modify
the existing code.
> VMS lets us do this by inspecting the
> record format (but even then, we are sometimes fooled -- e.g. VMS ZIP files
> have a text-type record format, Stream_LF).
Hmm, I thought we had switched to fixed-512 for zipfiles. In any case,
stream-anything is pretty rare in VMS and could be treated the same way
as DOS or Unix.
> We do have the "file" program in UNIX, but it guesses wrong more often than
> not.
Depends on which version you're using... Darwin's is pretty good (if I
do say so myself :-) ).
> When transferring between LIKE systems, ZIPping is a good way to solve this
> problem, but otherwise it is likely to introduce more problems (corrupted
> files) than it solves.
Erm...well, nothing personal, but Kermit's "assume it's text unless told
otherwise" behavior has introduced plenty of problems and corrupted files
itself...
> I'm not sure that this is the right way to solve the problem, because it
> assumes that every other file system in the world can map to the UNIX file
> system (a structural issue), and on a more simplicistic level, that directory
> names can never contain slashes (or if they can, then we must introduce a new
> kind of quoting rule for pathnames).
So far, the Unix filesystem is *the* most encompassing of any we've
encountered. The / issue does come up on Acorn RISC OS, but one could
flag those filenames specially and swap with dots (which are what they
use for directory separators). The real problem comes when you move a
rich directory system to a lousy (DOS) or non-existent (TOPS-20) one
and have to deal with all sorts of translations, truncations and name-
collisions. One way or the other, user input is necessary then.
--
Greg Roelofs "Name an animal that's small and fuzzy." "Mold."
newt@pobox.com or http://pobox.com/~newt/
27-Aug-96 18:44:18-GMT,1418;000000000011
Received: from GRUMPY.USU.EDU (grumpy.usu.edu [129.123.1.86]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA02418 for <FDC@WATSUN.CC.COLUMBIA.EDU>; Tue, 27 Aug 1996 14:44:17 -0400 (EDT)
Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556)
id <01I8RR0YMB0WCE2FIO@cc.usu.edu>; Tue, 27 Aug 1996 12:43:37 -0600 (MDT)
> Well, by everyone's admission filenames alone are insufficient to
> distinguish binary from text files. Looking at the first N bytes (whether
> two for MZ or 512) is insufficient also (lines don't have to break at 80
> columns). On machines with rich attributes those attributes are insufficient.
> In short, what's text and what's binary is "in the eyes of the beholder",
> and a particular beholder isn't predictable (or fixed) in advance.
> The conclusion is glaringly obvious, isn't it. People must choose
> because machines cannot. And that, I believe, is the end of this story.
>
Absolutely, at least for most operating systems. Personally, I think it would
be interesting to design a new file system in which files could be tagged as
text or binary -- by the application that created them, and also (as an
override) by their (human) owners. When files were text, I think it would
also be a great boon to humankind if they could be tagged as to the character
set of encoding. To my knowledge, no file system has ever provided such a
service in the file system itself. "Binary" would mean, simply, that if the
file is to be transferred to another computer, no conversions should be done.
Conversely, "text" would mean that record-format and character-set conversions
should be done.
To reinforce Joe's point about inspection: a long time ago, somebody wrote a
Kermit program that decided if a file was text or binary based on whether it
contained any bytes with the 8th bit turned on. Sombody else checked for lots
control characters. None of this works when a text file is Latin-1, CP850,
UNICODE, Hebrew, Russian, Japanese, etc. On the other hand, I have seen Intel
executables composed of only printable ASCII characters. (We have one in the
Kermit archives somewhere but I can't put my finger on it at the moment...)
- Frank
27-Aug-96 22:35:23-GMT,3278;000000000011
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id SAA23564 for <fdc@watsun.cc.columbia.edu>; Tue, 27 Aug 1996 18:35:22 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id RAA10648; Tue, 27 Aug 1996 17:29:22 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id RAA04577; Tue, 27 Aug 1996 17:31:32 -0500 (CDT)
[I got interrupted in writing this, and now I see there are other
messages in the thread, so apologies if there's some duplication.]
> Kermit 95, by the way, uses binary
> by default, since most Windows users are transferring only ZIP, GIF, or JPG
> files.
Oh, cool. I'll have to make note of that in our docs.
> Many people say it is better to just always transfer in binary mode, because
> at least then you don't corrupt the binary files (ZIP, GIF, tar.gz, etc), and
> even though you do corrupt the text files, the corruption is recoverable by
> knowledgeable people. I don't share that point of view, however, because (a)
> an ever-increasing percentage of computer users are *not* knowledgeable, and
> (b) text-file transfer converts not only the record format, but also the
> character-sets, a consideration that most English speakers (or non-users of
> IBM mainframes) tend to overlook.
I don't consider non-conversion of text files to be "corruption"; it's
simply non-translation (or deferred translation, if you prefer). On
the contrary, translation from an 8-bit (or more) character set to 7-bit
(or even to another 8-bit set) can introduce irreversible corruption
simply due to the fact that there's no one-to-one mapping from the first
set into the second. You can never win in that regard; you simply do
your best and hope it's good enough.
(Related anecdote: there's no way for a text-mode utility to do such
translations under Linux since X provides a Latin-1 character set and
Linux virtual consoles [I'm pretty sure] use the IBM PC character set.
One or the other will always be wrong for those using extended/foreign
characters.)
> Hey! TOPS-20 was just like VMS.
Similar, but my understanding is that (1) there's only one level of
subdirectories, and (2) you have to specify how many files will go
into it when you create it. Perhaps I'm mistaken about (1)? Frank
somebody from WSMR was our source of info on TOPS-20.
> (although granted, TOPS-20 does not exist *now* except in Mark Crispin's
> basement...)
CompuServe and White Sands both canned theirs?
> For example, are there other kinds of directory organizations that are more
> complex than a simple tree?
I'm not aware of any (unless you think of VMS indexed-whatever files as
a weird kind of directory system). There can be extra attributes associated
with directories, but zipfiles (can) store directories as separate entries
with separate "resource forks" of essentially arbitrary size.
Greg
27-Aug-96 22:49:14-GMT,1948;000000000001
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id SAA25251 for <fdc@watsun.cc.columbia.edu>; Tue, 27 Aug 1996 18:49:13 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id RAA11228; Tue, 27 Aug 1996 17:46:02 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id RAA06017; Tue, 27 Aug 1996 17:46:43 -0500 (CDT)
> Absolutely, at least for most operating systems. Personally, I think it would
> be interesting to design a new file system in which files could be tagged as
> text or binary -- by the application that created them, and also (as an
> override) by their (human) owners. When files were text, I think it would
> also be a great boon to humankind if they could be tagged as to the character
> set of encoding. To my knowledge, no file system has ever provided such a
> service in the file system itself. "Binary" would mean, simply, that if the
> file is to be transferred to another computer, no conversions should be done.
> Conversely, "text" would mean that record-format and character-set conversions
> should be done.
Amen. Please feel free to design it, patent it, sell it, whatever it takes.
That would be a dream file system for Zip/UnZip.
> On the other hand, I have seen Intel
> executables composed of only printable ASCII characters. (We have one in the
> Kermit archives somewhere but I can't put my finger on it at the moment...)
Uuencode. It's distributed as part of the c.b.i.p starter kit regularly
(or formerly regularly). Very cute.
Greg
28-Aug-96 5:52:44-GMT,2136;000000000011
Received: from ars.de (firewall.ars.de [194.97.120.113]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id BAA26458 for <fdc@WATSUN.CC.COLUMBIA.EDU>; Wed, 28 Aug 1996 01:52:43 -0400 (EDT)
Received: from jonas.ars.de by ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
id AA0151; Wed, 28 Aug 96 07:51:07 +0200
Received: by internal-host.ars.de (IBM OS/2 SENDMAIL VERSION 1.3.17/3.0ars)
> I would vote for making binary the default for ALL platforms.
>
Surely not IBM mainframes? :-)
Seriously, this has been proposed many times, and it makes more sense now
than before. But in our limited experience with Kermit 95's new binary-mode
default, we are seeing new problems. A common example is when people export
application (word processor, spreadsheet, database) files for transfer, and
then can't import them again because the records are in the wrong format.
Or they can import them, but the accented/non-Roman characters are wrong.
So, with the stupid file systems that are in use today -- and I maintain that
ALL of them are stupid -- indeed you can't win. (Perhaps "stupid" is not the
right word -- the idea has always been more one of locking people in to a
particular environment, rather than promoting diversity and interchange.)
- Frank
P.S. MS-DOS Kermit 3.15, C-Kermit 6.0, and IBM Mainframe Kermit 4.2.2 have a
new feature which, at least, lets the two Kermit programs recognize that they
are running on "like" computers (if they are) and therefore to switch into
binary mode automatically, even if their default transfer mode is text. So
this should go a long way towards satisfying many people. In this regard,
Kermit has an advantage over ZIP programs, because ZIP programs never know
where the ZIP file might be unzipped.
28-Aug-96 16:37:52-GMT,1481;000000000001
Received: from barney.usu.edu (barney.usu.edu [129.123.1.89]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id MAA23445 for <fdc@watsun.cc.columbia.edu>; Wed, 28 Aug 1996 12:37:51 -0400 (EDT)
Received: from cc.usu.edu by cc.usu.edu (PMDF V5.0-5 #11556)
id <01I8T13PB1T2CE2UCT@cc.usu.edu>; Wed, 28 Aug 1996 10:37:37 -0600 (MDT)
I remain surprized at the "text mode" bias in all this thinking.
That is, presuming that binary also means "stream of bytes." That's naive.
Anyone heard of byte order of numerical quantities? Have a look at the
ponderous NFS RPC material to see the trouble one gets into trying to
describe information, and that stuff covers only the easy items.
Binary simply isn't transportable between unlike systems, in
general, because the systems differ in representation. Big/little
endian, for example, not to mention "word" size.
Those fixating on byte stream should not get into this game.
Joe D.
28-Aug-96 18:11:45-GMT,3722;000000000011
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA08199 for <fdc@watsun.cc.columbia.edu>; Wed, 28 Aug 1996 14:11:42 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id NAA11827; Wed, 28 Aug 1996 13:10:39 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA04942; Wed, 28 Aug 1996 13:12:49 -0500 (CDT)
> Yes, Wancho. Huh...wonder why he punted on the file-system info. I
> *know* he claimed you had to know the directory size at creation time.
> But, as you say, it's irrelevant. I guess there's no point in hanging
> onto the partial TOPS-20 support in UnZip, either.
>
Nevertheless, I always thought it would be a cool idea to have a "virtual
museum" on the Internet, where people could see some of the old and
influential operating systems -- TOPS-10, TOPS-20, MULTICS, ITS, etc. (Even
RT-11, which CP/M and DOS were largely copied from :-)
Obviously impractical given the expense involved of maintaining the hardware,
let alone the access and security problems it would raise. But an awful lot
of good ideas have gone out the window and soon nobody will remember anything
but MS Windows, and will think that is the definition of an operating system.
In my recent "travels", I've come across a few real gems that are still up and
running that will disappear forever the next time the hardware breaks because
nobody wants to pay to keep them going. For example, just for the perverse
heck of it, I ported C-Kermit (and I use "port" in the real sense of doing a
lot of work, not the vulgar sense of "recompiling" :-) to Bell Research UNIX
V10, which I guarantee no more than two people in the world are still using.
> Au contraire! You're right that Zip doesn't know where it will be
> unzipped, but UnZip knows where it was zipped, and that amounts to the
> same thing. (Indeed, that fact is the sole reason I took the steps that
> eventually led to my leadership of the UnZip project six years ago...)
>
Ah, great minds...
> I've removed zip-bugs from the recipient list since this has become
> largely an academic exercise in nitpicking. :-)
>
No, it's just having a little fun -- something increasingly hard to come by
these days...
- Frank
28-Aug-96 18:57:36-GMT,2575;000000000001
Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id OAA15730 for <fdc@watsun.cc.columbia.edu>; Wed, 28 Aug 1996 14:57:35 -0400 (EDT)
Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id NAA14460 for <fdc@watsun.cc.columbia.edu>; Wed, 28 Aug 1996 13:56:42 -0500 (CDT)
Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id NAA09091; Wed, 28 Aug 1996 13:58:53 -0500 (CDT)
