Why such a strange code generates?

Index > Windows > Why such a strange code generates?

Author

Thread

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 22 Aug 2005, 07:30

Hello!
I found something strange (abnormal?) in code generation. All my programs works normal, but debugging process is terrible. Here is simple menu creation, but look what gebuggers shows. What could cause that (i.e. what am I doing wrong) and what should I do to make it good?

Description:		Download
Filename:	menu.rar
Filesize:	10.86 KB
Downloaded:	301 Time(s)

_________________
dream of mind creates a monster

22 Aug 2005, 07:30

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 22 Aug 2005, 10:07

Code:

invoke CreateWindowEx, WS_EX_TOOLWINDOW, _class, '', WS_OVERLAPPEDWINDOW, 200, 200, 300, 200, 0, 0, [hinstance], 0

Are you trying to push empty string as window name?
There is no such thing in FASM - just "PUSH 0" - this is NULL pointer. I think its a bit risky, but it works:

Code:

invoke CreateWindowEx, WS_EX_TOOLWINDOW, _class, 0, WS_OVERLAPPEDWINDOW, 200, 200, 300, 200, 0, 0, [hinstance], 0

If you really want your empty strings to stay you have to tell FASM that they are DWORDs, because FASM doesn't know how long an empty string should be. Like this:

Code:

invoke CreateWindowEx, WS_EX_TOOLWINDOW, _class, dword '', WS_OVERLAPPEDWINDOW, 200, 200, 300, 200, 0, 0, [hinstance], 0

There are problems in lines 85 and 90 also:
MessageBox needs a pointer as a second argument and you are passing '2', which points to 00000032h and that is not the correct location.
do this:

Code:

String1 db '1',0
String2 db '2222',0
;...
;Later in the code
invoke  MessageBox, 0, String1, '', 0
;...
invoke  MessageBox, 0, String2, '', 0

Btw, check out http://flatassembler.net/ and pull yourself the newest FASM (1.64).
For your code to work now you should change lines:

Code:

5:include 'win32ax.inc'
60: <DELETE THIS LINE> ; no need in FASM 1.6x
97:        ret

If you get stuck, I can post you the file...good luck!

22 Aug 2005, 10:07

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 22 Aug 2005, 11:34

Which line to delete? On line 60 I`ve got:

Code:

proc WindowProc, hwnd, wmsg, wparam, lparam

Please post the file.

I`m using version 1.6, and i`ve heared that since version 1.58 no improvements for win32.

If I write:

Code:

invoke CreateWindowEx, WS_EX_TOOLWINDOW, _class, 'myprog1',\
WS_OVERLAPPEDWINDOW, 200, 200, 300, 200, 0, 0, [hinstance], 0

or for example:

Code:

invoke lstrcpy, fonttype.lfFaceName, 'arial'

FASM generates very strange code, but program works just fine.

I`ve been advised not to use such string implementation, but declare strings in .data and use pointers on them.

22 Aug 2005, 11:34

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 22 Aug 2005, 12:10

The file you posted had:

Code:

59: proc WindowProc, hwnd, wmsg, wparam, lparam
60: enter ;FASM 1.6x generates error on this
61: push ebx esi edi
62:
63:        cmp [wmsg], WM_COMMAND

Don't include strings in invokes!
Program works fine IF this pointer it creates is at least readable, but the program doesn't work fine, but it shows you scrambled text. This far you have just been lucky Very Happy

I've got the answer to your question - why it shows up wierd. You put strings in the invoke command and FAMS is doing everything it can to satisfy you Wink

Code:

;This:
invoke  MessageBox, 0, '1', '', 0
;would look like this:
  push 0
  call @f
  db 0 ; this is the empty string
@@:
  call @f
  db '1',0 ; the ONE
@@:
  push 0
  call MessageBox

What call does is emulate the push. When push should be given a pointer, call uses the trick that the address of the next instruction is pushed to the stack and ESP doesn't go out of balance (i.e. no stack under/overflow). Between the CALL and the destination you can have your zero-terminated string

22 Aug 2005, 12:10

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 22 Aug 2005, 13:36

Quote:

This far you have just been lucky

For having about 50kb of working code I really am lucky Very Happy

Quote:

60: enter ;FASM 1.6x generates error on this

I`m using version 1.60 and haven`t met such errors.
Hmm... removing enter from my procedures with local data causes GPF.

Code:

-this works fine:
proc lv_param_update
        lvi LVITEM
enter
       ...
return
endp

-this causes GPF:
proc lv_param_update
        lvi LVITEM

       ...
return
endp

Then how to define local data in procs?

22 Aug 2005, 13:36

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 22 Aug 2005, 18:04

Then I'm mistaken - it is some higher version of 1.6x. I can't remember when it was changed.

22 Aug 2005, 18:04

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 22 Aug 2005, 19:21

There are Common Control Window Classes definitions in the Comctl32.inc file.

Code:

HOTKEY_CLASS equ 'msctls_hotkey32'
PROGRESS_CLASS equ 'msctls_progress32'
STATUS_CLASS equ 'msctls_statusbar32'
TRACKBAR_CLASS equ 'msctls_trackbar32'
UPDOWN_CLASS equ 'msctls_updown32'
TOOLTIPS_CLASS equ 'tooltips_class32'
ANIMATE_CLASS    equ 'SysAnimate32'
HEADER_CLASS equ 'SysHeader32'
LISTVIEW_CLASS equ 'SysListView32'
TREEVIEW_CLASS equ 'SysTreeView32'
TABCONTROL_CLASS equ 'SysTabControl32'
MONTHCAL_CLASS equ 'SysMonthCal32'
DATETIMEPICK_CLASS equ 'SysDateTimePick32'
TOOLBAR_CLASS equ 'ToolbarWindow32'
REBAR_CLASS equ 'ReBarWindow32'

Try to create any of them using that definition and than debug it. You`ll get almost the same result as mine.

Next two lines produce the very same code:

Code:

invoke CreateWindowEx, 0, PROGRESS_CLASS, 0, WS_CHILD, 200, 8,\
50, 8, [hwnd], 0, [hInst], 0
invoke CreateWindowEx, 0, 'msctls_progress32', 0, WS_CHILD, 200, 8,\
50, 8, [hwnd], 0, [hInst], 0

The result is on the first screenshot. Of course if you`ll do normal definition:

Code:

progressbar_class_name db 'msctls_progress32',0
invoke CreateWindowEx, 0, progressbar_class_name, 0, WS_CHILD, 200, 8,\
50, 8, [hwnd], 0, [hInst], 0

you`ll get second screenshot.

I think direct string usage is allowed and is a part of design concepts
Maybe we should ask Tomasz Grysztar about it?

Description:	first screenshot
Filesize:	11.73 KB
Viewed:	4926 Time(s)

_________________
dream of mind creates a monster

Last edited by veach1 on 22 Aug 2005, 19:28; edited 4 times in total

22 Aug 2005, 19:21

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 22 Aug 2005, 19:22

second screenshot

Description:	second screenshot
Filesize:	3.41 KB
Viewed:	4924 Time(s)

_________________
dream of mind creates a monster

22 Aug 2005, 19:22

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 22 Aug 2005, 20:56

there's nothing strange about it. "call" pushes address of following instruction and jumps elsewhere. so if string is behind call it pushes it's address. macro "pushd"s branch which pushes string (pushd "aaaaaaaaa") looks like: (not exactly)

Code:

local ..behind
call ..behind
db "aaaaaaa"
..behind:

It's OLLYs problem that it cannot resolve such code (i remember that it states it can - maybe it can be turned on/off somewhere in options) you can change macro to somthing like

Code:

local ..behind,..string
push ..string
jmp ..behind
..string db "aaaaaaa"
..behind:

22 Aug 2005, 20:56

veach1

Joined: 16 Jul 2004
Posts: 165

veach1 23 Aug 2005, 07:29

Than it`s not only OLLYs problem, apart from OLLY, three more debuggers (IDA8demo, gobug0.9, PEbrowserPro7.27) shows the same code.

23 Aug 2005, 07:29

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 23 Aug 2005, 10:23

Its hard to debug because only WE know the code :S Debugger has to choose, wheather its the proc it calls or are there any strings involved. Maybe some *smarter* ppl on this board (read: not me Smile

) can solve this - we can send this to Olly and other debuggers Wink

23 Aug 2005, 10:23

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 23 Aug 2005, 10:40

madis: it isn't that hard for heuristics to solve this. if we suppose string is zero-termintated then you have many clues:
1. call is among pushes - more arguments
2. call is going not too far forward, one byte before destination of call is 0 (termination string)
3. all bytes between instruction and destination are string characters ('0'-9','a'-'z','A'-'Z',10,13, etc...)

i think this is suffictent for heuristic to properly solve mostr cases

but if i remember correctly there was a switch for thi in olly, unfortunately i don't have olly installed currently.

23 Aug 2005, 10:40

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum