On Sun May 22 05, Andrew MacIntyre wrote:
> alexander wrote:
> >However burncd being a C app uses fprintf. Can I replace
> >the functionality of fprintf under x86asm by using only syscalls?
>
> fprintf(3) is most likely doing buffered I/O in the burncd case, which
> for a tty defaults to line buff
alexander wrote:
However burncd being a C app uses fprintf. Can I replace
the functionality of fprintf under x86asm by using only syscalls?
fprintf(3) is most likely doing buffered I/O in the burncd case, which
for a tty defaults to line buffered.
Your code is doing unbuffered I/O, which might
On Sun, 2005-May-22 00:09:35 +0200, alexander wrote:
>On Sun May 22 05, Peter Jeremy wrote:
>>
>> Can you please confirm that you also see the problem when you are using
>> xterm (not Eterm). Can you also please advise what versions of FreeBSD,
>> X11 and xterm/Eterm you are using.
>
>OK. Seems l
On Sun May 22 05, Peter Jeremy wrote:
>
> Can you please confirm that you also see the problem when you are using
> xterm (not Eterm). Can you also please advise what versions of FreeBSD,
> X11 and xterm/Eterm you are using.
>
OK. Seems like you somehow knew what was going on here. The problem
On Sat, 2005-May-21 16:58:07 +0200, alexander wrote:
>On Sat May 21 05, Peter Jeremy wrote:
>>
>> I think you need to give us more details and preferably some sample code
>> to simulate the problem. What is the hardware you are running on? What
>> version of FreeBSD, X11 and xterm/Eterm.
...
>Th
On Sat May 21 05, Peter Jeremy wrote:
>
> I think you need to give us more details and preferably some sample code
> to simulate the problem. What is the hardware you are running on? What
> version of FreeBSD, X11 and xterm/Eterm.
>
> --
> Peter Jeremy
Here's the code that is using the VT100
On Sat, 2005-May-21 03:51:05 +0200, alexander wrote:
>Ohh...sorry for not telling you this. Yes. The app works alright when
>executed from the console. But my problem is with xterm or Eterm. They don't
>handle VT100 very well.
By default, xterm is a VT102 superset, and the VT102 is a VT100 superse
In message: <[EMAIL PROTECTED]>
alexander <[EMAIL PROTECTED]> writes:
: On Fri May 20 05, Dan Nelson wrote:
: >
: > How often are you doing this? I wrote a quick microbenchmark and my
: > pIII-900 box can do 8 writes() per second of "\e[5D\e[Kabcde". I
: > don't think that's your
In the last episode (May 21), alexander said:
> Ohh...sorry for not telling you this. Yes. The app works alright when
> executed from the console. But my problem is with xterm or Eterm.
> They don't handle VT100 very well. I've added a nanosleep after each
> VT100 output but that didn't solve the i
On Fri May 20 05, Dan Nelson wrote:
>
> How often are you doing this? I wrote a quick microbenchmark and my
> pIII-900 box can do 8 writes() per second of "\e[5D\e[Kabcde". I
> don't think that's your bottleneck. If it is, the usual solution is to
> not do a write on every iteration. You'v
In the last episode (May 21), alexander said:
> I'd like to port an application that was written in x86 assembly for
> Linux. So far all I had to do is change the Linux calling convention
> (registers) to Posix style (stack).
>
> However at one point this application outputs 5 characters to stdout
I'd like to port an application that was written in x86 assembly for Linux.
So far all I had to do is change the Linux calling convention (registers)
to Posix style (stack).
However at one point this application outputs 5 characters to stdout (using
syscall write and fd=1). These 5 characters howe
12 matches
Mail list logo
