I created a printf macro that prints to a console.
When I type something like:
mov eax,10
printf "the value of the eax register is %d \n", eax
I get:
the value of the eax register is 10 \n
Anyone who's done any programming in C will realize that the \n appears instead of going to a new line.
Does anyone know of a way to make my masm treat strings like C strings or something similar.
My Idea is simply:
Make last parameter \n like macro value
(i mean printf string,function)
And then compare in macro value 'function' win \n,\a,\t...
My Idea is simply:
Make last parameter \n like macro value
(i mean printf string,function)
And then compare in macro value 'function' win \n,\a,\t...
After comparing, add to 'string' bytes 10,13.
You could go thru LOTS of trouble to parse out strings like "\n" to do something like that. I did it once for my "L" macro (defines unicode strings, see here.is/COMinASM or the new masm SP), but it made sense there as I was forced to parse out every char anyway.
Your macro will need to go thru every character and build up the results. You should be able to adapt something from "L"
Incidentally, trying to write a macro named "\n" will yeild:
error A2109: only white space or comment can follow backslash
Oh heck, here's L:
;----------------------------------------------------------------
; L.inc Macro to produce wide character strings
;
; copyright (c) July 30, 2000 Ernest Murphy
; For educational use only. Any commercial re-use only by written license
;
;----------------------------------------------------------------
wchar typedef word
L MACRO sText:REQ
LOCAL str, chr, flag
;; generates a wide character string
;; useage: sztext wchar L()
;; generates: sztext WORD "H","e","l","l","o","," ",
;; "W","o","r","l","d","!","!",0
;; max string length is 57 chars (MASM line length limit)
;; use multiple non-zero term strings in sequence for longer strings
;; (zero term the last of course)
str TEXTEQU < >
flag TEXTEQU <.>
FORC chr, <&sText>
IFDIF flag, <\>
IFDIF str, < >
str CATSTR str, <,>
ENDIF
ENDIF
IFDIF flag, <\>
IFIDN <&chr>, <\>
flag CATSTR <\>
ELSE
str CATSTR str, <">, <&chr>, <">
ENDIF
ELSE
flag CATSTR
;; check for a pipe (exclamation point)
IFIDN <&chr>, <|>
str CATSTR str, <"!!">
flag CATSTR
Satrukaan,
Ernie's point is correct, a "\" character cannot have other characters after it without generating an error, in MASM, it is a line continuation character.
You are trying to do 2 different things when you display the string in the manner that you want,
1. display a string
2. convert a register to ascii string and display it as well
I have seen approximations but they will not do the normal printf formatting as printf is a compex function that has a reasonably high overhead.
I have never found any problem using the standard API code to display text to the console, with a value you need to convert it first and then concantenate it to the end of the string you have before it.
Regards,
hutch@pbq.com.au
Actually I did use standard api calls.
more precisely I used wsprintf along with a writeFile
the macro is like 4 lines long.
I just thought there would be some sort of mechanism like "\n" in assembly strings.
currently my solution is to do a %s wherever I need my \n and stick use a string only containing the carrage return and line feed. I think this is what SEL suggested. I thought there might be a way to include the CRLF directly into the string somehow instead of adding more parameters
One DUH!! forehead slapping thought I just had is to add the string to your resource file, where /n and all that good stuff get parsed as you expect.
that's a very cool idea.
currently my macro requires the first parameter to be a string and includes it into the data section.
How do I get it to detect if it's a string or a string resource
so it would either include it in the data section or do a load string?
I think it has something to do with OPATTR but I don't know how to use it to accomplish this.
that's a very cool idea.
currently my macro requires the first parameter to be a string and includes it into the data section.
How do I get it to detect if it's a string or a string resource
so it would either include it in the data section or do a load string?
I think it has something to do with OPATTR but I don't know how to use it to accomplish this.
I've never played with OPATTR myself, here's what the manual says:
bit Set if expression
0 references a code label
1 Is mem var or has relocate data label
2 is an immediate var
3 uses direct mem addressing
4 is a reg value
5 ref no unidentified symbols and is w/o error
6 Is relative to SS
7 Refs an external label
8-10 has following type:
000 no lang type
001 C
010 SYSCALL
011 STDCALL
100 Pascal
101 FORTRAN
110 Basic (QB, not VB) ;-)
So... if I read this correctly, you can determine a string in .data since bit 1 will be set, but a resource string will not be such.
(WARNING: UNTESTED CODE FOLLOWS)
StringThing MACRO StrRef:REQ
IF (OPATTR (StrRef) AND 2
; {MACRO code for the StrRef in .data}
ELSEIF
; {MACRO code for the StrRef in a resource}
ENDIF
ENDM
Good luck. :-)
Most programming languages don't really provide a way to inline special characters in strings. You only need to think of Pascal (use CHR function) and Basic (use CHR$ function). Assembly languages haven't yet, as far as I know.
Most of the languages I know that allow special characters are derived from C. (Although I have seen languages using $ as an escape rather than \.) Sven Schreiber, who did WALK32 for MASM, created a macro which generated UNICODE and used forward slash (/) as an escape.
Which reminds me...does MASM have a way to generate UNICODE as easily as ANSI/ASCII ? The only reason you can't do
DW 'AB'
to produce UNICODE is that it would be ambiguous. Legacy code expects this to produce a single 16-bit value, instead of two 16-bit characters.
A Unicode string can be made like so:
WideStr word "H", "E", "L", "L", "O", " ", "W", "O", "R", "L", "D", 0
That's the whole trick behind the L macro above, taking a string you give it and letting the macro insert the other junk.
Yes, I've known how to handle most of it with macros.
A built-in facility would be useful for directly handling ' and " characters, though. For now, it looks like I have to use macros and work around its limitations on character manipulations.