pete@eleazar.dartmouth.edu (Peter Schmitt) (07/20/89)
I am having trouble compiling the recent posting of flip on my pc with TC 1.5. Here is a script of the session. Maybe someone can point me in the right direction. Script V1.0 session started Thu Jul 20 03:43:07 1989 C>ndmake -f makefile.tcc tcc -c -DTURBOC -DLINT -DNDEBUG flip.c Turbo C Version 1.5 Copyright (c) 1987 Borland International flip.c: Warning flip.c 451: Call to function 'signal' with no prototype in function setup_sigs Warning flip.c 451: Non-portable pointer comparison in function setup_sigs Warning flip.c 452: Call to function 'signal' with no prototype in function setup_sigs Warning flip.c 455: Call to function 'signal' with no prototype in function setup_sigs Warning flip.c 455: Non-portable pointer comparison in function setup_sigs Warning flip.c 456: Call to function 'signal' with no prototype in function setup_sigs Warning flip.c 464: Call to function 'signal' with no prototype in function cleanup Warning flip.c 466: Call to function 'signal' with no prototype in function cleanup Available memory 178944 tcc -c -DTURBOC -DLINT -DNDEBUG getopt.c Turbo C Version 1.5 Copyright (c) 1987 Borland International getopt.c: Available memory 197508 tcc -c -DTURBOC -DLINT -DNDEBUG turboc.c Turbo C Version 1.5 Copyright (c) 1987 Borland International turboc.c: Warning turboc.c 272: Call to function 'signal' with no prototype in function MVFILE Warning turboc.c 272: Non-portable pointer assignment in function MVFILE Warning turboc.c 291: Call to function 'signal' with no prototype in function MVFILE Warning turboc.c 299: Call to function 'signal' with no prototype in function MVFILE Warning turboc.c 305: Call to function 'signal' with no prototype in function handler Warning turboc.c 309: Call to function 'signal' with no prototype in function handler Warning turboc.c 310: Call to function 'raise' with no prototype in function handler Available memory 193898 tcc -eFLIP flip.obj getopt.obj turboc.obj Turbo C Version 1.5 Copyright (c) 1987 Borland International Turbo Link Version 1.1 Copyright (c) 1987 Borland International Undefined symbol '_signal' in module flip.c Undefined symbol '_signal' in module flip.c Undefined symbol '_signal' in module flip.c Undefined symbol '_signal' in module flip.c Undefined symbol '_signal' in module flip.c Undefined symbol '_signal' in module flip.c Undefined symbol '_raise' in module turboc.c Undefined symbol '_signal' in module turboc.c Undefined symbol '_signal' in module turboc.c Undefined symbol '_signal' in module turboc.c Undefined symbol '_signal' in module turboc.c Undefined symbol '_signal' in module turboc.c Available memory 231044 *** Error code 1 C>exit Script completed Thu Jul 20 03:44:05 1989 Peter R. Schmitt - UNIX User Services Consultant - Peter.Schmitt@dartmouth.edu There are two fundamental facts of human enlightenment: #1, There is a God. #2, You are not Him!
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/20/89)
In article <14517@dartvax.Dartmouth.EDU> pete@eleazar.dartmouth.edu (Peter Schmitt) writes: > >I am having trouble compiling the recent posting of flip on >my pc with TC 1.5. Here is a script of the session. Maybe >someone can point me in the right direction. >Undefined symbol '_signal' in module flip.c I went from TC 1.0 to TC 2.0 without spending any time on the cross with TC 1.5. As I remember, for some totally (pardon the technical jargon) TOTALLY HALF-ASSED REASON, signal was actually csignal or something. This was one of a number of TOTALLY HALF-ASSED, deviations from **IX (with NO GOOD OR BAD REASON) "features" of TC 1.0 and 1.5 which, in testimony to their original brilliance and utility, were ELIMINATED with TC 2.0. While I'm on the soapbox, let me note that before I bought TC, I bought a number of magazines and read a number of reviews of it. NOT ONE REVIEW noted any of the BRAIN-DEAD FEATURES of TC 1.0/1.5 (I can say they were brain-dead with certainity because they were eliminated in TC 2.0), most of which were stupid, arbitrary deviations from **IX norms. All the reviews I read focused on compile/execution speed. As it turned out I wasted more time tracking down BRAIN-DEAD differences between **IX and MSDOS conventions (changed to **IX forms in TC 2.0) than I saved by the faster compile times of TC 1.0. From this, I concluded that magazine reviews are only useful eliminating in TOTAL DUDS. If the program trashes the reviewer's hard disk AND causes a fire on the mother board AND if the product comes from a company that does not advertise too heavily in the magazine in question, it ~might~ get an unfavorable review. The original TC 1.0 had more bugs than raw meat in a third world bazaar, but NOT one review I read discovered that, for example, TC 1.0 floating point was more flakey than old paint on a brick wall. TO MAKE A DIATRIBE SHORT. Look at <signal.h>. You'll probably not find a definition for signal(). It'll be called something else. That's most of your problem; the rest is in the parameters. Beg, borrow, or steal TC 2.0. It's (almost) good! Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
Ralf.Brown@B.GP.CS.CMU.EDU (07/20/89)
In article <26514@agate.BERKELEY.EDU>, ked@garnet.berkeley.edu (Earl H. Kinmonth) wrote: }In article <14517@dartvax.Dartmouth.EDU> pete@eleazar.dartmouth.edu (Peter Schmitt) writes: }TC 1.5. As I remember, for some totally (pardon the technical jargon) }TOTALLY HALF-ASSED REASON, signal was actually csignal or something. ssignal() and gsignal() instead of signal() and raise(). }This was one of a number of TOTALLY HALF-ASSED, deviations from **IX }(with NO GOOD OR BAD REASON) "features" of TC 1.0 and 1.5 which, in }testimony to their original brilliance and utility, were ELIMINATED with }TC 2.0. I believe ssignal and gsignal are from a very early version of Un*x (V6?). }The original TC 1.0 had more bugs than raw meat in a third world bazaar, }but NOT one review I read discovered that, for example, TC 1.0 floating }point was more flakey than old paint on a brick wall. If you thought TC 1.0 was bad, I shudder to think what you would have thought of MSC 4.0, MSC 5.0, MASM 2.0, MASM 3.0, MASM 4.0, DOS 4.00, etc. At least Borland provides patches, rather than forcing you to wait for (and then buy!) the next release. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? PROGRAM n. A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunies for reward. -- from a flyer advertising for _Inside_Turbo_Pascal_
bobmon@iuvax.cs.indiana.edu (RAMontante) (07/21/89)
Turbo C v1.5 did/does not support signals as such. Support for that was added with v2.0. Rahul Dhesi posted a signals package for v1.5 that may/should provide what you need. It should be in simtel20 archives. In (lukewarm) defense of v1.0/v1.5, much of the missing stuff (such as signals) was stuff that makes little sense in a single-tasking environment. TC's target market, and the reviewers' readers, were not primarily UNIX gurus slumming on the toy machines, but people who lived exclusively in the MSDOS world --- and perhaps starting to get dissatisfied with BASICA. Of course, I personally want TC to look as UNIX-like as possible, so I can port stuff. But then, the MSDOS environment is the bottleneck there anyway...
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/21/89)
In article <23591@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >Turbo C v1.5 did/does not support signals as such. No, but it did have a signal() style function named, for no apparent reason, ssignal(). This is a classic case of, IF YOU'RE GOING TO DO IT, DO IT RIGHT, OR DON'T DO IT AT ALL. This is just close enough to UNIX practice (the documentation even claims "available on UNIX systems") to invite the expectation of compatability, when in fact, the function is about as useful as the proverbial "teats on a boar hog." >In (lukewarm) defense of v1.0/v1.5, much of the missing stuff (such as >signals) was stuff that makes little sense in a single-tasking >environment. TC's target market, and the reviewers' readers, were not >primarily UNIX gurus slumming on the toy machines, but people who lived >exclusively in the MSDOS world --- and perhaps starting to get >dissatisfied with BASICA. I don't buy this. Throughout the Turbo C manual, "UNIX" is the clear standard. Almost every function contains a note explaining the degree to which a given function conforms or does not conform to "UNIX" standards. The problem is that whoever wrote these must have been using a version of "UNIX" distributed by K-Mart. The notes are usually wrong, incomplete, or indicate conformity with a version of UNIX that has .001 percent of the market. It is understandable why magazine reviewers did not catch this. MSDOS reviewers are almost as parochial as MAC-types. Nevertheless, one of the selling points of C is PORTABILITY, indeed, a cynic (but not me) might even say that is the ONLY attraction of C. Therefore, some test of portability should be included in any review. Moreover, since Turbo C was entering a market where, to a large degree, Microsoft C was the standard, and since Microsoft C is/was more **IX compatible, Turbo C should have been judged against MSC on this point too. Finally, there is in my own mind, absolutely no excuse for reviewers of TC 1.0 to have NOT discovered the many bugs in floating point operations, in the larger memory models, etc. I had to try only one or two programs to find bugs, and I'm an historian, not a programmer!!!!! >Of course, I personally want TC to look as UNIX-like as possible, so I >can port stuff. But then, the MSDOS environment is the bottleneck there >anyway... Perhaps, but my experience has been somewhat different. I've ported Bibliofile, my freeform data base UNIX PDP-11/70 --> Xenix --> BSD --> Ultrix --> MSDOS. In porting to MSDOS, the only real hassle from MSDOS itself was file name expansion. All of the other hassles came from bugs in TC 1.0. With TC 2.0, I was able to dispense with several hundred lines of assembler and countless #ifdef statements. Lest all of this be misinterpreted, I would note that I also purchased Quick C (Microsoft) when it appeared. Talk about brain-dead design!!!!! As far as I'm concerned, anyone who purchased QC ought to get an IRS credit for making a contribution to an institution for the developmentally disabled. Maybe it's improved, but with all its bugs, TC 1.0 was good enough that I bought TC 2.0. When I received my discount coupon for the second generation of QC, my instinctive reaction was to place it in the circular file. Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
ho@fergvax.unl.edu (Tiny Bubbles...) (07/22/89)
From article <26514@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): > of your problem; the rest is in the parameters. Beg, borrow, or steal > TC 2.0. It's (almost) good! What would you consider a (not almost, but actually) good PC C compiler? I had TC 1.5. The only deviations I noticed from **IX were the maddening ssignal(), and a few machine-specific things (replacing opendir/readdir with findfirst/findnext, totally different ioctl, etc.) things that most likely could not have been easily fixed. I have TC 2.0 now. The thing I hate most about it is the memory model fiasco, and that is inherent in ANY PC compiler. You just can't evade it, unless you want to have one memory model (huge) and leave it at that. > Earl H. Kinmonth > History Department > University of California, Davis > 916-752-1636 (voice, fax [2300-0800 PDT]) > 916-752-0776 secretary --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>
mju@mudos.ann-arbor.mi.us (Marc Unangst) (07/22/89)
In article <26557@agate.BERKELEY.EDU>, ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: [TC 1.0 and 1.5 ssignal()/gsignal() vs Unix signal()/raise()] >No, but it did have a signal() style function named, for no apparent >reason, ssignal(). This is a classic case of, IF YOU'RE GOING TO DO IT, >DO IT RIGHT, OR DON'T DO IT AT ALL. This is just close enough to UNIX >practice (the documentation even claims "available on UNIX systems") to >invite the expectation of compatability, when in fact, the function is >about as useful as the proverbial "teats on a boar hog." >[...] >Finally, there is in my own mind, absolutely no excuse for reviewers of >TC 1.0 to have NOT discovered the many bugs in floating point >operations, in the larger memory models, etc. I had to try only one or >two programs to find bugs, and I'm an historian, not a programmer!!!!! I'm going to take some time with you, Earl, because it seems that you have the intelligence to comprehend what I'm going to say. Do you know what a version number means? Do you know what it means when a company releases a revision to a program, and says "this-and-this bug was fixed"? It means that there was a bug in the original release. And they've fixed it in the new release. Now, if your programs don't compile or run correctly with the bug, do you know what you do? You buy (or upgrade to) the new version. You don't sit around and bitch about how bad the old version was, or complain about the bug (that has been fixed). Now, admittedly, Borland probably should have tested TC 1.0 a little more thoroughly before unleashing it on the unsuspecting public. However, if you looked through the manual, tried compiling a few programs, and discovered the bugs in the compiler -- I'm sure that Borland would have been willing to either send you a fix or take back your compiler. However, sitting around, *after the bug has been fixed*, and complaining about it, doesn't do anybody any good. Why is it that, when a user has trouble with a PD/freeware/shareware program, they are always told to upgrade to the most recent version... But when a user has trouble with a piece of commercial software, they just sit around and flame away, even though their copy is several versions out of date? Followups directed to alt.flame, where they belong. -- Marc Unangst UUCP smart : mju@mudos.ann-arbor.mi.us UUCP dumb : ...!uunet!sharkey!mudos!mju UUCP dumb alt.: ...!{ames,rutgers}!mailrus!clip!mudos!mju Internet : mju@mudos.ann-arbor.mi.us
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/22/89)
In article <1105@unocss.UUCP> ho@fergvax.unl.edu writes: >From article <26514@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >> of your problem; the rest is in the parameters. Beg, borrow, or steal >> TC 2.0. It's (almost) good! > >What would you consider a (not almost, but actually) good PC C compiler? One that allowed larger programs to be debugged. >I had TC 1.5. The only deviations I noticed from **IX were the maddening >ssignal(), and a few machine-specific things (replacing opendir/readdir >with findfirst/findnext, totally different ioctl, etc.) things that >most likely could not have been easily fixed. There is more than that. I spend hours writing a decent system() function that recognizes SHELL, COMSPEC, and the current setting of the switchar. utime() and a number of other **IX functions available in MSC were not and still are not part of the Turbo C library. getenv() and chdir() were buggy in the initial version as were a number of other routines. I almost forgot the biggest pisser of all, the inability of TC 2.0 to work with lines terminated only by line-feeds, and worse yet, the failure to detect this problem in many cases. (TC 1.0 actually worked in this case.) Before you respond that CR/LF is the MSDOS convention and TC is a MSDOS compiler, let me give you my rebuttal. First, LF lines did work in TC 1.0. Second, it takes MORE code to require the CR/LF than not to. Third, since a major selling point of C is portability, TC should not make moving code anymore difficult than is required by the underlying platform.
ralf@b.gp.cs.cmu.edu (Ralf Brown) (07/23/89)
In article <26586@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: }I almost forgot the biggest pisser of all, the inability of TC 2.0 to }work with lines terminated only by line-feeds, and worse yet, the }failure to detect this problem in many cases. (TC 1.0 actually worked }in this case.) TC 2.0 *almost* works with LF-only lines. Seems that only the preprocessor command-recognizer fails.... (i.e. an #ifdef will get you a complaint about a missing #endif, but a file without conditional compilation compiles correctly). I do agree that this is an annoying problem. Unless I misremember, TC 1.5 was the same as 2.0. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did |"Let both sides invoke the wonders of science instead of I claim something?| the terrors." --John F. Kennedy
ho@fergvax.unl.edu (07/24/89)
From article <26586@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >>What would you consider a (not almost, but actually) good PC C compiler? > > One that allowed larger programs to be debugged. I was looking for the name of a compiler which was better than Turbo C. > utime() and a number of other **IX functions available in MSC were not > and still are not part of the Turbo C library. You're right -- the lack of utime() has actually bothered me... I had to find some non-standard function to cover it. It would be fairly simple to write a utime() function, but why it wasn't included, I don't know. > I almost forgot the biggest pisser of all, the inability of TC 2.0 to > work with lines terminated only by line-feeds, and worse yet, the > failure to detect this problem in many cases. (TC 1.0 actually worked > in this case.) > > Before you respond that CR/LF is the MSDOS convention and TC is a MSDOS > compiler, let me give you my rebuttal. First, LF lines did work in TC > 1.0. Second, it takes MORE code to require the CR/LF than not to. > Third, since a major selling point of C is portability, TC should not > make moving code anymore difficult than is required by the underlying > platform. I'm not happy with some of the design decisions behind MSDOS either (e.g., the CRLF instead of NL). But given that I have to work with them, I don't see any reason why the CRLF vs. LF problem should even be a problem. Changing NL's to CRLF's is the responsibility of the transporting program, be that ftp, xmodem, or rz/sz, IMHO. It should not be the responsibility of the application program to recognize a file which was improperly transported across environments. (If you can't TYPE the file properly, why should Turbo C be expected to interpret it?) And just because Turbo C 1.0 supported that quirk does not make them bound to retain the "feature" in future compilers. I'm not frustrated at all by that problem... the lack of utime(), lint, and a curses package seem much more pressing than a ^M^J vs. ^J fight. --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>
alex@mks.UUCP (Alex White) (07/24/89)
In article <5608@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >TC 2.0 *almost* works with LF-only lines. Seems that only the preprocessor >command-recognizer fails.... (i.e. an #ifdef will get you a complaint about >a missing #endif, but a file without conditional compilation compiles >correctly). I do agree that this is an annoying problem. Unless I >misremember, TC 1.5 was the same as 2.0. Annoying? Yes very. We can't use 2.0, and continued using TC1.5. TC 1.5 accepted LF only lines, the error message line numbers were off. TC 2.0 fouls up in the preprocess parsing. I phoned borland to complain for 2.0 and they pointed out the official line delimiter for dos was CR-LF and hence said that it wasn't a bug, and they weren't going to do anything about it, and it didn't matter that previous releases accepted it, or that MSC and MASM both accept LF only lines.
schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) (07/24/89)
In article <1325@mks.UUCP> alex@mks.waterloo.edu (Alex White) writes: >In article <5608@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >>TC 2.0 *almost* works with LF-only lines. Seems that only the preprocessor >>command-recognizer fails.... (i.e. an #ifdef will get you a complaint about >>a missing #endif, but a file without conditional compilation compiles >>correctly). I do agree that this is an annoying problem. Unless I >>misremember, TC 1.5 was the same as 2.0. Not to be a pain, but in what situation is this a problem? If you are compiling source generated elsewhere (Unix system, for example), why not crank it through a filter to fix things? Such a filter should be trivial to write, yes? If your editor is generating these files, well, then you have more of a problem, but still solvable by switching editors. But somehow I get the feeling I missed something... Chris -=- "This town needs an enema." ---- Joker, "Batman" Christopher Schanck (schanck@cis.ohio-state.edu)
ltf@attctc.Dallas.TX.US (Lance Franklin) (07/25/89)
In article <55868@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: >>TC 2.0 *almost* works with LF-only lines. Seems that only the preprocessor >>command-recognizer fails.... >Not to be a pain, but in what situation is this a problem? If you are >compiling source generated elsewhere (Unix system, for example), why >not crank it through a filter to fix things? Which brings us full circle...the program flip, mentioned in the Subject line, does that very thing...converts a Unix-style LF-only file into an MS-DOS-style CR-LF file (or visa-versa). Which means we have now entered an endless loop! did somebody remember to do a signal(SIGINT...) so we can ctrl-c out of this thread? Oh, I forgot...it's ssignal, isn't it. :-) Lance -- +-------------------------+ +------------------------------------------+ | Lance T Franklin | | "And all who heard should see them there, | ltf@attctc.DALLAS.TX.US | | And all should cry, Beware! Beware! +-------------------------+ + His flashing eyes, his floating hair!"
alex@mks.UUCP (Alex White) (07/25/89)
In article <55868@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: >Not to be a pain, but in what situation is this a problem? If you are >compiling source generated elsewhere (Unix system, for example), why >not crank it through a filter to fix things? Such a filter should be >trivial to write, yes? If your editor is generating these files, >well, then you have more of a problem, but still solvable by switching >editors. You missed something. We're running over PC-NFS, with all our files on the unix machine. All our source code resides on unix, we do a lot of our development on unix. The unix box is effectively our file server, which we can also use independently We maintain all source in unix format because PC programs (except TC 2.0) don't care about the CR. I use vi on the unix box or the pc equally; on the pc I have the vi option set to not add CR's on writing, so I work with exactly the same files as on unix. Of course, there is another reason. For a say 2,000 line C source file, thats 2,000 bytes extra of carriage returns for no possible purpose.
dmt@mtunb.ATT.COM (Dave Tutelman) (07/26/89)
In article <1113@unocss.UUCP> ho@fergvax.unl.edu writes: >From article <26586@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): > >> I almost forgot the biggest pisser of all, the inability of TC 2.0 to >> work with lines terminated only by line-feeds, and worse yet, the >> failure to detect this problem in many cases. (TC 1.0 actually worked >> in this case.) >> ..... >I'm not happy with some of the design decisions behind MSDOS either (e.g., >the CRLF instead of NL). But given that I have to work with them, I don't >see any reason why the CRLF vs. LF problem should even be a problem. > >Changing NL's to CRLF's is the responsibility of the transporting program, >be that ftp, xmodem, or rz/sz, IMHO. It should not be the responsibility >of the application program to recognize a file which was improperly >transported across environments. (If you can't TYPE the file properly, >why should Turbo C be expected to interpret it?) Because UNIX(R) and MS-DOS can reside on the same machine. Today's 386 boxes can run both easily. If I have text files on such a box, I'd REALLY like to be able to process them under each OS. No transporting program should be needed, because I'm really not transporting the file. (Yes, I know I'm transporting the environment; I'm arguing practicality, not purity.) I recognize that we're far from there now, and may never get there. However, I'd certainly like to see Borland be part of the solution, not part of the problem. >And just because Turbo C 1.0 supported that quirk does not make them >bound to retain the "feature" in future compilers. True. I'm used to hearing that argument from my less favorite software suppliers. (Hmmm... I wonder whether that's random correlation or cause and effect.) Note that I'm a happy user of Turbo C. I use it in preference to the other leading C compilers (having used at least four different brands in the past). I'm also one of Borland's first customers, with Turbo Pascal serial #1026. So I'm not shooting flames at a favorite target. But it dismays me that they'd "break" this very useful "quirk", when they might use it as a positive product differentiator. The foregoing is my own opinion. I don't know AT&T's opinion on this subject, so I certainly can't represent it here. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Middletown, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 957 6583 | +---------------------------------------------------------------+
ho@fergvax.unl.edu (Michael Ho) (07/26/89)
From article <8760@attctc.Dallas.TX.US>, by ltf@attctc.Dallas.TX.US (Lance Franklin): > In article <55868@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes: > Which brings us full circle...the program flip, mentioned in the Subject > line, does that very thing...converts a Unix-style LF-only file into an > MS-DOS-style CR-LF file (or visa-versa). > > Which means we have now entered an endless loop! did somebody remember to > do a signal(SIGINT...) so we can ctrl-c out of this thread? > > Oh, I forgot...it's ssignal, isn't it. :-) Actually, it *is* signal now. In Turbo C 2.0. Confused yet? :-) Seriously, if someone is gonna post a program to transport something across architectures, they should give you a file readable on the TARGET machine, not the source machine -- and moaning about how the target machine SHOULD have read files of this type is ridiculous. (After all, if we REALLY expected the target PC to read LF-only lines, then this entire program was unneccessary.) P'raps I should write a Mac program to convert Mac files to PC files... then sell it to unwitting PC owners. Same issue, isn't it? --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>
ho@fergvax.unl.edu (Tiny Bubbles...) (07/27/89)
From article <1571@mtunb.ATT.COM>, by dmt@mtunb.ATT.COM (Dave Tutelman): > Because UNIX(R) and MS-DOS can reside on the same machine. Today's > 386 boxes can run both easily. If I have text files on such a box, > I'd REALLY like to be able to process them under each OS. No transporting ^^^^^^^^^^^^^ Can **IX read the DOS format text files? Can the **IX compiler handle something with CR/LF's at the end of each line? (These aren't flames; I honestly don't know how PC-based Unix clones work. Our mainframe Ultrix C compiler will honk and wheeze if I forget to set the -a option on rz.) Guess it's a matter of which environment is more important to you. If you consider **IX to be your 'main' system, and MS-DOS to be a slave, then I can understand your reasoning. But it would still be unfair to expect MS- DOS to cater to Unix's whims, while not expecting the Unix to bow to MS-DOS (if that is the case). --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>
bobmon@iuvax.cs.indiana.edu (RAMontante) (07/30/89)
As someone else mentioned n passing, MS-DOS's convention eats up 2K on a 2000-line file, to no advantage. Programs that process input streams have to do more work to handle End-Of-Lines; not much, but a bit more. Forgetting compatibility, the Unix convention just makes more sense.
cck@deneb.ucdavis.edu (Earl H. Kinmonth) (07/30/89)
In article <1153@unocss.UUCP> ho@fergvax.unl.edu writes: >From article <1571@mtunb.ATT.COM>, by dmt@mtunb.ATT.COM (Dave Tutelman): >can understand your reasoning. But it would still be unfair to expect MS- >DOS to cater to Unix's whims, while not expecting the Unix to bow to MS-DOS >(if that is the case). There is no question of either operating system "catering" to each other in some sort of personified sense. Operating systems have only the personality human programmers give them. So too for compilers. The question is ultimately, how sensitive are the authors of a given piece of software to real life convenience issues. I suspect that in a year or so, compatability in terms of files and libraries will be a testing requirement for C compilers. A few years ago, indeed, even a year ago, one would rarely see mention of **IX in PeeCee oriented magazines. Now, one gets an article or two per month in such mags. Several factors will contribute to this: the proliferation of 386/486 machines (running MSDOS on such machines is rather like having an Indy 500 car but only gravel roads to drive on); the proliferation of **IX machines as file servers for MSDOS machines; the (belated) recognition that OS-II is a bummer.