Hi, Paul.

PE> FM> Of course! But it's the buffer move problem your solving here, not the
PE> FM> move until \n problem.

PE> Yeah, that's right, separate threads.

PE> PE> memcpy is designed to copy from a buffer to another buffer, for
PE> PE> a length of whatever.  No overrun allowed.  Destination to be
PE> PE> returned to caller.  Parameter order is dest, source, length...

PE> FM> You should also mention that it returns *dest (if I've read that 'C'
PE> FM> code properly).

PE> It returns dest, not *dest.

Can you explain that to me in non-'C' terms? Like on say the '86
platform, what would be returned in some registers in each case.

PE> PE> _DATA   segment dword public use32 "DATA"
PE> PE> _DATA   ends
PE> PE> _BSS    segment dword public use32 "BSS"
PE> PE> _BSS    ends

PE> FM> AAMOI why do specify these segments here?

PE> Basically because I don't really understand segments, but what I
PE> do have is some skeleton code that I use for my assembler
PE> programs.

Yes, I write real assembler (as distinct from embedded in Pascal) so
seldom that I need to have a skeleton to avoid having to rethink the
basics each time. I used to do that for COBOL too, but that was to avoid
having to write, and have keypunched (yes, this was in the punched card
days), all the boilerplate. Even though I reckon I could still reel off
from memory exactly what you had to have to get the program compiled on
a Burroughs Medium System machine - and it's 18 years (bloody hell!)
since I had to do so.

Regards, FIM.

 * * Have I reached the person to whom I am speaking?
@EOT:

---