additional new line(s) when re-direct to file

[ggmasm32]

i wrote M_PRINTF macro which does some similar to printf() in C, it is working great. However when I re-directed the program output to a text file, i can see it adds two additional new line whenever new line is encountered. Wondering if there is any fix can be made. Because of this, the log output file is 3 times lenghtier than its console output.
In non-redirected case, it is just one new line.

What the M_PRINTF does when it encounters '\n' string is prints 0ah, 0dh using int21 (ax=02h) function. That is all it does.
If I looked at the generated log file by re-direct using hex editor, I see 0ah, 0dh, 0dh.

One thing I did was exchange the printing sequence of 0ah and 0dh to 0dh and 0ah just to see what happens. Result is slightly better, instead of inserting 2 new line now it has 1 new add'l line, much more readable. I see 0dh 0ah 0ah in the text file.

Also, when I scour the internet, the 0dh and 0ah seems to be correct sequence since it is CRLF, so only thing remain is how to eliminate 1 add'l line when re-directed.

[jj2007]

How do you seriously expect help if you don't post your code? Telepathy is a great concept, but so far it has never worked in this forum 8)

[ggmasm32]

OK I posted the entire function below:

Currently i changed the order as 0xd, 0xa in which case, I notice both on cmd line console and redirected file it is adding 1 more extra redundant line
Previously order was 0xa, 0xd in which case, on cmd line console: one extra line but then redirected to a file it is adding 2 more extra redundant line
Btw, mov cx, 03h line just before has no meaning, at least i dont see, i just kept there in case something not get broken, i should as well remove and test to make sure nothing affected.

Thanks.,



;   create string specified by pStr on the fly in code segment
;   and outputs the string. useful to call: M_PRINT "str" without
;   specifying address somewhere else in the memory.

M_PRINTF MACRO pStr
    local skipStr, printfLoop, exitMacro, printfStr, m_printf_skip_esc_char
    IF      OPTION_ENABLE_M_PRINT
    push    ax
    push    dx
    push    bp
    push    cx

    jmp skipStr
    printfStr     db pStr, '$'

skipStr:
    lea     bp, cs:printfStr
    mov     cx, 3h

printfLoop:
    mov     ah, 02h
    mov     dl, cs:[bp]
    cmp     dl, '$'
    je      ExitMacro

    cmp     dl, '\'
    jne     m_printf_skip_esc_char
    cmp     byte ptr cs:[bp+1], 'n'
    jne     m_printf_skip_esc_char
    inc     bp

    mov     dl, 0dh
    mov     ah, 02h
    int     21h
    mov     dl, 0ah
    mov     ah, 02h
    int     21h
   

m_printf_skip_esc_char:
    int     21h
    inc     bp
    dec     cx
;   jz      exitMacro
    jmp     printfLoop

exitMacro:
    pop     cx
    pop     bp
    pop     dx
    pop     ax
    ENDIF
    ENDM

[FORTRANS]

Hi,

Code: [Select]

    mov     dl, 0dh
    mov     ah, 02h
    int     21h
    mov     dl, 0ah
    mov     ah, 02h
    int     21h     ; This prints one linefeed.
   

m_printf_skip_esc_char:
    int     21h     ; This will print a second linefeed.

   So, comment out the first.

HTH,

Steve

[ggmasm32]

Thanks I will give it a try. Using this chance I am wondering if i can ask one more thing related?
is there any pre-defined asm macro that can give a name of current proc or calling proc (parent that called current proc)?
I am intenting to define PRINTDBG function and/or that prints out any string with function name for the purpose of making debug easier, so that output is something like this:

"FcnName: "Error, blah blah"

when macro called by
PRINTDBG "Error, blah blah"

Previously I attempted to write the function name literally before each string, but as you can imagein it is incredibly tedious and error phone. Thanks.

[ggmasm32]

Hi,

Code: [Select]

    mov     dl, 0dh
    mov     ah, 02h
    int     21h
    mov     dl, 0ah
    mov     ah, 02h
    int     21h     ; This prints one linefeed.
   

m_printf_skip_esc_char:
    int     21h     ; This will print a second linefeed.

   So, comment out the first.

HTH,

Steve

that was bad bug. i took out the second int 21h and yes it works finally. thanks! :D