Missing operator in expression

[Kalx]

Hi,
I was writing my n00b level code to output the address of the PEB,but an error "missing operator in expression" where there's

Code Select Expand

MOV eax,[fs:0x30] keep popping up.

Code Select Expand

.386

.model flat,stdcall
option casemap:none

include \masm32\include\masm32rt.inc

.data


.code


start:

    XOR eax,eax
    MOV eax,[fs:0x30]
    print "eax = "
    print str$(eax),10,13
    inkey "pause"
    invoke ExitProcess,NULL
               
end start

Thanks to those who'll help :)

[habran]

Try MOV eax,[fs:30h]  instead of MOV eax,[fs:0x30]

[Kalx]

The error changed,now on the same line " error A2108: use of register assumed to ERROR"

[nidud]

deleted

[Kalx]

Well,now masm go fine but the exe doesn't output anything. I'm sure that this is another kind of problem.

[rrr314159]

Hi Kalx,

All I can figure is you are using only the 3 lines nidud gave; he didn't mean u should take out the other lines which do the printing! Here's everything needed:

Code Select Expand

include \masm32\include\masm32rt.inc
.code

start:

    assume fs:nothing
   
    MOV eax,fs:[30h]
    print "eax = "
    print str$(eax),10,13
    inkey "pause"
    invoke ExitProcess,NULL
               
end start

[dedndave]

the contents of EAX are destroyed when you print "eax="   :P

Code Select Expand

        print   "eax = "

        ASSUME  FS:Nothing

        mov     eax,fs:[30h]

        ASSUME  FS:ERROR

        print   str$(eax),13,10
        inkey
        exit

[rrr314159]

woops, you're right ::)

I got an answer printed ("6") and ass-umed it was the right one

[dedndave]

length of the string "eax = " = 6
the StdOut routine returns the length, and is used in the print macro

[nidud]

deleted

[rrr314159]

True, but still doesn't explain why Kalx didn't see anything print out. Presumably I'm right, he removed all the print statements? Can't see any other explanation. Perhaps we'll never find out.

First thing I did (when I figured out what a macro was, and discovered macros.asm) was rewrite all the macros I use. My "prnt" macro preserves registers because there's absolutely no reason to return the count in eax; and no reason for speed since "print"ing takes so long. That's my excuse for forgetting this weird behavior.

Note that my "sprnt" macro does return the character count, like sprintf. Makes perfect sense when you're printing to a buffer. Admittedly it also made sense long ago when printf returned the character count, dealing with physical printers ... but no longer does today.

BTW I've posted all my macro-replacements for macros.asm here and there, latest versions work with both 32 and 64 bit, and have come up with dozens of new ones. I notice many of them jj2007 has done also, in MasmBasic, years ago ... I got a couple of the ideas from him, but mostly it's a case of convergent evolution

nidud: All these macros may be a bit confusing ...

the problem with them is very simple: they're non-standard. If everyone used the same there'd be no problem. ... no doubt it's time for a thorough upgrade to macros.asm, so newbies wouldn't feel the need to improve them

[Kalx]

Ok,neither the code of nidud nor my code output something.
The code of nidud is in his own post,mine is this:

Code Select Expand

.386

.model flat,stdcall
option casemap:none

include \masm32\include\masm32rt.inc

.data


.code


start:

    ASSUME fs:NOTHING
    MOV eax, fs:[30h]
    ASSUME fs:ERROR
    print str$(eax),13,10
    inkey
    exit     

end start

If this two code work in every computer but mine,maybe the cause is the compile time option?
I use thse (I've a folder called workspace inside the masm32's folder and i call ml and link from there) :

Code Select Expand

..\bin\ml /c /coff proj1.asm

Code Select Expand

..\bin\link /SUBSYSTEM:WINDOWS /LIBPATH:..\lib proj1.obj
P.s:I'm very glad to see that this is an active community

[hutch--]

> the problem with them is very simple: they're non-standard. If everyone used the same there'd be no problem. ... no doubt it's time for a thorough upgrade to macros.asm, so newbies wouldn't feel the need to improve them

There IS a reason why a single file is used in MASM32, so it IS standard. Everyone is free to write their own but the supplied versions have worked correctly for a long time and they are documented properly.

[jj2007]

the problem with them is very simple: they're non-standard. If everyone used the same there'd be no problem. ... no doubt it's time for a thorough upgrade to macros.asm, so newbies wouldn't feel the need to improve them

There are a two or three macros that could be polished a little bit, but 99% work surprisingly well. And compared to any other assembler package I've seen, Masm32 is a very high standard.

Code Select Expand

..\bin\link /SUBSYSTEM:WINDOWS /LIBPATH:..\lib proj1.obj

To see console output, you need /SUBSYSTEM:CONSOLE

[rrr314159]

@Kalx, sure, subsystem:console

@hutch, you're right, why "fix something that ain't broke"?

There are a two or three macros that could be polished a little bit, but 99% work surprisingly well.

- AFAIK they work fine (ignoring for now 64-bit), do exactly what they're supposed to do. One might want to "polish" them. For instance, as mentioned, I think print shld preserve registers, don't need the byte count. (In situations where you do, u'd print to buffer, using sprintf macro.) Also some macros seem redundant to me ... but this is all definitely a matter of opinion. Others will disagree. Up to hutch of course, but I agree attempting to "improve" macros.asm was not a good idea - fixing something that ain't broke.

- Instead people wind up augmenting them as they like, which causes the nonstandard situation. Just like Linux, it would be more "commercial" with only one version; but that's not really possible.

- MasmBasic includes an augmented set of macros which could be considered an enhanced macros.asm - the most successful I know of. (BTW notice that "deb" doesn't return byte count in eax! I assume) This is the best/only way to do it: produce your own candidate "better" macros package and hope everyone uses it (roughly speaking). But as with Linux, probably no "standard package" can get more than, say, 20 or 30% of users.

- Talking about standardizing I'd say it's more important to standardize on an assembler, like H/JWasm, which is the most popular around here (and my fave). But there are other worthy candidates, all with happy users, so that's not gonna happen any big hurry either. MASM is stuck with "too many versions", so, look on bright side: diversity, freedom of choice, Open Source Software, etc.

And compared to any other assembler package I've seen, Masm32 is a very high standard.

- Sure, we're all very happy with it. VisualMASM? Randall Hyde HLA? ;) Note even HLA (and other, more useful, "environments") are built on Masm32 package. Fasm is great, but the "package" is minimal: dreams of being like Masm32 if and when it grows up. GoAsm, others can be mentioned, with happy users. Actually I don't know much about those, but I'm pretty sure no one even claims to exceed Masm32's high standard re completeness of package (samples, tutorials, qEditor etc), reliability, documentation, basic functionality. But they do have one advantage: under active development. So they can include new more modern features (like, 64-bit macro library I hope).

- Personally, I just write my own macros, borrowing anything from macros.asm or anywhere, and don't worry much about it. I only mentioned it as an excuse (superfluous of course) for forgetting that "print" trashes eax.