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 exactly
what I want.
However when I do the very same under the console (using bash or sh.
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 very
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 Eterm
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
react
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 reasons
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
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
terms
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
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 have a
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 exactly
what
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
11 matches
Mail list logo
