i want to set an array (255 ) of RASENTRYNAME from some wired reason . icant .
i cant even do local bla:RASENTRYNAME

H:\MASM32\MyProg\checkifonline\LISTBOX.asm(313) : error A2175: invalid qualified type : RASENTRYNAME
H:\MASM32\MyProg\checkifonline\LISTBOX.asm(313) : error A2195: parameter or local cannot have void type

i tired to set an array of RASCONN and with this i couldnt set an array bigger than 20 (dont know why )

maybe you can help me


Posted on 2001-08-30 13:20:10 by eko
eko -

please post a section of your code so whoever can help you has a better idea of what is going on. I would be of little help but could learn from it.

How big is RASENTRY? Is it static? etc
Posted on 2001-08-31 14:37:51 by drarem

mydata RASENTRYNAME 100h DUP (<>)

or if you want it dynamic, and not taking up space in the PE:

mydata RASENTRYNAME 100h DUP (<>)

and then make sure that in the RASENTRYNAME struct, all the data is '?'
Posted on 2001-09-01 01:40:57 by Kenny
thanks for your replay. i forgot how to set a array of a struct (global) ...

but i found the problem (i think) it was at windows.inc





Posted on 2001-09-01 08:32:07 by eko

i'm still having a problem with the array

when i do


r array of 255

and mov r.dwSize,264
everything is working ok

but when i do

mov r.dwSize,264 the program close itslef....

if you know what is the problem

Posted on 2001-09-01 13:14:36 by eko
Ok, if you want local, just do this

myproc PROC
R RASENTRYNAME 100h DUP (<> ) ;this is now local data

myproc ENDP

If the .data section is outside of the proc, then it becomes not local.
Posted on 2001-09-01 14:31:39 by Kenny

well ... the code works . but are you sure it will be local ?


Posted on 2001-09-02 10:38:22 by eko
What do you mean by Local :)

See, MASM's version of local is the same thing as global, you just can't use the data previous to the proc (and some other limitations). But, in C++, they say the data is local, when it is really global temporary data, and just passed between functions in the stack. So, what I mean is that Microsoft has built into their compiler that you can't access local or protected data outside of the function, when in reality you can, just MS can't garentee its integrity, so they disable it.

Dispite what people tell you, LOCAL data is not everything that MS makes it out to be. It still takes up RAM. It takes extra time to be passed between functions (or PROCS) and can never be garenteed. However, global data is ALWAYS going to be what you want it to be, and you won't have to go through previous procs trying to figure out what you did to data. Heck! Check out betov. This guy coded a 1MB asm source using all global, and his program works fine (SpAsm).
Posted on 2001-09-02 15:50:11 by Kenny
The are two types of 'LOCAL's in MASM. Locals in a PROC are created on the stack and are not accessible out side that PROC - they are not global. The other type of LOCAL is in a macro, and that is just an assemble time EQU (text, number, or label).

In the above code, you are creating global data in the DATA segment using the shortcut segment directives. I think the program crashed before because you had more than 4k of locals - if that is the case you need to allocate the space from the heap, or manually access the stack in ~4k increments until you have what you need. This is due to the Window memory managment. There was another thread here about this limitation - I'll see if I can find it and repost a link here. eko, I would try a smaller array and if the code works then my assumption is correct - if it still doesn't work, then the error is somewhere else, or I'm wrong as well. :)

Kenny, you are wrong - go back to the manual. ;)
Posted on 2001-09-02 16:53:36 by bitRAKE
I swear I used a LOCAL directive, and then later in the program I accidentally tried to use it, and it worked fine. Maybe I'm completely messed up... I don't know. I don't use LOCAL though, so I wouldn't really know.

What I do know is that MASM is very finikey.

I forget stuff pretty easily, so you might be right.... Now that I think about it, you probably are. I think it's the .data directive that you can use anywhere else in the program but before it.


Try this:

Take WinMain and put all the locals in the .data section. You will notice it doesn't work... Now, take the locals and place them in the way I described above. WOW It works! I hate MASM :)
Posted on 2001-09-02 17:56:52 by Kenny
DANG! I just tried it, and you are indeed correct! My mistake... shoot me :)
Posted on 2001-09-02 18:08:38 by Kenny

thanks for your replys

i thought that if you do local myvar:DWORD or something ..

it will be on the stack , and you cannot reach them from anywhere expect the procedure . so global will take more memory than local , am i worng ?

another question , maybe i'mdoing something worng
how do you access to an array of struct ??



Posted on 2001-09-03 06:56:06 by eko
You are right eko, about LOCAL variables being on the stack and only availible inside that PROC.

To access an array you should multiply the index by the size of the array:

MyStrangeProc PROC values:DWORD
LOCAL myRect[32]:RECT

mov eax, values
mov ecx, SIZEOF RECT
mul ecx

mov eax, myRect.left
MyStrangeProc ENDP

If the size of the structure is a multiple of 2,4,8 then you can multiply at the time of use (mov eax, myRect.left) - there are other was to multiply as well (LEA, SHL, etc.). Remember that LOCALs are really memory references from EBP!

mov eax, myRect.left


mov eax, ;xxx is some value

...look at the code with a debugger. :alright:

This is really just brushed apon in Chapter 5: MASM Programmers Reference - they could have done a better job IMHO. For example, in some cases MASM will add the *2,*4,*8 for you in the access - it depends how the array is defined. This is one of the reasons NASM was wrote. :)
Posted on 2001-09-03 08:20:22 by bitRAKE
exacly what i needed ;]

Posted on 2001-09-03 08:48:45 by eko
hi again

in some cases MASM will add the *2,*4,*8 for you in the access - it depends how the array is defined

and when ?

Posted on 2001-09-03 08:51:06 by eko
Here is the example out of the documentation:

w WORD ?
b BYTE ?

array WB (100 / SIZEOF WB) DUP ({0})

mov array[12].w, 40h
mov array[32].b, 2

I think I'm mistaken - this doesn't appear to produce anything unexpected. Just tried it. Wonder why I thought that MASM did that? :tongue: I just love to blame MASM for all my problems. ;)
Posted on 2001-09-03 12:42:22 by bitRAKE