I have studied the decoded results and drawn the following conclusions:
- The code you enter in the main program consists of instructions starting with a mark of "Start of main code" and
ending at "End of main code". Inside there is also the "Main Code Entry Point" where execution is started.
If you use modules, ie compiles *.obj files, you can find them by the end of the main code. The modules are separated
by a number of 0CCh (int 3) instructions. The modules are marked with "Module X".
The table for jump to MS API functions is common to the main code and modules. Sometimes this table ends up at the
beginning and then the main code is at the end. Usually the main code ends up first and followed by the jump table.
If you also use static libraries in your code, the libray code ends up after the main code's jump table, separated by
some 0CCh (int 3). More such sections are available if more static libraries are used.
Internal processes that are invoked in the code are marked with "Process X byte args". Only those processes are
marked. In the static libraries there may be processes that are unmarked when not invoked in the main code.
This description seems to add up for the programs that I have written.
I attach the decoded result from the file "PlayVideosWithDShow.exe" provided by jj2007.
Result PlayVideosWithDShow.decoded
- 15,427 rows of instructions
- 3 modules (*.obj files)
- 2 static libraries
- 114 internal invoked processes (including modules and libraries)
I am grateful for comments and corrections of my conclusions.
hello minor28;
Sometimes that 'int 3' are used as being a bunch of bytes to align next procedure into some address range (4,8,16,...), not same action but same way we can change that to 'nop' that have 1 byte size too. We have others choices like 'mov edi,edi' that don't do anything usefull but are used to align nexts instructions or procedure by default to an even address.
I think you looked to 'ret' instruction to deduce about how many parameters a function holds inside specific calling convention. You can check too where that variable is used so you can conclude about that being a dword instead of 4 bytes, or 1 dword parameter, ... .
I quickly see your file, not sure about what I'm talking now but sounds to me that have more than 1 calling convention used on that file.
Looks good. I attach a proggie that converts .decoded to a valid .asm file :biggrin:
MakeSource.exe expects PlayVideosWithDShow.decoded in the same folder. For example, it translates
00401019: E8 5A 3A 00 00 call 00404A78
into
call ds:[00404A78h]
Unfortunately,
jz dword ptr ds:[0040103Fh]
is not accepted by the assembler. Same for loop. I wonder if there is a valid syntax for that?