Hi,
I tried several ways of working with unicode strings and what I post here is what I did better for my needs. It's like a pseudo BSTR without any needs of SysAllocString because the strings are declared directly in the .DATA section. Tree macros are doing the job and I included a test program as a demo.
Let me know your comments or possible improvment that could be made on it.
BStrData MACRO LabelName:REQ, Text:REQ
lbl textequ <&LabelName>
bypass = 0
count = 0
forc chr, <&Text>
if bypass ne 0
if '&chr' eq 'n'
count = count + 2
else
count = count + 1
endif
bypass = 0
elseif '&chr' eq "/"
bypass = 1
else
count = count + 1
endif
endm
align 4
dword count
forc chr, <&Text>
if bypass ne 0
if '&chr' eq '/' ; // = slash
lbl word '/'
elseif '&chr' eq 'a' ; /a = apostrophe or single quote
lbl word "'"
elseif '&chr' eq 'e' ; /e = exclamation
lbl word '!'
elseif '&chr' eq 'n' ; /n = new line
lbl word 13,10
elseif '&chr' eq 'p' ; /p = percent
lbl word '%'
elseif '&chr' eq 'q' ; /q = double quote
lbl word '"'
elseif '&chr' eq '{' ; /{ = parenthese open
lbl word '('
elseif '&chr' eq '}' ; /} = parenthese close
lbl word ')'
elseif '&chr' eq '[' ; /[ = chevron open
lbl word '<'
elseif '&chr' eq ']' ; /] = chevron close
lbl word '>'
else
.err <BStrData macro error: You have used an invalid option after the slash>
endif
bypass = 0
lbl textequ <> ; prevent label redefinition
elseif '&chr' eq "/"
bypass = 1
else
lbl word '&chr'
lbl textequ <> ; prevent label redefinition
endif
endm
word 0 ; null char terminator
ENDM
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@BStrSize MACRO LabelName:REQ, WithNull:REQ ; Bytes
mov eax, offset LabelName
mov eax, dword ptr [eax-DWORD]
add eax, eax
if WithNull ne 0
add eax, WORD
endif
exitm <eax>
ENDM
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@BStrLength MACRO LabelName:REQ, WithNull:REQ ; Characters
mov eax, offset LabelName
mov eax, dword ptr [eax-DWORD]
if WithNull ne 0
inc eax
endif
exitm <eax>
ENDM
EDIT: I added an error message in the BStrData macro in case of invalid option after the slash.
[attachment deleted by admin]
Your code is very good. Are you aware of cross platform compatibility issues? Are you aware also that a system upgrade could break your application?
This is fine for active development and non critical applications. Keep in mind the compatibility factor. You must you the SysAlloc procedures to avoid these issues. Also you should consider using procedures instead of macros. It will make your codes easier to debug. I am a beginner with assembly programming, but I do believe macros are for making short work and extending the language processing.
I have not tested your code but it appears very advanced. Great work. You should consider making your own High Level MASM language. Several hundred thousand others as well as myself would be very interested in a customizable macro assembler language pre processor with high level style Try Catch error checking. You seem to have a talent for macros. By all means use it!
Hi ttaylor,
Not usually the one to look at a thread containing macros but I stumbled in here, I'm of the school that macros generally just obfuscate code and that making assembler into a crippled version of C doesn't really make sense. But if you want to look at a MASM preprocessor you might like this one by Biterider et al...
http://objasm32.tripod.com/index.htm#start
ttaylor,
Don't be mislead, I'm not a good macro writer and I wrote this one long time ago and I just saw that it have errors. The 4 bytes before the string pointer of a BSTR should be the bytes count (without the null-char) and not the characters count. Also, the variables should be declared as local.
In fact, I'm of the same school of Donkey about macros and I never use them in the .CODE section. But to easily build unicode strings in the .DATA section, there's not a lot of solutions and a macro do the job perfectly.
I don't mean to steal your thread doe, take a look at my post here: http://www.winasm.net/forum/index.php?act=ST&f=13&t=2852&st=0#entry14427.
It is the best way to do BSTR data (for Visual Basic 6.0; Tested.) Unicode conversion is not needed. Simple and easily included into your projects.
Quote from: donkey on January 20, 2009, 11:12:10 AM
Hi ttaylor,
Not usually the one to look at a thread containing macros but I stumbled in here, I'm of the school that macros generally just obfuscate code and that making assembler into a crippled version of C doesn't really make sense. But if you want to look at a MASM preprocessor you might like this one by Biterider et al...
http://objasm32.tripod.com/index.htm#start
I am familiar with the project and sources. I don't really care for the programming style. (Or documentation and the lack of a dedicated and guided development environment)
If you read this post and are looking to HL Convert MASM, Take a few notes from Randal Hyde and the Objasm32 project, AND focus PRIMARILY on Visual Basic Style Programming as well. I have read posts from C coders stating that there is no better R.A.D. development system in the world. On a personal note Steer pretty darned clear of implementing managed code or types. That was the downfall of Microsoft Basic. It sucked all the power out the language like a 75 watt bulb powered by a 9V battery.
Quote from: ttaylor on January 20, 2009, 10:26:56 AM
...You should consider making your own High Level MASM language. Several hundred thousand others as well as myself would be very interested in a customizable macro assembler language pre processor with high level style Try Catch error checking...
Not to fan any flames here, but have you seen RosASM and it's preprocessor/macro language? Google for the website address.
Quote from: ttaylor on January 20, 2009, 02:02:54 PM
It is the best way to do BSTR data (for Visual Basic 6.0; Tested.) Unicode conversion is not needed. Simple and easily included into your projects.
ttaylor,
I take no offense in your comments. :wink
My macro will fail with many languages other than english and I'm perfectly aware of that. Again, this macro does what it have to... but you can be in the opposite opinion, it is your right.
Quote from: ttaylor on January 20, 2009, 02:12:04 PM
I am familiar with the project and sources. I don't really care for the programming style. (Or documentation and the lack of a dedicated and guided development environment)
If you read this post and are looking to HL Convert MASM, Take a few notes from Randal Hyde and the Objasm32 project, AND focus PRIMARILY on Visual Basic Style Programming as well. I have read posts from C coders stating that there is no better R.A.D. development system in the world. On a personal note Steer pretty darned clear of implementing managed code or types. That was the downfall of Microsoft Basic. It sucked all the power out the language like a 75 watt bulb powered by a 9V battery.
Not really in the market for any HL stuff, I use GoAsm exclusively, it is fairly low level in that it doesn't support most of the high level constructs like IF/THEN/ELSE or REPEAT/UNTIL etc and the lack of a powerful macro engine in it doesn't affect me much since I have use for only 2 or three macros and they are very simple ones. But I do understand that some are looking for this kind of stuff and outside of a few rants about it not being assembly I generally steer clear of the macro/HL threads.