.code or .data section

[emre_tinaztepe]

 Hi there,
I am struggling with something weird. I am trying to put my byte string in .code section and after using it with MessageBox api, it works but Windows XP gives and error,
as you know bla. bla. an exception occured, SEND it DONT SEND IT bla. bla.
  But if i put my byte string into .data section, it gives error...
  Code is like this :
.486
.model flat,stdcall
option casemap:none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc

includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

.data


.code
_start:   
   push 0
   push offset mesaj
   push offset mesaj
   push NULL
   call MessageBox
   
   push 0
   push offset mesaj
   push offset mesaj
   push NULL
   call MessageBox
   
   mesaj db 'emre',0   


_end:
   push 0
   call ExitProcess
end _start
 

Does anyone have any idea?

[mnemonic]

Tip of the day: Crossposting is bad habbit.

Your solution is here: http://www.masm32.com/board/index.php?topic=7672.0

[ragdog]

hi

Code Select Expand


.code
_start:   

   push 0
   push offset mesaj
   push offset mesaj
   push NULL
   call MessageBox
   
   push 0
   push offset mesaj
   push offset mesaj
   push NULL
   call MessageBox
   ret
   mesaj db 'emre',0
_end:
   push 0
   call ExitProcess
end _start


greets
ragdog

[OldTimer]

The easiest way to embed data into the code section is to use the 'szText' macro.   It will produce the jump statements for you.

.data
      szText MACRO Name, Text:VARARG
        LOCAL lbl
          jmp lbl
            Name db Text,0
          lbl:
        ENDM
.code

    szText mesaj,"emre"

[emre_tinaztepe]

Thank you for your replies,i got the idea behind! System tries to recognize byte string as instruction. now it works,


Thanks again :)


P.S : I got the tip of the day:) Wont be again :)

[Tipidy]

Now I have a question, why would one want to embed test in the .code section instead of the .data section? Just curious...  :bg

[drizz]

Now I have a question, why would one want to embed test in the .code section instead of the .data section? Just curious...  :bg

1) for no apparent reason; so the string is readonly? .const section is also readonly, you can put strings there too.
2) viri-like coding

Code Select Expand

push 0
call @f
db "mesaj",0
@@:
push dword ptr [esp]
push 0
call MessageBox

3) because you can

[Vortex]

Hi Emre,

Why do you prefer to pass manually the parameters instead of using the invoke statement?

[Synfire]

Actually, although it's bad practice, it can be used to reduce program size. Each section has to be at minimum 512 bytes so even if you just put "Hi" into the section, it will be padded to 512 bytes minimum ("last section exemption" not taken into account). Some people put strings in the code section to make use of the space they are using there to keep from having to make an extra section which would primarily consist of unused space.

[Vortex]

One can use also the /MERGE linker switch combining the sections to one to reduce the size of the executable.

[Synfire]

Yea, that's effectively the same idea. If you were going to do it, I would probably suggest using the /MERGE method and let the Linker handle everything. This is because if you collect everything into one section the Linker will automatically take advantage of the "last section exemption". The last section in the section table isn't bound by the 512 byte increment rule, the linker can strip unused data from the end of the section (further reducing the file size).

[Jimg]

How does one know what to use for the from=to parmeter, and is this method viable for shrinking a static library?

[hutch--]

Jim,

Static libraries don't have sections like a PE executable file.

[drizz]

How does one know what to use for the from=to parmeter, and is this method viable for shrinking a static library?

Code Select Expand

/MERGE:.text=.drizz /MERGE:.rdata=.drizz /MERGE:.data=.drizz /SECTION:.drizz|RWE
although static libraries object files(static library is collection of obj files) do have sections, you can't use merge command because it's not supported. other ways to shrink the static library would be to remove any .debug$S, .debug$T @comp.id, .file, assembler logo,etc. information from object files, but i'm not familiar with such a tool.

[hutch--]

There have been tools in the past to strip junk out of object modules but its probably just as simple to build the object module without the junk in it as a release build. I don't personally see the point of chasing size reduction in an object module when the only thing that matters is the final size of the executable code built using object modules. With current 32 bit COFF object modules you have complete control of both DATA and CODE so there is no problems in controlling what you end up putting into an EXE file as long as you are not using a junky compiler that does not gve you the options.