WTW101@PSUVM.BITNET (Bill Warner) (08/11/89)
I am outputing text in assembly using the DOS funtion Write(...). I am
terminating my lines with single linefeeds. The text outputs to the default
output device (the screen) just fine. When I redirect my text to the disk
(via >df1:bla) then TYPE this file everything is dandy. However when I edit
this file with DME I have missing text!
The missing text occurs when I continue a line of text. i.e. I call
Write(...) and print some text, then I call Write(...) again and print text
thats terminates with a linefeed. The latter half of the text dissapears!
Ideas? Answers?
Chris
CJC@psueclacmcmanis%pepper@Sun.COM (Chuck McManis) (08/11/89)
In article <89222.135727WTW101@PSUVM> WTW101@PSUVM.BITNET (Bill Warner) writes: >The missing text occurs when I continue a line of text. i.e. I call >Write(...) and print some text, then I call Write(...) again and print text >thats terminates with a linefeed. The latter half of the text dissapears! >Ideas? Answers? Easy to hit bug. I bet when you call "Write(...)" for the first segment of the line you count the nul character, when you continue you start just past the nul you outputed. DME probably treats the NUL as the EOL since C does. But copy, and AmigaDOS in general just blasts whats in the file to the console and if it happens to have nuls in it, it doesn't care. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
WTW101@PSUVM.BITNET (Bill Warner) (08/11/89)
Isn't multi-tasking great? For as we speak I can confirm your suspicions.
You were correct in the fact that I do have nulls in my output, however it was
not from overestimating the length of my output. It was due to another oversite
. Thanks for the help. Also thanks for J Wright for the 'TYPE file OPT H'
suggestion.
Chris
CJC@psueclartczegledi@crocus.waterloo.edu (Richard Czegledi) (08/12/89)
In article <89222.135727WTW101@PSUVM> WTW101@PSUVM.BITNET (Bill Warner) writes: >I am outputing text in assembly using the DOS funtion Write(...). I am >terminating my lines with single linefeeds. The text outputs to the default >output device (the screen) just fine. When I redirect my text to the disk >The missing text occurs when I continue a line of text. i.e. I call [...] >Write(...) and print some text, then I call Write(...) again and print text >thats terminates with a linefeed. The latter half of the text dissapears! How about using CR LF's? One seriously braindamaged (in my opInion) 'feature' of AmigashmnOS is that it uses LF's for end of lines. This creates lots of problems when I'm taking my textfiles to IBM's and other machines. Why couldn't they have done it proper? Lf is a line feed! and CR is a carriage return. It's a pain when programs start sticking out LF's in the middle of lines. Such programs usualy crap out on my terminal (he who lives without a terminal for editing is not alive). ------------------------------------------------- We were developing a new line eater organism, but it escaped from the culture dish, ran rampant through the lab and crawled into a machine where it multiplied. Then it ate all of the signature files. But we managed to contain it before it went through the net{{{{^ 'YUM'
ecarroll@csvax1.cs.tcd.ie (Eddy Carroll) (08/12/89)
In article <89222.135727WTW101@PSUVM>, WTW101@PSUVM.BITNET (Bill Warner) writes: > I am outputing text in assembly using the DOS funtion Write(...). I am > terminating my lines with single linefeeds. The text outputs to the default > output device (the screen) just fine. When I redirect my text to the disk > (via >df1:bla) then TYPE this file everything is dandy. However when I edit > this file with DME I have missing text! > > The missing text occurs when I continue a line of text. i.e. I call > Write(...) and print some text, then I call Write(...) again and print text > thats terminates with a linefeed. The latter half of the text dissapears! > > Ideas? Answers? > > Chris > CJC@psuecla It sounds like you are either accidentally or intentionally outputting a null byte ($00) at the end of each string you Write(). The Type command ignores these, but DME treats them as an end-of-line indicator. The easy solution is to subtract 1 from the 'Length' parameter you are passing to Write(), so the terminating $00 you have at the end of your strings won't actually get written. -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until INTER: ecarroll@cs.tcd.ie | you've died in MUD!" UUCP: {..uunet}!mcvax!ukc!cs.tcd.ie!csvax1!ecarroll | -- Richard Bartle
addison@pollux.usc.edu (Richard Addison) (08/13/89)
In article <15874@watdragon.waterloo.edu> rtczegledi@crocus.waterloo.edu (Richard Czegledi) writes: }In article <89222.135727WTW101@PSUVM> WTW101@PSUVM.BITNET (Bill Warner) writes: }>I am outputing text in assembly using the DOS funtion Write(...). I am }>terminating my lines with single linefeeds. The text outputs to the default }>output device (the screen) just fine. When I redirect my text to the disk }>The missing text occurs when I continue a line of text. i.e. I call }[...] }>Write(...) and print some text, then I call Write(...) again and print text }>thats terminates with a linefeed. The latter half of the text dissapears! } }How about using CR LF's? One seriously braindamaged (in my opInion) 'feature' }of AmigashmnOS is that it uses LF's for end of lines. This creates lots }of problems when I'm taking my textfiles to IBM's and other machines. } }Why couldn't they have done it proper? Lf is a line feed! and CR is a }carriage return. It's a pain when programs start sticking out LF's }in the middle of lines. Such programs usualy crap out on my terminal }(he who lives without a terminal for editing is not alive). Interestingly enough (considering the alleged bias of the creators of AmigaDOS), this is a convention from UNIX. Having a single character to mark an end of line is rather handy, actually. DME will show the CR characters as reversed M's (at least when I use WB1.3's NEWCON:). Richard Addison "The mad poster strikes again. What me worry? Be happy!"
peter@sugar.hackercorp.com (Peter da Silva) (08/15/89)
In article <15874@watdragon.waterloo.edu>, rtczegledi@crocus.waterloo.edu (Richard Czegledi) writes: > How about using CR LF's? Because it increases the size of files (slightly) and increases the complexity of programs that manipulate text files (considerably, in some cases) for absolutely no good reason. Because CP/M and MS-DOS are the only systems that do things this way (UNIX and AmigaDOS use LF, OS/9 uses just a single CR, and most minicomputer and mainframe operating systems use either 80-column card image format or variable length records). > One seriously braindamaged (in my opInion) 'feature' > of AmigashmnOS is that it uses LF's for end of lines. This creates lots > of problems when I'm taking my textfiles to IBM's and other machines. So write a 5-line BASIC program to fix them up, and don't worry about it. > Why couldn't they have done it proper? They did do it proper. It's MS-DOS and CP/M that screwed up. > Lf is a line feed! The ASCII character set defines LF as a line feed, or as a line terminator. It specifies that if a single character is to be used as a line terminator it should be line-feed. For reasons obvious to the most casual observor, a single character line terminator is preferable (most MS-DOS programs punt the problem by keying off CR as the terminator, BTW, and skipping LFs. Too many programmers out there who wouldn't know an O/S if it bit them on the ass, bringing all their CP/M bad habits with them). QED. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`