" or '?

[n00b!]

.

[hutch--]

noob,

An AND is an AND and an OR is an OR. Look up the two instructions, they do different things.

The order of text when using larger than BYTE is determined by the memory order that the data is written under. Byte data is written left to right in memory, larger data types (WORD DWORD etc ...) are written right to left. FASM for example reverses the text so the "Test" in FASM is identical to "tseT" in MASM and most others.

[jj2007]

Is there a difference between " and '?

Yes and no. In practice, you will see more often "double" quotes, i.e. chr$(34); single quotes are handy if you need double quotes inside a string. Here are a few examples.

Code Select Expand

include \masm32\include\masm32rt.inc

.code
MyText db "Hello World", 0
AppName db 'Masm32 supports two types of "quotes": ', 0

start:
MsgBox 0, addr MyText, addr AppName, MB_OK
MsgBox 0, "Hello World", addr AppName, MB_OK
MsgBox 0, " ' Hello World ' ", addr AppName, MB_OK
MsgBox 0, chr$('Hello World'), addr AppName, MB_OK
MsgBox 0, chr$(' " Hello World " '), addr AppName, MB_OK
; this one does NOT assemble because the macro does not check for single quotes:
; MsgBox 0, 'Hello World', addr AppName, MB_OK
exit

end start

[hutch--]

Sorry noob, I did not read the question properly. (Been working on a custom control all day).  :eek

[PBrennick]

noob,

This works, also:

Code Select Expand


AppName db "Masm32 supports two types of ", 34, "quotes", 34, ":",  0


I always think in hex, it seems, though; so I would usually use 22h instead of 34 though it does not matter at all.

-- Paul

[japheth]

noob,

This works, also:

Code Select Expand


AppName db "Masm32 supports two types of ", 34, "quotes", 34, ":",  0


And this works as well - similar to C:

Code Select Expand


AppName db "Masm supports two types of ""quotes"":",  0


[jj2007]

   MsgBox 0, "Hello ""World"", how's life?", addr AppName, MB_OK

[n00b!]

.

[jj2007]

Is this so? :-/

For all practical purposes, stick to these examples:

My$ db  "Test", 0
AppName db "MyApp:", 0
invoke MessageBox, 0, addr My$, addr MyApp, MB_OK
invoke MessageBox, 0, chr$("Test"), addr MyApp, MB_OK

mov edx, offset My$
mov eax, [edx]
cmp eax, "tseT"
jne somewhere
mov ecx, "tseT"
cmp ecx, [edx]
jne somewhere

Rough rule: invert only when you substitute a dword number as in mov eax, 12345 with its text equivalent

[n00b!]

.

[AeroASM]

mov a, 288191                                        ;288191 would be reversed by putting it in a
   mov eax, a                                                   ;reversed 288191 would be read out of memory, so it's reversed again and the value is again 288191
   invoke MessageBox, NULL, ustr$(eax), 0, MB_OK     ;MessageBox(288191)

mov a, 288191                                       ;288191 would be reversed by putting it in a
   invoke MessageBox, NULL, ustr$(a), 0, MB_OK        ;Why does it not display reversed 288191

I tested a bit with the Strings and that rule I wrote upper seems to work (If I'm wrong please tell me!),
but why it's not working with the 288191 is confusing me again.....

ustr$(a) reverses it again because it is taken out of memory. with ustr$(eax), no more reversal happens because it is already in a register.

[n00b!]

.

[MichaelW]

For words, dwords, and qwords the bytes as stored in memory are reversed relative to the "normal" order, so the least significant byte is stored at the lowest address and the most significant byte at the highest address. The storage order in memory must be considered when you access some sub-unit of a value. For example, for a dword stored at address 403000h you would access the most-significant word at address 403002h.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
        m8 dq 1122334455667788h
        m4 dd 11223344h
        m2 dw 1122h
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    print "1122334455667788h",13,10
    xor ebx, ebx
    .WHILE ebx < 8
      movzx eax, BYTE PTR [m8+ebx]
      print uhex$(eax)," "
      inc ebx
    .ENDW
    print chr$(13,10,13,10)

    print "11223344h",13,10
    xor ebx, ebx
    .WHILE ebx < 4
      movzx eax, BYTE PTR [m4+ebx]
      print uhex$(eax)," "
      inc ebx
    .ENDW
    print chr$(13,10,13,10)

    print "1122h",13,10
    xor ebx, ebx
    .WHILE ebx < 2
      movzx eax, BYTE PTR [m2+ebx]
      print uhex$(eax)," "
      inc ebx
    .ENDW
    print chr$(13,10,13,10)

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


Code Select Expand


1122334455667788h
00000088 00000077 00000066 00000055 00000044 00000033 00000022 00000011

11223344h
00000044 00000033 00000022 00000011

1122h
00000022 00000011


If you had a 4-byte string defined as:

str1 db "abcd"

Then to compare it as a dword you could do something like this.

mov eax, BYTE PTE str1
cmp eax, "dcba"

For general-purpose string comparisons you would normally loop through the strings comparing bytes, but for longer strings you could do most of the comparisons as dwords and then compare any remaining bytes as bytes.

[Mark Jones]

PS:
3. Can I compare more then 1/2/4 Bytes?
Maybe like    cmp eax, "abcdefghijk"

No. Well, it should be possible to do QWORDS on a 64-bit processor, but x64 assembly programming is much harder than 32-bit. Anyways, like Michael said, to compare strings > 4 bytes, another method needs to be used.

Generally, the syntaxes you are presenting (CMP something,"tseT") occur rarely in general coding practice. If you're working with strings, most strings are longer than 4 bytes, and are handled by either API functions (lstrlen, lstrcmp, lstrcpy, etc.) or handlers you write yourself. For instance, this old code "reads" ASCII null-terminated strings byte-by-byte, parsing them appropriately: http://www.masm32.com/board/index.php?topic=1073.0

P.S. sheesh the board is slooooooooooooow right now, what's up?

[jj2007]

P.S. sheesh the board is slooooooooooooow right now, what's up?

Indeed! This morning it was still ok...