The MASM Forum

;||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
;解群自定义宏
;**************************************
    scanf  MACRO format:REQ,args:VARARG
      rcall vc_scanf,cfm$(format),args
      EXITM <>
    ENDM 

    printf  MACRO format:REQ,args:VARARG
    rcall vc_printf,cfm$(format),args
      EXITM <>
    ENDM
;**************************************
;||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

they work properly and i have added them to my MASM 64SDK main macro MACRO64.INC. Everything is fine, please all lazy people, good to create their own useful macro code.

They look good, just make sure that the names do not clash with anything in the VC runtime library. The reason for the "vc" prefix is to avoid this problem. "vc_scanf"

Quote from: hutch-- on November 15, 2020, 12:34:50 AM
They look good, just make sure that the names do not clash with anything in the VC runtime library. The reason for the "vc" prefix is to avoid this problem. "vc_scanf"

very good

; *******************************************************

    include \masm32\include64\masm64rt.inc

    .data
   a dq ?
   b dq ?
   s dq ?
.code

; ******************************************************

entry_point proc
       
    printf("\t please input a and b \t")
    scanf("%ld%ld", offset a, offset b)
    mov rax,a
    add rax,b
    mov s,rax
    printf("\t a+b=%ld",s)
    printf("\n")
    waitkey

    .exit

entry_point endp

;*******************************************************

    end

it need to be noticed  that the "offset"

Hi stevenxie,

Reading the original macros64.inc :

    rcall MACRO pname,ag1,ag2,ag3,ag4
      register_call pname,ag1,ag2,ag3,ag4
    ENDM

The rcall macro takes a maximum of 5 parameters.

Here is another version of your printf macro :

include     \masm32\include64\masm64rt.inc

printf MACRO format:REQ,args:VARARG
   invoke vc_printf,cfm$(format),args
ENDM

.code

start PROC

    printf "%s %u %u %u %u %u","This is a test",1,2,3,4,5
    invoke  ExitProcess,0

start ENDP

I get the following error message with your macro :

UpperCase.asm(11) : warning A4006:too many arguments in macro call

hi vortex.
it is a simple question
folowing:

.........
printf("%d %d %d  ",1,2,3)
printf("%d %d %d",5,6,7)
.........
so it have unlimit args.
:eusa_boohoo:

Hi stevenxie,

Your macro is nice but I am afraid the case is not so simple. You are calling twice the printf macro while you can do it only with one line. In your code, you have four items limit per call. Don't misunderstand me, my aim is not to be a critique here. With some small retouches, I am sure you can write very useful macros. Thanks for your macro idea.

dear vortex, thank for you!

Hi Steven, just one suggestion, like many of others I used to use simple single characters as variables but it comes back to bite you later when you don't remember what each one was. It is useful to use descriptive names as it helps you to keep track of what code is doing when you look at it again some time later.

Sad to say I have been caught enough times where I have had to carefully track what a variable does to make sense of the code again and this does matter when you write code that is designed to be reused like libraries or code block that you want to insert later.

best way is to use the original functions with the original libraries or with windows 10 a library with the inlines functions.
You can have a library with inlines functions here http://luce.yves.pagesperso-orange.fr/header.htm (http://luce.yves.pagesperso-orange.fr/header.htm)
dowload the sdk10.0 it is in H:\sdkrc100\crt_lib\IX86\release\crt10_32.lib
there is the same in 64

The real problem with directly calling C runtime libraries is issues of namespace, it already clashes with some MASM reserve words and the process of appending a lead "vc" solves that problem. Working the 64 bit include and library in 64 bit MASM are problem free.

Real problem is to have rebuild the msvcrt librarie changing the names of various functions.
The msvcrt is just a part of the system and cannot be modified without many risks and problems.

Except that it has namespace errors when used with MASM. The includes and library are very reliable and does not have the problems of trying to use a C runtime library.

Is it possible to set internal and external names in import libraries? Maybe this would be another method to avoid naming conflicts.

I use the libraries as they are with the prototypes as they are(just translate) without any problem (UASM).
Ml64 could use also the same protototypes but is more limited than UASM.
With windows 10 , there is just the inline functions who are a problem.They need a simple library done by Visual Studio.
It is possible.

Quote from: hutch-- on November 15, 2020, 08:48:36 PMit already clashes with some MASM reserve words

Can you give an example?

Hi Jochen,

\masm32\bin\dumpbin.exe /EXPORTS \Windows\System32\msvcrt.dll > exports.txt

The list will include two Masm reserved keywords, div and FABS.

FABS     ABSolute value of ST(0)

I see - thanks, Erol. It works fine with my Masm64 implementation, but I can imagine that other SDKs have a problem.
  if @64
movlps xmm0, MyReal8
jinvoke fabs, xmm0
movlps MyDest, xmm0
  else
jinvoke fabs, MyReal8
fstp MyDest
  endif
  Print Str$("The absolute value is %f\n", MyDest)
  jinvoke div, 12345, 246
  mov rcx, rdx
  Print Str$("div 12345/246 = %i with remainder %i\n", rax, rcx)

Output:
The absolute value is 123.456000
div 12345/246 = 50 with remainder 45

Hi Jochen,

The solution in the Masm package is to rename those functions :

32-bit :

c_msvcrt typedef PROTO C :VARARG

externdef _imp__fabs:PTR c_msvcrt
crt_fabs equ <_imp__fabs>

externdef _imp__div:PTR c_msvcrt
crt_div equ <_imp__div>


64-bit :

externdef __imp_fabs:PPROC
vc_fabs equ <__imp_fabs>

externdef __imp_div:PPROC
vc_div equ <__imp_div>


Yes, open "msvcrt.inc" and you will find them. Prepending the "vc" makes it possible to,

(a) avoid namespace clashes
(b) create different VCRT includes and libraries with no clashes.

MASM is not subject to the restriction of VC, a mistake that many have made and it is not crippled like UASM with a quirky requirement for old format prototypes that no-one is willing to provide.

With a very extensive set of includes and libraries, 64 bit MASM has no need of this junk.

Quote
With a very extensive set of includes and libraries, 64 bit MASM has no need of this junk.

Ah Venise !!!!!!!!!
But more serious,made a masm package without a modified msvcrt is the perfect soluce.
for 64 ,
The need is to use the ucrt and msvcrt original lib and normal prototypes.
I doubt that the ucrt.lib will be happy with the modified mscvrt of the masm32 package.

Hi TouEnMasm,

The modification is only the naming of the function prototypes prepended with the vc_ prefix. The import library remains intact - no any modification :

C:\masm32\lib64>\PellesC\bin\podump.exe /EXPORTS msvcrt.lib > exports.txt
C:\masm32\lib64>type exports.txt | findstr "vc_"

The problem is that it is not a perfect solution, if you have a look at the list of VC runtime functions, some of the names are MASM reserve words which makes the direct approach useless. 64 bit MASM is very intolerant to errors. You use the standard C runtime libraries with Microsoft C. Differing from your assumptions, MASM does not need to try and emulate C, it does its own MASM notation well.

There is another problem, the MSVCRT include and library is only for MSVCRT, not any of the later versions so if you get some of the C runtime going, you cannot use a later version due to namespace collisions.

Here is how to do "printf" in both ASCII and UNICODE. The original was written by Michael Webster some years ago, it was later modified to include a UNICODE version using the same notation.

    printf MACRO format:REQ, args:VARARG
      IFNDEF __UNICODE__
        IFNB <args>
          fn crt_printf, cfm$(format), args
        ELSE
          fn crt_printf, cfm$(format)
        ENDIF
        EXITM <>
      ELSE
        IFNB <args>
          fn crt_wprintf, cfm$(format), args
        ELSE
          fn crt_wprintf, cfm$(format)
        ENDIF
        EXITM <>
      ENDIF
    ENDM

A macro is the solution if you want to try and ape C code. Here is a simple text example.

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

    include \masm32\include64\masm64rt.inc

    printf MACRO format:REQ, args:VARARG
        IFNB <args>
          fn vc_printf, cfm$(format), args
        ELSE
          fn vc_printf, cfm$(format)
        ENDIF
        EXITM <>
    ENDM

    .code

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

entry_point proc

    USING r12

    SaveRegs

    printf("\n\n\tprintf demo\n\t\t\qNext Line\q\n\t\t\t\qAnother Line\q\n\n\n");

    waitkey
    RestoreRegs
    .exit

entry_point endp

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

    end

The simple way in five minutes

Quote
   include sdk64.inc
   include stdio.sdk
   include conio.sdk
   includelib ucrt.lib
   includelib msvcrt.lib
   includelib H:\sdkrc100\crt_lib\X64\release\crt10_64.lib ;inline fonctions
   
.data
   a dq ?
   b dq ?
   s dq ?
.code

; ******************************************************

main proc
       
    invoke printf,TXT(" please input a and b ")
    invoke scanf,TXT("%ld%ld"),addr a, addr b
    mov rax,a
    add rax,b
    mov s,rax
    invoke printf,TXT(13,10," a+b=%ld",13,10),s
    invoke _getch

   ret
main endp
end

Hi ToutEnMasm,

Nice work using your SDK. The executable depends on some exta DLLs.

\PellesC\bin\podump.exe /IMPORTS Downloads\demo.exe | findstr ".dll"

        api-ms-win-crt-conio-l1-1-0.dll
        VCRUNTIME140.dll
        KERNEL32.dll
        api-ms-win-crt-runtime-l1-1-0.dll
        api-ms-win-crt-math-l1-1-0.dll
        api-ms-win-crt-stdio-l1-1-0.dll
        api-ms-win-crt-locale-l1-1-0.dll
        api-ms-win-crt-heap-l1-1-0.dll

It is write under Windows 10 with all the official libraries of the windows SDK and of the visual studio C++.
If you write it in C , you wull have exactly the same dll needed.

DLLs yes, libraries NO. You have not addressed CRT clashes with MASM reserve words yet. If you want to use C libraries, write in C.

Quote
DLLs yes, libraries NO. You have not addressed CRT clashes with MASM reserve words yet. If you want to use C libraries, write in C.

Have a look to the editmasm.ini who show all the path of the libraries: Libraries (all are of the last VS version and last SDK version)
libraries yes
Protototypes are the masm prototypes and all includes are write in masm syntax.
It is pure masm syntax who don't need complex macros to avoid conflicts between libraries.
Without conflict between libraries code can be far more simple,there is only one macro in use TXT.

Hi ToutEnMasm,

Your example can be assembled to import functions only from kernel32.dll and msvcrt.dll :

include     \masm32\include64\masm64rt.inc

.data

a   dq ?
b   dq ?
s   dq ?

.code

start PROC

    invoke  vc_printf,"Please input a and b"
    invoke  vc_scanf,"%ld%ld",ADDR a, ADDR b
   
    mov     rax,a
    add     rax,b
    mov     s,rax
   
    invoke  vc_printf,\
            chr$(13,10," a+b=%ld",13,10),s

    invoke vc__getch

    invoke  ExitProcess,0

start ENDP

END


The final executable is just only 1.5 KB

Yves,

You are still missing something, ML64 does not need the old prototypes. If you look in the import libraries there is no linker information. Below is all you need in ML64, your includes may be useful in UASM but ML64 does not use the same method as the old ML for prototypes.

externdef __imp_AddAtomA:PPROC
AddAtomA equ <__imp_AddAtomA>
  IFNDEF __UNICODE__
    AddAtom equ <__imp_AddAtomA>
  ENDIF

externdef __imp_AddAtomW:PPROC
AddAtomW equ <__imp_AddAtomW>
  IFDEF __UNICODE__
    AddAtom equ <__imp_AddAtomW>
  ENDIF

externdef __imp_AddConsoleAliasA:PPROC
AddConsoleAliasA equ <__imp_AddConsoleAliasA>
  IFNDEF __UNICODE__
    AddConsoleAlias equ <__imp_AddConsoleAliasA>
  ENDIF

Sorry but it is write with UASM and his prototypes are modern (Windows SDK prototypes translated) ,not old (you need to invert your affirmation).
The old are those you have made (hutch proto) for ML64 who accept this prototypes without controling of the arguments.
Microsoft have done ML64 to replace the inline assembler of the C++.
That is something very limited in memory,and more...and bugged
The new couldn't be no verify of the arguments passed by the prototypes.
A compiler need to verify the human work.
The prototypes you have write for ml64 don't allow any verify of the arguments (there is one case where ml64 could verify arguments with modern proto).
That is dinosaure prototypes not new. :joking: (to be more exact ,machine proto first level of library)

ML64 is for assembler programmers with enough experience to use it, hand holding belongs to the past. ML64 with 64 bit MASM is already application capable, I wonder why we don't see working applications from other "civilised" assemblers ?

You probably should stick to UASM where they need a comprehensive collection of prototypes, 64 bit MASM does not need them.

Ok,prototypes are useless and verify the writing is also useless,I will return perhaps to binary code
1010111
1110011
That was enough for today. :thumbsup:

Yves,

You can go high level, write the code in HEX.

Quote from: TouEnMasm on November 22, 2020, 03:34:39 AM
Ok,prototypes are useless

Absolutely useless! Only Bill Gates knows why they invented them. Real men^TM don't need that type checking crap as in C/C++, they count and check their arguments by hand - push push push in 32-bit code, mov rdx, xxx in 64-bit code :cool:

The Solar Assembler and Flat Assembler does not need prototypes.

Quote from: Vortex on November 22, 2020, 06:55:17 AM
The Solar Assembler and Flat Assembler does not need prototypes.

in old ml I seen invoke something that is below needs proto,but when its just make PROC without any arguments,using call works without proto

Hi daydreamer,

Here is another invoke macro implementation declaring the external functions. While it does not use prototypes, you need to be careful to specify the ANSI\UNICODE version of the API functions.

With 64-bit Assembly, I always use jinvoke (no PROTOs btw) :tongue:

jinvoke CreateWindowEx, WS_EX_CLIENTEDGE, Chr$("RichEdit20A"), NULL,\
reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance
mov hEdit, rax ; you may need this global variable for further processing
xchg rax, rbx ; use a persistent register for the handle
jinvoke SendMessage, rbx, WM_SETTEXT, 0, MyR4
Tmp_File.asm(31) : Error A2114: forced error: ## not enough arguments for CreateWindowEx ##
** Warning, line 35: passing a REAL4 may not work **

Oops, it seems I forgot the lParam - what a lousy coder I am :sad:

 :biggrin:

We have all heard this sobbing before, ML clone users have problems with real low level assembler, they don't know how to count and want the assembler to do it for them. Who cared about the documentation where you need to be able to read, the assembler should be able to do it for them.

Do you need the author of the assembler to hold your hot little hand and lead you through the complexities of something that you are too dumb to comprehend when you could be using PHP or JAVA or a nice soft script kiddie's script language instead of a nasty professional tool that bites the hand that feeds it ?

You don't need a tool that is sharper than a razor blade when you could be using a nice soft easy powder puff designed for server side scripting. There is a big wide wonderful world out there where you can write garbage like the rest and feel profound about it.  :tongue:

 :biggrin:

You can tell the men from the boys by the paper they use. Large sheet of xxxx grade sand paper hanging off a nail in the loo.  :badgrin:

Quote
We have all heard this sobbing before, ML clone users have problems with real low level assembler, they don't know how to count and want the assembler to do it for them. Who cared about the documentation where you need to be able to read, the assembler should be able to do it for them.

Human (including Hutch) are just ridiculous when they count in place of a machine.The machine just do about 1 million of calculations by second when the human haven't just started.
But if it is your pleasure to count each jump instead of let's it done by the machine,do it.

No, Yves, Real Men^TM don't need to count the arguments, and they don't produce bugs! The others can go for C/C++, where argument counting and type checking is, of course, obligatory :cool:

@Yves: Perhaps we could register at a C++ forum, and try to convince them that type checking is not necessary, what do you think? We might become very popular, even famous :mrgreen:

Buffoon or REAL men ,keep your sentance for you .

He he, their is a wonderful wide world out there where the authors hold your hot little hand and you don't have to play with nasty things like professional tool that already deliver applications that work. You know the line about XXXX grade sandpaper in the loo. In a world where programmers can't count and can't read the reference material, you always have server side scripting to feel profound about.  :tongue:

Try this but beware, you have to know how to count and read at the same time.

invoke SendMessage, \       ; the function read from the reference material
            hWhatever, \    ; number 1
            WM_COMMAND, \   ; number 2
            100, \          ; number 3
            0               ; number 4

Difficult isn't it ?

Now doesn't someone holding you poor hot little hand look so much easier ?

Quote from: jj2007 on November 23, 2020, 08:30:50 PM
No, Yves, Real Men^TM don't need to count the arguments, and they don't produce bugs! The others can go for C/C++, where argument counting and type checking is, of course, obligatory :cool:

@Yves: Perhaps we could register at a C++ forum, and try to convince them that type checking is not necessary, what do you think? We might become very popular, even famous :mrgreen:

well if you prefer type lots of shifts,altgr combos and do typing that typecasting requires on loads of types,that you dont need in assembler,go ahead
for example:
myicon=(HICON)LoadImage(
SendMessage(hWnd,WM_SETTEXT,(LPARAM)text,NULL);
and many more+ it leads to frustrating time spent for CPP beginners getting those kinda wrong types errors and solve
yes you can have small windows program if you strip it off the two icons,but  in earlier than win10,needs to download few megabytes Cpp runtime to work

maybe need to create a "spoonfeeding" script for newbies? :biggrin:

another annoying Cpp I had many years ago was changes of versions every now and then,I wasted loads of times to try make game programming for dummies CD's example work and libraries and it was impossible because it was completely different CPP versions,so I gave up:(