I'v read the documentation and I can't get arrays to work. I'm trying to make an array inside a structure (MODULEENTRY32) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/moduleentry32_str.asp but I cant get it to work.

post your code which doesn't work and error returned.

TCHAR szModule[MAX_MODULE_NAME32 + 1]
in (f)asm: szModule du MAX_MODULE_NAME32+1 dup(?)

TCHAR szExePath[MAX_PATH];
in (f)asm: szExePath du MAX_PATH dup(?)

"du" or "db" depending on whether you use "A" or "W" functions.
fasm's headers have CHAR type defined for this purpose:

i really don't know then... you should maybe ask tomasz.

i really am not a big user of "struct" macro

Thanks. Works now. Heres the struct incase anyone is interested:

struct MODULEENTRY32
dwSize dd ?
th32ModuleID dd ?
th32ProcessID dd ?
GlblcntUsage dd ?
ProccntUsage dd ?
modBaseAddr db ?
modBaseSize dd ?
hModule dd ?
szModule du 256h dup(?)
szExePath du 260h dup(?)
ends

although I'm not sure how to get BYTE* (think this is a pointer) working.

tomasz: i wanted to point out this later... don't you think it just blind following of "common" way to implement ansi and unicode versions with common interface, like in C? in C it is possible to manipulate these with (roughly) same code, but not in assembly.

Why not just do it directly? One file with imports for both ***A and ***W functions, and coders should know which he is using, and he can use both...

You're right, that would be much more assembly-like.
I perhaps cared too much about compatibility here (while not at all in some other areas).

Well I only use A versions. No specific reason why (habit I guess). Any idea what i would need to use BYTE* (no idea what this doesn in C, since I'v never done much C) or would it work fine like that?

Thanks for all your help so far

do you think it's too late to break backward compatibility? For sure some people won't be very happy, but it would be nice to have this "clear", and if it should be done, then better sooner than later...

and, yes, you managed to spare us of "common way" in many areas

Well, the idea appeals to me.
However note, that the "common" way still has the advantages spared even by fasm sometimes - the HELLO example will compile and execute correctly when you change WIN32AX to WIN32WX.

well... in case of helloworld-like programs yes, but not after you modify single string by asm code... you know.

right now i am working on static string library, and i am becoming scared when i will have to port it to unicode

I think you'd be REALLY scared if you had to port it to UTF-8

hehe