DUP operator

[ic2]

I just realize my buffers were in the wrong place.  Needed to be in the .data? Section

My question should have been is it possible to place un-initialized data in the .data section.  I think the answer may be no-possible.  I just need to know for sure.

This is a one very interesting thread and a great future reference.  Ehtyar, I been wondering the same thing myself,  a lot,  every time I open my .data inc.  I think I hear the sad truth once before.  I still can't believe it.  Here i am again reading into something i review last year seriously ...
ToutEnMasm, that rocks... We learning something new everyday...

[Ehtyar]

Guess we need to start using GlobalAlloc for storing our strings ;) *hides from the smart people*

Ehtyar.

[PBrennick]

Kyoy,
The one question that no one seemed to answer for you is the following...

buffer BYTE BUFMAX+1 dup(0)

The reason for that type of notation is to ensure that the buffer remains zero terminated. Of course, it can be defeated, but the notation is a nice reminder when you look back at your code many months later as to what must be; or else.

Paul

[zooba]

My question should have been is it possible to place un-initialized data in the .data section.  I think the answer may be no-possible.  I just need to know for sure.

Nope, it's definitely not possible. The reason is quite boring, it's simply because the .data section is always initialised and the .data? section is always uninitialised. So you can't initialise data in a .data? section because '.data?' means 'uninitialised'.

Of course, you could always initialise it to zero, though it achieves little except bloat :wink

Cheers,

Zooba :U

[PBrennick]

zooba,
I think you must be confused. He asked if you can put uninitialized data in the .data section NOT the other way around. The anwser, of course, is yes you can.

The following will assemble, link and execute with no errors. I just, now, tested it although, I have seen it done pretty often.

Code Select Expand


;

;  Un-Initialized DATA 
; 
.data?

    NotifyData      NOTIFYICONDATA <>   ; Tray Icon Notification Data.

    hInstance       dd  ?               ; Application Instance Handle.
    hMenu           dd  ?
    hConfigMenu     dd  ?               ; Configuration Pop-up Menu Handle.
    hNetMenu        dd  ?               ; Web Surfer Pop-up Menu Handle.


;

;  Initialized DATA 
; 
.data

    szClassName     db  "GeneSysClass", 0
    szAppName       db  "GeneSys Menu", 0
    szFontName      db  "MS Sans Serif", 0
    szGeneSys       db  "\GeneSys\GeneSys.exe ", 0                  ; Default Path
                    db  MAX_PATH - ($ - OFFSET szGeneSys) dup (0)   ; (260 - X) bytes
    hIcon           dd  ?



Paul

[zooba]

I think you must be confused. He asked if you can put uninitialized data in the .data section NOT the other way around. The anwser, of course, is yes you can.

The assembler will accept the syntax. However, it will initialise it (probably to zero) so it is still initialised data and will bloat the executable.

Try this:

Code Select Expand

.data
    DWORD 40000h DUP (?)

When MASM finally assembles it (MASM is slow for big DUPs when assembling to COFF), you'll have a 1MB executable. Change it to .data? and you'll be back down to a few KB (though just as slowly).

A random chunk grabbed from the middle of the big one shows that it has initialised it with zero:

Code Select Expand

000019A0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000019B0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000019C0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000019D0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000019E0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000019F0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00001A00 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00001A10 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00001A20 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00001A30 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00001A40 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

So the assembler will accept not specifying a value, and where a HLL would probably give a compiler error, MASM will simply initialise it to zero.

Cheers,

Zooba :U

[PBrennick]

zooba,
I already know all that, but it was not the question. You should just answer the question correctly and not try to confuse everything.

The answer is 'yes,' the impact is ANOTHER question.
Paul

[Ratch]

PBrennick,

     I think I agree with zooba on this one.  Anything you put into .DATA will be initialized to something, and contribute to the size of the executable.  There is no way that entries in .DATA will be treated the same as if they were in .DATA?.  Sure, you can specify (?) within .DATA, but that is not specifying uninitialized data, that is specifying undefined data.  There is a difference.  Ratch

[PBrennick]

Ratch,
Nobody said it would not create or contribute to bloat. Read all the posts. You will see that at one point zooba said you can't do it. He did NOT say you should not do it as he said in a later reply. That is my objection.

This is what zooba said:

Quote from: ic2 on Today at 01:57:35 AM
My question should have been is it possible to place un-initialized data in the .data section.  I think the answer may be no-possible.  I just need to know for sure.

Nope, it's definitely not possible. The reason is quite boring, it's simply because the .data section is always initialised and the .data? section is always uninitialised. So you can't initialise data in a .data? section because '.data?' means 'uninitialised'.

Of course, you could always initialise it to zero, though it achieves little except bloat wink

Cheers,

Zooba

That is obviously incorrect and is the only point I am struggling to make here. If someone is going to give advice, let's make sure it is correct.
Paul

[Ratch]

PBrennick,

Nobody said it would not create or contribute to bloat. Read all the posts. You will see that at one point zooba said you can't do it. He did NOT say you should not do it as he said in a later reply. That is my objection.

     No, zooba is right.  Here is why.  Sure, it is dumb to code something like BYTE 80 DUP (?)  in a .DATA segment, but that operation is coding undefined itialized data, not uninitialized data.  That is what zooba meant when he said it is impossible to code uninitialized data in a .DATA segment.  Ratch

[zooba]

Sure, it is dumb to code something like BYTE 80 DUP (?)  in a .DATA segment, but that operation is coding undefined initialized data, not uninitialized data.

From MASM32.HLP:

The .DATA directive starts the initialized data segment (with
     segment name _DATA) and ends the previous segment, if any. The
     .DATA segment should contain all global data that have initial
     values.

     The .DATA? directive starts the uninitialized data segment (with
     segment name _BSS) and ends the previous segment, if any. Place all
     uninitialized data in the .DATA? segment.

ie. the .DATA segment contains initialised data and nothing you can do can uninitialise that. Whether you specify a value or not it is still initialised. The assembler enforces it by assuming everything to zero unless you specify a value (most HLLs enforce it by giving a compilation error).

The .DATA? segment contains uninitialised data and you can't initialise it at compile time. The assembler enforces this by giving an error message.

My exe is 20.5kb ... When i add this new buffer size with dup (?) or dup (0) I get the exact same results.

Buffer   BYTE   10000   DUP (?)

my exe size rises to 30.5kb

I thought DUP (?) mean it will not go to that size until after the program is EXECUTED. - - - Un-Initialized

And that if we use DUP (0) it will automatically add that size to the program increasing the size of the exe even before execution.. - - - Initialized

...

Forget it, I looked a little harder here and placed it in the proper place... .data?

So the original problem was solved by the original poster, which is good. The confusion is over the meaning of ? when used as an initialiser.

If you initialise a variable with a question mark, you are specifying that you don't care what value it is. The assembler is allowed to choose for you and in general it will choose zero. This holds (I believe) for any segment except for .DATA?.

In a .DATA? segment, only the total size of the data is stored in the executable. Then Windows will allocate enough memory for your application on loading. (The same thing happens for the .DATA segment, but Windows will then copy the entire segment into memory.) Since you can't know what value your variables will take, the assembler requires you to initialise them as '?', or unknown/unspecified.

Hopefully this has cleared things up.

Cheers,

Zooba :U