Hello,

I have been using FASM for a few years now and have exploited it for almost all of my assembly projects. The most recent is a Trespasser game mod. I have used FASMW (GUI) versions 1.56, 1.58 and 1.60 to compile the project without any problems. However, I recently upgraded to FASM 1.62, and while it does seem to have nice macro features, I have run into major syntax problems with most of the code. I have gotten around a few of them, but it is still a major obstacle as the program is very large and hardly fun to rewrite.

Here are some examples of issues that have come up:
1.
cmp DWORD [eax+20],0
-> This gives an "invalid macro arguments" error for some reason and must be changed to
cmp [eax+20],DWORD 0

2.
call DWORD [ebx]
-> This also gives an error and must be changed to
call [ebx]

3.
fld DWORD [edi+20]
-> Gives an error (???)

3.
struct
...
label .szName
times 64 db ?
ends
-> The "times 64 db ?" gives a structure error and must be changed to
db 64 dup ?

4.
invoke SomeFunction,0,DWORD [ebp],1
-> "DWORD [ebp]" gives an error and must be changed to
[ebp]

There are others as well, mostly having to do with the "DWORD" and other type specifiers. There were a few that I could not get around at all. Keep in mind that all of the original syntax as specified works fine using FASM v1.60 or lower. I have not tried 1.61.

The source code in question can be found in the following archive:
http://www.geocities.com/trespasserhacks/atx135.zip
The file to compile is "ATX_SOURCE\ATYPEX.asm". The dll found in the root folder was created with v1.60.

Anyhow, I hope that there is a fix for these problems, as I could definitely use the new macro features from the new version(s).

Thanks

These all are problems of new macro package, not the new assembler itself. The problem here is generally caused by the fact that now there is DWORD structure (and other similar) defined in WIN32A.INC and family - to allow MASM-like syntax in structure definitions, but mainly for the "local". It can be fixed by making definitions of those structures local to the "local" macro, I will do it.

The second problem you had is with the new "struct" macro - it now simulates the TASM/MASM structures, and for this reason it's more strict with what you can do inside the definitions - only the data defining directives are allowed, so you cannot use TIMES, also the labels other than the ones with data definitions will not define the structure fields. So or are the ones you should use now. (If you need any more free-form structures, learn to use the native "struc" feature of fasm's - it gives you much greater flexibility, on the cost of more work you have to put to make good definitions.)

I have updated the "1.62 for Win32" package with the corrected includes to solve the problem with capitalized type specifiers.

Thank you. The type specifiers now work properly, though I'm still having some structure compatibility issues. I may try rewriting them as you suggested.

I only have two other questions for the moment:

1. An instruction such as "sub eax,[ebx+jump_info.LastTickCount]" where the structure used is defined as...
struct jump_info ;20 BYTES
.Push dd ?
.JumpAngle dd ?
.JumpTendancyd dd ?
.RepeatPeriod dd ?
.LastTickCount dd ?
ends
... no longer works in v1.62/1.62 macros due to an "undefined symbol" error. Most of my code is coded using that syntax. Will switching to "STRUC" (instead of "struct" macro) fix this indexing problem?

2. What is the new method for fetching the "sizeof" a certain structure (instead of simply using the structure's name to do so)?

Again, thank you very much for your time and hard work.

The new "struct" doesn't need the dots before the names, just rewrite it to:

See this thread for more details about using the new "struct".

As for the size of structure, there is no new method, the method for this always was sizeof.jump_info etc. Using structure name for this purpose was an unofficial trick and is no longer supported.

Thanks for pointing that out. I should have paid closer attention to the documentation.

edit: The project now compiles properly under 1.62 after rewriting the structures (link not updated).