Option Literals:on "\n"

[aw27]

No, your example doesn't redirect perfectly - you know that, of course.

Of course, it redirects perfectly.

@José: If you are looking for crt-free code, try MasmBasic ;)

You invented a CRT MACRO that make a "just in time" assembly of the CRT functions. You are indeed a genius.  :t

I apologize, but I think all aspects have been dealt with so, I will have to pass for further comments.  :(

[hutch--]

 

> And a search within the \masm32\include directory tells that exist 80 *.inc files with PROTO C functions.

Have you counted the number of API prototypes that are STDCALL ?

> I was referring to the import libraries included with MASM32

Have you counted the number of API prototypes that are STDCALL ?

> The include file msvcrt.inc, which is part of the main include file masm32rt.inc of the SDK distribution, contains many hundreds of renamed functions with the crt_ prefix

Yes I know, I wrote the tool that created them. What you don't do is lose a massive number of names because they are used in another language, this allows the project to use any name it likes without being restricted by another language. In case anyone has missed it, MASM is a macro assembler that does not need a C compiler although it can easily use a module created in C if its done properly.

and is not bound to give any credence to other languages naming conventions.

> ..than C, PASCAL, STDCALL, FASTCALL, ...

I think you have missed the point here, MASM comes with NO RUNTIME LIBRARY at all, the vast majority of API functions are STDCALL, a few are in C, as far as I know there are no PASCAL functions and in 32 bit you can cook your own version of FASTCALL if you want to.

I know that you guys come from a different set of assumptions but I will make the point that MASM as a macro assembler can produce EXE, DLL, and OBJ files without any other help from C compilers.

LATER :
> These Windows API functions loads msvcrt.dll and use these functions, so MSVCRT is definitely a vital part of the package.

This is nonsense, you can call any of the entire Windows API function set without having to include MSVCRT.

[jj2007]

No, your example doesn't redirect perfectly - you know that, of course.

Of course, it redirects perfectly.

If you consider the CR CR LF at the end "perfect", then you are right, of course. But I vaguely remember that the OP started this thread because of such unwanted sequences 8)

@José: If you are looking for crt-free code, try MasmBasic ;)

You invented a CRT MACRO that make a "just in time" assembly of the CRT functions. You are indeed a genius.  :t

Wow, that one I had completely forgotten! I wanted to be kind to C programmers in transition

But you can open any "normal" MasmBasic exe in PeView, you won't find the CRT loaded (unless Masm32 functions are used, of course).

[habran]

Johnsa has fixed that \n\r stuff :t
New Uasm has been uploaded today
Please test it

[habran]

aw27 source from the post #4

Code: [Select]

OPTION frame:auto
OPTION WIN64:2
option LITERALS:ON


includelib \masm32\lib64\kernel32.lib
ExitProcess proto :dword
includelib \masm32\lib64\msvcrt.lib
printf proto :ptr, :vararg

.code
start:
  invoke printf, "Here\nis\none"
  invoke ExitProcess,0

end starthere is the text:

Code: [Select]

0x0000000000A75000  48 65 72 65 0a 69 73 0a 6f 6e  Here.is.on
0x0000000000A7500A  65 00 00 00 00 00 00 00 00 00  e.........
and here is output:
Here
is
one

[aw27]

Johnsa has fixed that \n\r stuff :t
New Uasm has been uploaded today
Please test it

@habran,
It fixes when assembling for 64-bit with LITERALS:On.  :t
When assembling 32-bit with LITERALS:ON the escapes are not converted, though.
The escapes are also not converted, in either case, when not using LITERALS:ON and we just pass the address of the string. I think it is possible to do that as well without conflicting with the special characters used by the macros.

[habran]

Good find :t
I'll pass it on Johnsa, it is his babe ;)
BTW, I am happy with your attitude and I appreciate your contribution for insurgence of UASM

[jj2007]

Johnsa has fixed that \n\r stuff :t

it has been working perfectly

Was there something that needed fixing...? Don't underestimate the risk of breaking existing code. IMHO there was nothing that needed a fix, except the CRT runtime that adds arbitrarily CR chars where it shouldn't - but that is clearly not our baby.

[johnsa]

Hi,

I never put anything in to support the escapes in raw string data, as you can directly add the values yourself :
myString db "this is a string",13,10,0  for example
So at present they're only on the literals as directly used by invoke, I will look into the 32bit issue as they should function exactly the same! :)

[aw27]

I never put anything in to support the escapes in raw string data, as you can directly add the values yourself :
myString db "this is a string",13,10,0  for example

myString db "this",10,"is a",10,"string",10,0

is fine for the printf of msvcrt.dll. No need to add the 13 in the end too.

The printf of Visual Studio is not the printf of msvcrt, it is a bit more intelligent.

@JJ,
No comments. 

[nidud]

deleted

[jj2007]

High-Level Console Modes

ENABLE_PROCESSED_OUTPUT: The backspace, tab, bell, carriage return, and line feed characters are processed

Problem is that I can't convince the OS to stop helping me: It always adds CR, even if the string contains only LFs ::)

Which makes the behaviour of CRT printf() even more suspect and superfluous. But I do remember that you could produce

These
     stairs
           have
               five
                   steps

with a string containing only linefeeds. Or was that on Windows 98?

[hutch--]

I still don't know why anyone bothers with "printf" when its such an archaic format from the days of DOS consoles and command line Unix. It is relatively easy to produce StdOut in both 32 and 64 bit Windows and simply by procedure design it both outputs to the screen and redirects with no problems at all. I just don't see the point of struggling to conform to ANSI 1989 or earlier when that world no longer exists. My only view is leave this historical junk to the out of date but backwards compatible C compilers.

[aw27]

At least when LITERALS:ON it would be useful to translate the remaining escape characters (backspace, tab, bell, carriage return). In particular because it is not possible to insert the codes in the middle, like I did above:
myString db "this",10,"is a",10,"string",10,0
And of course all this will be useful for any function, and there are many-the limit is the imagination- that would use a literal string, not only printf.
I am not here to participate in wars between C (or any other programming) and MASM. I don't think it makes sense and leads nowhere. Every programming language has its place. One think is undeniable, both C and MASM complement each other are are set to work together. Actually MASM can be used together with any HLL I am aware of, even the .Net languages. Still, makes a better match with C.

[hutch--]

This is why I am a macro assembler man.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL number    :QWORD

    mov number, 1234

    conout chr$(9),"Leading Text", \
           cfm$("\n\tHow D Awl\n\tthis is a converted number -\r "), \
           str$(number),chr$(32,60,13,10,9),"Trailing Text",lf

    waitkey

    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

Which outputs to the screen,

        Lead Text
        How D Awl
        this is a converted number -> 1234 <
        Trailing Text
Press any key to continue...