Author Topic: Option Literals:on "\n"  (Read 507 times)

aw27

  • Member
  • ****
  • Posts: 709
Re: Option Literals:on "\n"
« Reply #30 on: September 04, 2017, 03:14:38 AM »
No, your example doesn't redirect perfectly - you know that, of course.
Of course, it redirects perfectly.

Quote
@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--

  • Administrator
  • Member
  • ******
  • Posts: 4813
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Option Literals:on "\n"
« Reply #31 on: September 04, 2017, 03:35:13 AM »
 :biggrin:

> 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.

Quote
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.

hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: Option Literals:on "\n"
« Reply #32 on: September 04, 2017, 03:43:16 AM »
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)

Quote
Quote
@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 :bgrin:

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

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: Option Literals:on "\n"
« Reply #33 on: September 05, 2017, 10:05:41 PM »
Johnsa has fixed that \n\r stuff :t
New Uasm has been uploaded today :biggrin:
Please test it :greenclp:
Cod-Father

habran

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: Option Literals:on "\n"
« Reply #34 on: September 05, 2017, 10:33:58 PM »
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 start
here 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
Cod-Father

aw27

  • Member
  • ****
  • Posts: 709
Re: Option Literals:on "\n"
« Reply #35 on: September 05, 2017, 10:39:29 PM »
Johnsa has fixed that \n\r stuff :t
New Uasm has been uploaded today :biggrin:
Please test it :greenclp:
@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

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: Option Literals:on "\n"
« Reply #36 on: September 05, 2017, 10:53:11 PM »
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 :eusa_clap:
Cod-Father

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: Option Literals:on "\n"
« Reply #37 on: September 05, 2017, 11:45:25 PM »
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

  • Member
  • ****
  • Posts: 526
    • Uasm
Re: Option Literals:on "\n"
« Reply #38 on: September 05, 2017, 11:50:53 PM »
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

  • Member
  • ****
  • Posts: 709
Re: Option Literals:on "\n"
« Reply #39 on: September 06, 2017, 12:07:07 AM »
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.  :badgrin:


nidud

  • Member
  • *****
  • Posts: 1371
    • https://github.com/nidud/asmc
Re: Option Literals:on "\n"
« Reply #40 on: September 06, 2017, 12:24:13 AM »
 :biggrin:

Code: [Select]
include stdio.inc
include stdlib.inc
include winbase.inc

.code

main proc

    printf("Here\nis\none\n")
    WriteFile(
        GetStdHandle(STD_OUTPUT_HANDLE),
        "Here\r\nis\r\nanother one\r\n",
        sizeof(DS0001), NULL, 0)
    exit(0)

main endp

    end main

Code: [Select]
Here
is
one
Here
is
another one

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: Option Literals:on "\n"
« Reply #41 on: September 06, 2017, 06:16:55 AM »
High-Level Console Modes
Quote
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--

  • Administrator
  • Member
  • ******
  • Posts: 4813
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Option Literals:on "\n"
« Reply #42 on: September 06, 2017, 08:19:28 AM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

aw27

  • Member
  • ****
  • Posts: 709
Re: Option Literals:on "\n"
« Reply #43 on: September 06, 2017, 09:31:05 AM »
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--

  • Administrator
  • Member
  • ******
  • Posts: 4813
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Option Literals:on "\n"
« Reply #44 on: September 06, 2017, 11:09:38 AM »
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...
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin: