Option Literals:on "\n"

[aw27]

This too bad JJ,  :( :( :(
And now I see the reason you say that MASM is getting worse at every edition.   

Let's try it without using the macros. 

Code Select Expand


.386

.model flat, stdcall
option casemap :None

includelib \masm32\lib\kernel32.lib
GetStdHandle proto :dword
WriteFile proto :dword, :ptr, :dword, :ptr, :ptr

includelib \masm32\lib\msvcrt.lib
printf proto C :ptr, :vararg
strlen PROTO C :ptr

.data
format0 db "MASM 'specific characters' that need to be escaped (lol) <,>,!,(,)",13,10,0

.code

STD_OUTPUT_HANDLE equ -11

main proc
LOCAL bWritten : dword
LOCAL theLen : dword
LOCAL theHandle : dword

;1- Using GetStdHandle\WriteFile
Invoke strlen, offset format0
mov theLen, eax
Invoke GetStdHandle, STD_OUTPUT_HANDLE
mov theHandle, eax
Invoke WriteFile, theHandle,offset format0,theLen, addr bWritten,0

;2- Using msvcrt printf
invoke printf, offset format0
ret

main endp

end main


Output:

MASM 'specific characters' that need to be escaped (lol) <,>,!,(,)
MASM 'specific characters' that need to be escaped (lol) <,>,!,(,)

[hutch--]

 

> Another interesting fact about the  cfm$ macro is that it invented  "masm specific escapes" like \l for <, \r for >, \x for !, \a for ( and \b for ). The most amazing is not that its steals the "\r" (carriage return escape), the most amazing is that the escapes are absolutely unnecessary both for msvcrt prinft and for the GetStdHandle\WriteFile used by the print macro.

The other amazing factor is it has been working perfectly for years and is not locked into the assumption level of high level languages but then it IS MASM.  :P It writes to the screen correctly, can be redirected correctly and provides a few extra escapes that plug a hole in MASM's ancient macro notation.

[aw27]

The other amazing factor is it has been working perfectly for years and is not locked into the assumption level of high level languages but then it IS MASM.  :P It writes to the screen correctly, can be redirected correctly and provides a few extra escapes that plug a hole in MASM's ancient macro notation.

I don't think so, see my example above. It redirects perfectly. :t

[jj2007]

http://masm32.com/board/index.php?topic=5250.0

Yep, I knew I had seen that before, thanks for reminding me

[hutch--]

 

> I don't think so, see my example above. It redirects perfectly

Yes but you have to use a high level language runtime to do it where MASM can use the API without that assumption and it is because MASM is a macro assembler. There are those of us who don't see assembler just as an accessory to some other high level language.  :P

[nidud]

deleted

[aw27]

Yes but you have to use a high level language runtime to do it where MASM can use the API

Actually MSVCRT.DLL is an operating system DLL, not a C runtime.
This is the situation since Windows 95.

[hutch--]

That is a re-translation that does not work. Look at the name, the source and the format.

MS = Microsoft
VC = Visual C
RT = Runtime

It mirrors much of the C runtime library, it is not a Windows API DLL and it is almost exclusively in C format, not the API STDCALL.

[aw27]

That is a re-translation that does not work. Look at the name, the source and the format.

MS = Microsoft
VC = Visual C
RT = Runtime

Were Microsoft in a position to give a new name of this historic msvcrt.dll without breaking thousands of applications it would have been done 20 years ago. As you know no company loves more changing names of things than Microsoft.

It mirrors much of the C runtime library, it is not a Windows API DLL and it is almost exclusively in C format, not the API STDCALL.

There is no specific C format, C functions can use any calling convention, as you know, and 99% of Windows is done in C. The Cdecl is similar to the stdcall, but is best for variadic functions, which abound in that msvcrt.dll. That was probably the reason for not compiling it for stdcall use. On the other end millions of DLLs exist that export stdcall functions and are not part of the Windows API. I don't think the calling convention should be the criteria for deciding if a DLL is part or not of the operating system. 

[nidud]

deleted

[hutch--]

Herein lies the difference, the reference material for the functions in MSVCRT is what it used for the normal C libraries whereas the Windows API functions are not, MSVCRT is what it says it is, a C runtime DLL that has been included in the OS versions since about Win95b. Everyone knows that STDCALL and C calling conventions are different so there is little point in trying to claim they are the same.

> Were Microsoft in a position to give a new name of this historic msvcrt.dll without breaking thousands of applications it would have been done 20 years ago

Have you seen the number of MSVC????.DLL versions there are ? They have long ago renamed their C runtime DLLs but left the old one alone.

> Or the re-translation of printf to ctr_printf, and then hog up these names with macros like exit() and printf().

That is because MASM is not VC and is not bould to give any credence to other languages naming conventions. Behind that statement is the assumption that assembler is a sub set of the C language where in fact it is not.

> Keep in mind that most of the .LIB files included with MASM32 loads msvcrt.dll and use these functions.

This is claptrap, the entire project uses some MSVCRT function calls which are mainly in macros but the vast majority of the MASM32 library is written in assembler and the source is there to prove it.

[aw27]

This is claptrap, the entire project uses some MSVCRT function calls which are mainly in macros but the vast majority of the MASM32 library is written in assembler and the source is there to prove it.

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.

Many of them are used all around the SDK.

Behind that statement is the assumption that assembler is a sub set of the C language where in fact it is not.

It is not. Also C uses MASM without being a subset of MASM. 

[nidud]

deleted

[aw27]

Not to mention that the user.dll exports Cdecl "API functions" like wsprintf, which are frequently used within the SDK.
I think we covered all aspects of the problem.  :t

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

[jj2007]

see my example above. It redirects perfectly. :t

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

But the whole point of macros like chr$() and cfm$() is that you can see what you want to write in context, not as WriteFile xyz, someobscurepointer. The line print "Hello World" is much easier to read and understand. This is why "high level languages" were created. BASIC was the first major milestone there, but with the slow old machines, programmers were forced to use BASIC and assembly in parallel. Then, many years later, K&R decided to abandon BASIC and lift assembly to a higher level of abstraction, and to call it "C". The new "HLL" was almost as fast as assembly, but, as we still can see half a century later, it also maintained its closeness to the metal: pointers all over the place, the need to allocate and free explicitly even a simple hello world string, etc. The fact that M$ has to update the OS every month, and Adobe lost her reputation as a serious software company, is attributable to the habit of C/C++ to introduce bugs easily (I am trying to blame the language for the bugs, knowing how sensitive her programmers are )

In any case, please stop alluding that there is any parental relationship between C and assembly. Our baby was around long before K&R started their clumsy attempt to make assembly "easier".

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