26-Aug-96 20:22:00-GMT,4423;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id QAA04898; Mon, 26 Aug 1996 16:21:59 -0400 (EDT) Date: Mon, 26 Aug 96 16:21:59 EDT From: Frank da Cruz To: jaltman@columbia.edu cc: Kai Uwe Rommel , Joe Doupnik , John Chandler Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Mon, 26 Aug 96 10:33:41 EDT Message-ID: > > 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 ; 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) id AA0489; Tue, 27 Aug 96 16:31:00 +0200 Message-Id: <9608271431.AA0489@internal-host.ars.de> Date: Tue, 27 Aug 96 16:30:59 +0100 From: Kai Uwe Rommel Subject: Re: Info-ZIP and C-Kermit To: Zip-Bugs@LISTS.WKU.EDU, fdc@WATSUN.CC.COLUMBIA.EDU In-Reply-To: from "Frank da Cruz" at Aug 26 96 4:21 pm X-Mailer: ELM [version 2.3 PL11] for OS/2 You (Frank da Cruz) wrote: > Thanks, Kai Uwe (and hello :-) Hi! > 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). My personal opinion is: DON'T DO text mode transmissin/conversion. Leave everything as is. Those who have to transfer texts between systems with different representations of text files know how to deal with that "problem". > In DOS and Windows, I suppose we could go by filetype (e.g. ".TXT" is text), > but of course it is not reliable. For example, german versions of Microsoft Word 5 used the extension .TXT instead of .DOC for their (binary) document files. > 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. I agree. Kai Uwe -- /* Kai Uwe Rommel ARS Computer & Consulting GmbH, Muenchen, Germany * * rommel@ars.de CompuServe 100265,2651, Fax +49 89 324 4524 * * rommel@leo.org (ftp://ftp.leo.org/pub/comp/os/os2 maintenance) */ 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 ; 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) Date: Tue, 27 Aug 1996 13:26:17 -0500 (CDT) From: Cave Newt Message-Id: <199608271826.NAA06405@ellis.uchicago.edu> 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 ; 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) Date: Tue, 27 Aug 1996 12:43:37 -0600 (MDT) From: Joe Doupnik Subject: Re: Info-ZIP and C-Kermit To: ROE2@MIDWAY.UCHICAGO.EDU Cc: ZIP-BUGS@LISTS.WKU.EDU, FDC@WATSUN.CC.COLUMBIA.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU Message-id: <01I8RR0YMESICE2FIO@cc.usu.edu> X-VMS-To: ROE2@MIDWAY.UCHICAGO.EDU X-VMS-Cc: ZIP-BUGS@LISTS.WKU.EDU,FDC@WATSUN.CC.COLUMBIA.EDU,JCHBN@CUVMB.CC.COLUMBIA.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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. Joe D. 27-Aug-96 18:54:37-GMT,4069;000000000000 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id OAA03531; Tue, 27 Aug 1996 14:50:13 -0400 (EDT) Date: Tue, 27 Aug 96 14:50:12 EDT From: Frank da Cruz To: Cave Newt Cc: Zip-Bugs@LISTS.WKU.EDU, jaltman@columbia.edu, JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Tue, 27 Aug 1996 13:26:17 -0500 (CDT) Message-ID: > 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. > But even if it tries (and misses sometimes) in the DOS/Windows environment, what about UNIX, OS-9, QNX, AOS/VS, VOS, VM/CMS, MVS/TSO, CICS, RT-11, ... ? There is no way on earth to embody all that knowledge in one piece of software. And then add in the fact that you might be looking at foreign files rather than domestic ones. It's hopeless with any degree of reliability. (In the latest version of C-Kermit, we let the user build lists of files to be transferred -- the list can be any length at all, and each member of the list can be tagged as binary or text.) > > 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... > Exactly the point -- if you assume text, you corrupt the binary files; if you assume binary, you corrupt the text files. Kermit 95, by the way, uses binary by default, since most Windows users are transferring only ZIP, GIF, or JPG files. But the real issue is what to do about a mixture of file types. 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. > 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 > Hey! TOPS-20 was just like VMS. Nonexistent would be HP-1000 or OS/360 :-) (although granted, TOPS-20 does not exist *now* except in Mark Crispin's basement...) > and have to deal with all sorts of translations, truncations and name- > collisions. One way or the other, user input is necessary then. > Right. That's why this is such a hard problem -- and why we've been putting it off for so long :-) Maybe the UNIX model is adequate in the sense it is a superset of all others, but I haven't done a broad enough study to reach that conclusion yet. For example, are there other kinds of directory organizations that are more complex than a simple tree? Certainly there are file organizations that are WAY more complex than a stream. - Frank 27-Aug-96 19:01:41-GMT,2345;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id PAA07527; Tue, 27 Aug 1996 15:00:52 -0400 (EDT) Date: Tue, 27 Aug 96 15:00:52 EDT From: Frank da Cruz To: Joe Doupnik Cc: ROE2@MIDWAY.UCHICAGO.EDU, ZIP-BUGS@LISTS.WKU.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Tue, 27 Aug 1996 12:43:37 -0600 (MDT) Message-ID: > 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 ; 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) id AA0489; Tue, 27 Aug 96 16:31:00 +0200 Message-Id: <9608271431.AA0489@internal-host.ars.de> Date: Tue, 27 Aug 96 16:30:59 +0100 From: Kai Uwe Rommel Subject: Re: Info-ZIP and C-Kermit To: Zip-Bugs@LISTS.WKU.EDU, fdc@WATSUN.CC.COLUMBIA.EDU In-Reply-To: from "Frank da Cruz" at Aug 26 96 4:21 pm X-Mailer: ELM [version 2.3 PL11] for OS/2 You (Frank da Cruz) wrote: > Thanks, Kai Uwe (and hello :-) Hi! > 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). My personal opinion is: DON'T DO text mode transmissin/conversion. Leave everything as is. Those who have to transfer texts between systems with different representations of text files know how to deal with that "problem". > In DOS and Windows, I suppose we could go by filetype (e.g. ".TXT" is text), > but of course it is not reliable. For example, german versions of Microsoft Word 5 used the extension .TXT instead of .DOC for their (binary) document files. > 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. I agree. Kai Uwe -- /* Kai Uwe Rommel ARS Computer & Consulting GmbH, Muenchen, Germany * * rommel@ars.de CompuServe 100265,2651, Fax +49 89 324 4524 * * rommel@leo.org (ftp://ftp.leo.org/pub/comp/os/os2 maintenance) */ 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 ; 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) Date: Tue, 27 Aug 1996 13:26:17 -0500 (CDT) From: Cave Newt Message-Id: <199608271826.NAA06405@ellis.uchicago.edu> 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 ; 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) Date: Tue, 27 Aug 1996 12:43:37 -0600 (MDT) From: Joe Doupnik Subject: Re: Info-ZIP and C-Kermit To: ROE2@MIDWAY.UCHICAGO.EDU Cc: ZIP-BUGS@LISTS.WKU.EDU, FDC@WATSUN.CC.COLUMBIA.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU Message-id: <01I8RR0YMESICE2FIO@cc.usu.edu> X-VMS-To: ROE2@MIDWAY.UCHICAGO.EDU X-VMS-Cc: ZIP-BUGS@LISTS.WKU.EDU,FDC@WATSUN.CC.COLUMBIA.EDU,JCHBN@CUVMB.CC.COLUMBIA.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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. Joe D. 27-Aug-96 18:54:37-GMT,4069;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id OAA03531; Tue, 27 Aug 1996 14:50:13 -0400 (EDT) Date: Tue, 27 Aug 96 14:50:12 EDT From: Frank da Cruz To: Cave Newt Cc: Zip-Bugs@LISTS.WKU.EDU, jaltman@columbia.edu, JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Tue, 27 Aug 1996 13:26:17 -0500 (CDT) Message-ID: > 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. > But even if it tries (and misses sometimes) in the DOS/Windows environment, what about UNIX, OS-9, QNX, AOS/VS, VOS, VM/CMS, MVS/TSO, CICS, RT-11, ... ? There is no way on earth to embody all that knowledge in one piece of software. And then add in the fact that you might be looking at foreign files rather than domestic ones. It's hopeless with any degree of reliability. (In the latest version of C-Kermit, we let the user build lists of files to be transferred -- the list can be any length at all, and each member of the list can be tagged as binary or text.) > > 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... > Exactly the point -- if you assume text, you corrupt the binary files; if you assume binary, you corrupt the text files. Kermit 95, by the way, uses binary by default, since most Windows users are transferring only ZIP, GIF, or JPG files. But the real issue is what to do about a mixture of file types. 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. > 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 > Hey! TOPS-20 was just like VMS. Nonexistent would be HP-1000 or OS/360 :-) (although granted, TOPS-20 does not exist *now* except in Mark Crispin's basement...) > and have to deal with all sorts of translations, truncations and name- > collisions. One way or the other, user input is necessary then. > Right. That's why this is such a hard problem -- and why we've been putting it off for so long :-) Maybe the UNIX model is adequate in the sense it is a superset of all others, but I haven't done a broad enough study to reach that conclusion yet. For example, are there other kinds of directory organizations that are more complex than a simple tree? Certainly there are file organizations that are WAY more complex than a stream. - Frank 27-Aug-96 19:01:41-GMT,2345;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id PAA07527; Tue, 27 Aug 1996 15:00:52 -0400 (EDT) Date: Tue, 27 Aug 96 15:00:52 EDT From: Frank da Cruz To: Joe Doupnik Cc: ROE2@MIDWAY.UCHICAGO.EDU, ZIP-BUGS@LISTS.WKU.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Tue, 27 Aug 1996 12:43:37 -0600 (MDT) Message-ID: > 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 ; 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) Date: Tue, 27 Aug 1996 17:31:32 -0500 (CDT) From: Cave Newt Message-Id: <199608272231.RAA04577@ellis.uchicago.edu> To: JRD@cc.usu.edu, fdc@watsun.cc.columbia.edu Subject: Re: Info-ZIP and C-Kermit Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, zip-bugs@lists.wku.edu [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 ; 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) Date: Tue, 27 Aug 1996 17:46:43 -0500 (CDT) From: Cave Newt Message-Id: <199608272246.RAA06017@ellis.uchicago.edu> To: JRD@cc.usu.edu, fdc@watsun.cc.columbia.edu Subject: Re: Info-ZIP and C-Kermit Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, zip-bugs@lists.wku.edu > 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 ; 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) id AA1296; Wed, 28 Aug 96 07:51:05 +0200 Message-Id: <9608280551.AA1296@internal-host.ars.de> Date: Wed, 28 Aug 96 7:51:04 +0100 From: Kai Uwe Rommel Subject: Re: Info-ZIP and C-Kermit To: fdc@WATSUN.CC.COLUMBIA.EDU Cc: roe2@midway.uchicago.edu, Zip-Bugs@LISTS.WKU.EDU, jaltman@columbia.edu, JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu In-Reply-To: from "Frank da Cruz" at Aug 27 96 2:50 pm X-Mailer: ELM [version 2.3 PL11] for OS/2 You (Frank da Cruz) wrote: > > > 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... > > > Exactly the point -- if you assume text, you corrupt the binary files; if you > assume binary, you corrupt the text files. I beg to differ. If you assume binary, you do _not_ corrupt the text files. You just don't convert them, leaving this extra step to the user (and extra tools). > Kermit 95, by the way, uses binary > by default, since most Windows users are transferring only ZIP, GIF, or JPG > files. I would vote for making binary the default for ALL platforms. Kai Uwe -- /* Kai Uwe Rommel ARS Computer & Consulting GmbH, Muenchen, Germany * * rommel@ars.de CompuServe 100265,2651, Fax +49 89 324 4524 * * rommel@leo.org (ftp://ftp.leo.org/pub/comp/os/os2 maintenance) */ DOS ... is still a real mode only non-reentrant interrupt handler, and always will be. -Russell Williams 28-Aug-96 15:46:31-GMT,1886;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id LAA15123; Wed, 28 Aug 1996 11:46:00 -0400 (EDT) Date: Wed, 28 Aug 96 11:46:00 EDT From: Frank da Cruz To: Kai Uwe Rommel Cc: roe2@midway.uchicago.edu, Zip-Bugs@LISTS.WKU.EDU, jaltman@columbia.edu, JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Wed, 28 Aug 96 7:51:04 +0100 Message-ID: > 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 ; 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) Date: Wed, 28 Aug 1996 10:37:37 -0600 (MDT) From: Joe Doupnik Subject: Re: Info-ZIP and C-Kermit To: fdc@watsun.cc.columbia.edu Cc: ROE2@MIDWAY.UCHICAGO.EDU, JCHBN@CUVMB.CC.COLUMBIA.EDU, ZIPS-BUGS@LISTS.WKU.EDU, JALTMAN@COLUMBIA.EDU Message-id: <01I8T13PB2RCCE2UCT@cc.usu.edu> X-VMS-To: IN%"fdc@watsun.cc.columbia.edu" X-VMS-Cc: ROE2@MIDWAY.UCHICAGO.EDU,JCHBN@CUVMB.CC.COLUMBIA.EDU,ZIPS-BUGS@LISTS.WKU.EDU,JALTMAN@COLUMBIA.EDU,JRD MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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 ; 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) Date: Wed, 28 Aug 1996 13:12:49 -0500 (CDT) From: Cave Newt Message-Id: <199608281812.NAA04942@ellis.uchicago.edu> To: fdc@watsun.cc.columbia.edu Subject: Re: Info-ZIP and C-Kermit Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu, rommel@ars.de Frank wrote: > Any Kermit program can have its default transfer mode be binary -- the user > just puts a "set file type binary" command in her/his initialization file; or > the site puts one in the site-wide initialization file. Kermit is totally > (and almost infinitely) customizable. And you accuse *me* of a developer's bias? :-) * 0.5 > Not with Kermit. Kermit is an extremely common method of accessing Linux, > and it can easily be adjusted to either case. I was wrong anyway. Linux uses a Latin-1 code page even for its virtual consoles (which should have been obvious, given its origins). > Frank Wancho? (I managed TOPS-20 systems for about 10 years.) 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. > But then do you have a standard and transportable way of mapping complex > structural information between unlike systems? No, of course not, but at least you can transport it and recreate it on like systems. > No matter; this discussion is mostly academic -- I don't see us going anywhere > with it for a while, and by that time, maybe ALL file systems will have > devolved to the simple DOS/UNIX model and then we won't have to worry about it > any more, except for deep questions like how to turn backslashes around :-) One can only hope (or fear)... :-) > 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. 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...) Joe wrote: > 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. That's only true for poorly designed binary file formats. There's really no reason for any format designed since 1985 not to specify precisely what byte order is used and what each of the field sizes is. This is true even for formats that may use different sizes and byte orders on each platform for maximum I/O efficiency; there's no excuse for not including a fixed, well-defined header that specifies the key parameters of the rest of the file. FORTRAN binary files are a prime example of how *not* to do it. For non-stream things like VMS database file formats, there's inherently no portability, so it's not so much an issue there. Greg P.S. I've removed zip-bugs from the recipient list since this has become largely an academic exercise in nitpicking. :-) 28-Aug-96 18:26:12-GMT,2336;000000000001 Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id OAA09997; Wed, 28 Aug 1996 14:25:19 -0400 (EDT) Date: Wed, 28 Aug 96 14:25:18 EDT From: Frank da Cruz To: Cave Newt Cc: JCHBN@CUVMB.CC.COLUMBIA.EDU, JRD@cc.usu.edu, rommel@ars.de Subject: Re: Info-ZIP and C-Kermit In-Reply-To: Your message of Wed, 28 Aug 1996 13:12:49 -0500 (CDT) Message-ID: > 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 ; 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 ; 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) Date: Wed, 28 Aug 1996 13:58:53 -0500 (CDT) From: Cave Newt Message-Id: <199608281858.NAA09091@ellis.uchicago.edu> To: fdc@watsun.cc.columbia.edu Subject: Re: Info-ZIP and C-Kermit Frank, > 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 :-) Hey, I used RT-11 on a 1978-vintage Terak (PDP8-based, I think) in college! 8-inch diskettes, funky screen with separate text and graphics memory, and a random-access Diablo daisy-wheel printer that we used to create six-foot- long traces of magnetospheric phenomena. It had 64KB (32KW) of RAM, as I recall, and was quite a step up from the 8KB Commodore PETs we had in high school... Amazingly enough, they *still* had Teraks in use at NASA Ames ca. 1991. > 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. Shudder... > 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. Ooo, I'd love to take a crack at UnZip on a system like that. :-) (Well, maybe not. It's not like there aren't a billion other projects waiting for me.) > Ah, great minds... Or at least Dilbert-like ones... > No, it's just having a little fun -- something increasingly hard to come by > these days... Ah, but I and many of the luna^H^H^H^Hengineers with whom I associate *equate* academic nitpicking with fun--consider this sentence, for example. ;-) Regards, Greg