On 16 May, alexander wrote:
> You're right. The code I'm using is wrong when it is being executed
> under the console. However the fact that Eterm and xterm do what I
> want to do with my app show that I'm not the only one who needs a
> NOP ascii value. Both render the NUL ascii code as NOP. Since
On Mon, 16 May 2005 19:11:44 +0200
alexander <[EMAIL PROTECTED]> wrote:
> Hi there.
>
> I'm using syscall number 4 write() to output data to stdout using x86
> assembly. When I try to output the following DWORD: 0x3532 I get
> the following output under Eterm and xterm: "25". Which is exactl
> You're right. The code I'm using is wrong when it is being executed
> under the console. However the fact that Eterm and xterm do what I
> want to do with my app show that I'm not the only one who needs a
> NOP ascii value. Both render the NUL ascii code as NOP. Since both
> terms are much newer
In the last episode (May 16), alexander said:
> On Mon May 16 05, Warner Losh wrote:
> > The ANSI character set standard doesn't talk at all about how
> > characters are rendering. Terminal emulation software renders the
> > characters as they see fit. NIL is *NOT* a NOP.
>
> OK. You defentately
On Mon May 16 05, Frank Mayhar wrote:
>
> Not "much easier." "Correct."
>
> The fact that your code wrote three NULs to the console in the first
> place meant that your code, not the console, was broken.
> --
> Frank Mayhar [EMAIL PROTECTED]http://www.exit.com/
> Exit Consulting
alexander wrote:
> You're right. The code I'm using is wrong when it is being executed
> under the console. However the fact that Eterm and xterm do what I
> want to do with my app show that I'm not the only one who needs a
> NOP ascii value. Both render the NUL ascii code as NOP. Since both
> term
On Mon May 16 05, Warner Losh wrote:
>
> The ANSI character set standard doesn't talk at all about how
> characters are rendering. Terminal emulation software renders the
> characters as they see fit. NIL is *NOT* a NOP.
OK. You defentately have a point right there. Surely telling write(2)
to r
> Since there already is an ascii code for the white space (SP = 20h) I don't
> quite understand why 00h is also interpreted as a white space. Because that
> makes two values for a white space, but not a single value for the NOP
> operator. If this behaviour of the console is due to historic reason
On Mon May 16 05, Warner Losh wrote:
> From: alexander <[EMAIL PROTECTED]>
> Subject: Console ASCII interpretation
> Date: Mon, 16 May 2005 19:11:44 +0200
>
> No. It means NUL. When writing with write(2), you are telling the
> system to output 4 bytes. How different terminal emulation programs
From: alexander <[EMAIL PROTECTED]>
Subject: Console ASCII interpretation
Date: Mon, 16 May 2005 19:11:44 +0200
> Hi there.
>
> I'm using syscall number 4 write() to output data to stdout using x86
> assembly. When I try to output the following DWORD: 0x3532 I get
> the following output under
In the last episode (May 16), alexander said:
> I'm using syscall number 4 write() to output data to stdout using x86
> assembly. When I try to output the following DWORD: 0x3532 I get
> the following output under Eterm and xterm: "25". Which is exactly
> what I want.
>
> However when I do the
11 matches
Mail list logo
