.DATA This section contains initialized data of your program.
.DATA? This section contains uninitialized data of your program. Sometimes you just want to preallocate some memory but don't want to initialize it. This section is for that purpose. The advantage of uninitialized data is: it doesn't take space in the executable file. For example, if you allocate 10,000 bytes in your .DATA? section, your executable is not bloated up 10,000 bytes. Its size stays much the same. You only tell the assembler how much space you need when the program is loaded into memory, that's all.

O_o How is that possible? I come from C and there is nothing similar to this in C. Firsst of all in .DATA? how can you allocate memory and the executable and the executable's size will remain the same? I don't get the explanation the writter gives there.

Anybody to help me? In both cases you have bits. What if they are random and what if they are initialized... why is there that difference..?

pls help thanks in advance.
Posted on 2004-08-18 16:18:22 by patriziacharms993
I am not an expert on this but maby the exe tells the OS to allocate this memory on runtime, therefore the compiled exe should contain only info on the type of allocatation and the number of times it should allocate it.

So when the app is executed the following happend---

00 01 02 03 04 05 06 07 ;*some data before .Data*
00 00 00 00 00 00 00 00 ;.Data?
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 08 09 0A 0B ;*end of .Data*
0C 0D 0E........................ ;App entry point

(Side note: PE aka "Portable Executable" might play a big part in this -win32 apps- as i haven't look it up myself)

Source Code
.Data?
SomeArray db 28 dup(?) ;this could be one var or manny but the exe will not bloat.....

Hence the program is placed in memory in the correct spaced ammounts. The exe therefore does not directly grow according to the needed memory ammount. (.Data? : runtime resolution of values and so no meaningfull values to store except for the size and type of var boundries )

HLL - uses manny data types to help with resolving bugs on compiletime (VC++ especially has manny), but all can fall into the basic catogories of byte:word:dword

In C/C++ this is hidden away from the coder - a HLL trait incomparison to ASM. HLL compilers can do this aswell but it has to do with the HLL compilers interpitation of the vars that you have declared - if it is smart enough and you allocate a 500kb of unitilized data as a var then it should use this approach.

Initilized Data: Implies that the application is depended upon the first value upon execution time and therefore stores the value in the exe statically. Text would count towards that. Specific colour values that you want in you app. This is referred to as being Hard-coded.
Unitilized Data: HWND data type would be a example as you do not know the value upon execution but only at runtime but you need to store this value for later reference. Now take an array - purpose doesn't matter - but if the contents will only be obtained at runtime then it will be placed under the .data? section. Like an array of HWND data types.

Black iCE
Posted on 2004-08-18 17:14:37 by Black iCE
Indeed, this is related to the PE format. The .data? section in MASM will create a special type of section in the executable that instructs the OS to allocate memory on runtime. So all it needs is the total size in bytes of this memory, and the address where it's supposed to be placed (so pointers will work).
Posted on 2004-08-18 17:44:20 by QvasiModo

and the address where it's supposed to be placed (so pointers will work).

I agree.

My understanding:

Generally speaking - pointers are referred through DWORD values that contain the addess of the data consirned in *relative* relation to applications loaded address. So if 2 instances of the app is loaded they are kept separate and the pointer will refere to the data consirned using the loaded apps address space as a way to relate to it.

Relative Pointer:Relates to data through the apps address space. (OFFSET and ADDR)

    [*]Usally not placed in any vars as it is calculated at runtime.

    External Pointer:Relates to data outside its own address space -usally returned through an api as in SHGetMalloc.

      [*]Usally placed under the .data? section.

      Static Pointer:Hardcoded value -techinically speaking not a true pointer- but usefull for certain situations, and usally the coder's own protection scheme (messhing up the exe) or data contained within the exe added without system methods. Also the root of most illeagal activities.

        [*]Placed under .data or relate to it through runtime techniques and modifying the returned value accordingly as not to relate to it directly.


        Black iCE
Posted on 2004-08-18 18:46:01 by Black iCE
".DATA?" doesn't even need an extra section - if the last section is read+write, the peheader.sizeofimage can just be expanded.

Also, C/C++ *does* have this kind of storage that doesn't bloat the EXE file: "int bigarray[500000]" should use BSS (other name for uninitialized data) storage.

This kind of storage is guaranteed to be zero-filled, by the way.
Posted on 2004-08-18 19:15:05 by f0dder
f0dder - the discussion was ment to be on general terms.

Also, C/C++ *does* have this kind of storage that doesn't bloat the EXE file: "int bigarray[500000]" should use BSS (other name for uninitialized data) storage.

Yes - but look at the original post, i was attempting to explain and keep it ss (simple stupid) :grin:. Speaking in techincal would prove no point on explaining bron's post.

if it is smart enough and you allocate a 500kb of unitilized data as a var then it should use this approach.

so i just said that HLL do this but depending on wether it realizes that it can compile it in that manner.

MSDN
int
The keyword int specifies a 32-bit signed integer on 32-bit platforms...

ie 500000*4=2000000bytes:rolleyes:
better to use "BYTE bigarray[500000]" if you are using my givin example.

Black iCE
Posted on 2004-08-18 19:30:26 by Black iCE
bron,

The distinction is simple stuff once you get it. Some data must be initialised, text is a good example.


.data
MyText db "This is my text",0

When you need data like this in your app, it must be stored somewhere and when you use ".data" it means the data is stored in the INITIALISED data section.

When you have data that can only be filled at runtime, you don't need to store that info in the INITIALISED data section so you can put it in the UNINITIALISED data section and save some space. It is often useful to make a set of handles global so you allocate the spoace for them in the .DATA? uninitialised data section like as follows.


.data?
hwnd dd ?
hedit dd ?
htoolbar dd ?
hstatus dd ?

Another choice is to allocate the data locally if you only need the data within a procedure and not globally.


LOCAL hCtrl:DWORD
LOCAL rct:RECT
LOCAL buffer[260]:BYTE


Regards,

hutch at movsd dot com
Posted on 2004-08-18 19:42:27 by hutch--
ice, I was commenting on the "I come from C and there is nothing similar to this in C.". I wonder why I picked 500000, though - if I wanted 500kb I'd have used an unsigned char array, and 500*1024 (yes, I'm explicit like that when I want kilobyte :)).

bron, things to keep in mind:
".data" is initialized to whatever you initialize it to
".data?" is initialized to zero
local storage goes on the stack, and have "totally random" contents.
Posted on 2004-08-18 19:57:19 by f0dder
".data?" is initialized to zero.
Be careful ! No warrant !

Auto insert "Memory Clear Routine" not in every assembler/compiler.

Auto "Memory Clear Service" not in every O.S.

if sizeof(.data?) is big, CPU clear they, need cost many machine cycles.

Ex:
    .data?


szOut db big_number dup(?)

.code

; First R/W szOut[] routine after load the exefile.
invoke lstrcpy, addr szOut, addr szSource

Do You want O.S Auto clear szOut[] when load the exefile every time?
Posted on 2004-08-18 21:29:39 by
Kestrel - i have came across that problem before (That might have been while programming in DOS).But when using .data? it is best practice to assume that the data isn't zeroed. Or to clarify, any memory related allocation should not be assumed as being zeroed - only if documentation states diffrently may you savely regard it as zeroed.

The point of .data? is to initilize it during runtime - so to assume it to have a value can cause a great deal of loss sleep and headaces if you don't realize where your problem might be in you app.

(Side Note: So as to state that my example in my first replay is just an example, and that the zeroed bytes was aimed at making it obvoius that it belongs to the .data? section - bolding was added afterwards to make it stand out easily.)

Black iCE
Posted on 2004-08-18 21:32:33 by Black iCE
How is that posible? ... how can you allocate memory and the executable and the executable's size will remain the same?


When you click on a icon to run a programm, or you use other way for run a programm, there is also called a loader, that depend on the OS, yes th PE format have a lot to do here, this is readed by the loader, the relocations are done, the sections are initialized, the necesary thing for run your programm under the control of the operative systems is done there.

For example, when the loader find the unitialized section .bss .data?... unitialized... it see how many bytes there are, and it allocate this spece at run-time (but with a pre-request in your code), like I know is filled with zeros. The diference, is like hutch say, you normally whant some data initialized and other no, but see that there exist diference with the memory allocations at runtime, done in the heap, that this memory is not guarantee that is filled with zero, while you know exactly how unitialized data you whant, hwnd, otherunitialized, you dont know how many (or much) whant with allocations at run-time. (Hope you get the idea :)


Auto insert "Memory Clear Routine" not in every assembler/compiler.


I dont understand that... the .data? sections is handled by the OS loader, pheraphs you refer to local variables? in the stack.


Have a nice day or night.
Posted on 2004-08-18 22:15:36 by rea
I dont understand that... the .data? sections is handled by the OS loader, pheraphs you refer to local variables? in the stack.

OS Loaded -> exefile entry point, right?

OK....! But some exefile entry point is door of Coat.

The Coat maybe added by compiler (or Linker, or IDE, or packer, or other).

the Coat done something -> Entry point (writed by Programmer).

most Compilers to be add Coat (or add Super Big Coat).

most Assembler don't add Coat (or add super light Coat) , so Asm exefile is pure always.
Posted on 2004-08-19 01:50:48 by
Thanks for all the replies! First of al about C:


double data[100000000];
int main()
{

}



int main()
{
double data[100000000];
}



int main()
{
double data[100000000] = {0};
}


All these programs have the same size ( 24.5KB ). So how does the size of the .exe blows up when the data arre initialized in C?

Now about assembly. ( guys don't post code because i am new to this and i don't understand anything... and i don't get along very well with terms too.. )
So you mean that i get the memory from the heap (with .data?) at run time?

and second:
>".data?" is initialized to zero
The global data are initialized to 0 like in C, but the locals have the random values like in C again, but both take their memory at run time?
Posted on 2004-08-19 03:45:40 by patriziacharms993