registers at startup and questions

[Jeff]

i was just wondering about the registers and what is typically in them at startup.  i remember seeing in another thread that windows XP machines usually have eax = 0 and ebx containing the address of the PEF (?) (whatever that is).  is there any significance to the other values? (like "edx contains the address to the calling program")

this eventually leads to my next question, are those register values necessary for a program to function properly.  i am trying to write a little "program supplement" thing that will get the arguments passed to the program, process them, and have it available to the user program (kind of like what c/c++ programs do with the argc/argv values).  should i save the registers at the beginning when i process the arguments and restore them for the "main program" or are they expendable?

then, is there a way to make variables in a program/library available to other programs without having to declare them in the other program?  (gotta get argc/argv to the main program preferredly global)

my final question, unreleated.  if you had a procedure that did not contain a prologue and epilogue, should the values of esi (and possibly edi) change whenever they are accessed.  a while ago, i was experimenting with procedures and the PROLOGUE:NONE and EPILOGUE:NONE options.  a simple "length of a null-terminated string" procedure that took in one argument (the address of the string).  so (i think) it looked something like this:

Code Select Expand

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

StringLength PROC STDCALL, String:PTR BYTE
    MOV esi,String
    XOR ecx,ecx
    .WHILE BYTE PTR [esi] != 0
        INC ecx
        INC esi
    .ENDW
    MOV eax,ecx
    RET
StringLength ENDPthen when i was debugging this program, i found that when it went to "INC esi", esi turned to some funky number.  should that have happened?  i understand the concept of a stack frame and how the procedure usually refers to procedural arguments and local variables are referenced relative to the ebp register, but from what i see, it has nothing to do with that.

[roticv]

Let me answer your final question because I think it is more interesting  :toothy

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

Means that masm will not automatically create the stack frame or remove the stack for you. You only use that if you have no use for the stack frame and want to save some bytes.

In your example, you used "mov esi, string" where string is a parameter for your function. MASM will interpret the variable "string" as mov esi, [ebp+8]. As you haven't set up the frame stack, the value in ebp at [ebp+8] obviously does not contain your parameter. Your parameter is still found in your stack (esp). So to access your parameter, you should use mov esi, [esp+4] instead.

Do read my article on the stack if you are interested at http://win32asmcommunity.net/phpwiki/index.php?pagename=TheStack

[Jeff]

thanks roctiv.  i am pretty confident in my knowledge of the stack but i will definitely be reading that.  ;)  i guess i was hoping that MASM would have done the appropriate changes to the reference (but it was expecting me to set up the frame :D).  i think i made a break after the loop and it was some big number (definitely larger than my string).  mov esi, string probably moved a 2 into esi and took a looooooong time to find a null.  :)

PS since there is no epilogue, the procedure is using the STDCALL calling convention, and there is an argument, i would have to clean up the stack as well huh?  (the possible solution to the crashes :D)

[roticv]

Yes, you should be using "retn 4*numberofparameters" instead of ret.

Btw it is always good to load it up in a debugger (like Ollydbg) and figure out what's wrong. It's a great way to learn new things.

[hutch--]

Jeff,

You used ESI so it needs to be preserved as well.

Code Select Expand


OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

StringLength PROC STDCALL, String:PTR BYTE

    push esi

    MOV esi,[esp+8]    ; fixed with thanks to Victor.
    XOR ecx,ecx
    .WHILE BYTE PTR [esi] != 0
        INC ecx
        INC esi
    .ENDW
    MOV eax,ecx

    pop esi

    RET 4

StringLength ENDP

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef


You normally set the prologue and epilogue back to default after unless you want any following code to have the same characteristic.

[AeroASM]

You should ideally define String as :DWORD because the only thing that :PTR BYTE does is allow you to skip out the byte ptr when doing a mov mem,immed which is confusing.

Once you get it working, have a go at coding your own loop rather than using .while.

[roticv]

Hutch,

In your code, it should be [esp+8] instead. That's the problem with not using a stack frame - you tend to create unwanted crashes due to carelessness.

[AeroASM]

I think that MASM should have the option of making prologue and epilogue code ebp-less. Is there a "suggestion box" on the Microsoft website?

[hutch--]

Victor,

> In your code, it should be [esp+8] instead. That's the problem with not using a stack frame - you tend to create unwanted crashes due to carelessness.

You are right, I added the push/pop ESI after.  :P Stack should be corrected for changes due to ESI with PUSH. Main observation was the algo should be coded with one register but with two it would have saved the problem using ECX or EDX.

The problem is neither using or not using a stack frame, its not calculating the change in ESP.

[MazeGen]

I think that MASM should have the option of making prologue and epilogue code ebp-less. Is there a "suggestion box" on the Microsoft website?

Yes, there is, but I much doubt they will support it.

Petroizki already made "ebp-less" macro set. I will release the plugin one day to simplify the syntax, hopefully.

[roticv]

Wow that is really a difficult task. How come I did not get to see the thread?

[MazeGen]

:( It seems that only a few coders saw the thread, or almost nobody needs "ebp-less" procedures - there is no feedback.

[hutch--]

Maybe I have missed something here but as you can already write procedures without a stack frame in MASM using the OPTION PROLOGUE/EPILOGUE syntax, I am not sure what the gain is. They tend to be used when the algo design needs the extra register EBP and there is a minor stack overhead gain by doing so.

[Jeff]

thanks for your input guys.  that helped a bunch.  now would anyone happen to know about the other questions?  :D

[donkey]

Hi,

At startup there are two registers that have significance. EAX and EBX both contain interesting values.

EBX on NT based systems contains a pointer to the PEB (Process Environment Block) that contains various useful information about the program that is running. For example it's heap handle, parent PID, command line and many other tid bits. Because the pointer is only set on NT based systems you can use it as a quick way to determine the OS family for API's such as PSAPI, which are only available in the NT family. EBX will always contain 00530000h on 9x systems.

Note that you can also obtain the PEB pointer using fs mov eax,[30h]

EAX will contain the application entry point on 9x systems, on XP systems it will contain 10000000h, NULL on all other NT versions.

Here is a partially completed list of the PEB/PDB

Code Select Expand

TIB STRUCT
pvExcept DD // 00h Head of exception record list
pvStackUserTop DD // 04h Top of user stack
pvStackUserBase DD // 08h Base of user stack

; NT only
SubSystemTib DD // 0Ch
FiberData DD // 10h

; 9X & NT
pvArbitrary DD // 14h Available for application use
ptibSelf DD // 18h Points to the structure itself ???

; NT only
unknown1 DD // 1Ch
processID DD // 20h
threadID DD // 24h
unknown2 DD // 28h

pvTLSArray DD // 2Ch Thread Local Storage array

; NT only
pPEB DD // 30h Pointer to Process Environment Block (PDB)
ENDS

PDB STRUCT
header DD 2 DUP (?) // 00 Kernel object header
module DD // 08 Main exe module (NT)
LdrData DD // 0c Pointer to loader information
ProcessParameters DD // 10 Process parameters
unknown1 DD // 14 Unknown
heap DD // 18 Default process heap
mem_context DD // 1c Process memory context
dwflags DD // 20 Flags
pdb16 DD // 24 DOS PSP (pointer)
PSP_sel DW // 28 Selector to DOS PSP
imte DW // 2a IMTE for the process module
threads DW // 2c Number of threads
running_threads DW // 2e Number of running threads
free_lib_count DW // 30 Recursion depth of FreeLibrary calls
ring0_threads DW // 32 Number of ring 0 threads
system_heap DD // 34 System heap to allocate handles
task DD // 38 Win16 task
mem_map_files DD // 3c Pointer to mem-mapped files (pointer)
env_db DD // 40 Environment database (pointer)
handle_table DD // 44 Handle table (pointer)
parent DD // 48 Parent process (pointer)
modref_list DD // 4c MODREF list (pointer)
thread_list DD // 50 List of threads (pointer)
debuggee_CB DD // 54 Debuggee context block (pointer)
local_heap_free DD // 58 Head of local heap free list (pointer)
unknown2 DD // 5c Unknown
crit_section DD // 60 Critical section
unknown3 DD 3 DUP (?) // 78 Unknown
console DD // 84 Console (pointer)
tls_bits DD 2 DUP (?) // 88 TLS in-use bits
process_dword DD // 90 process dword (??)
group DD // 94 Process group (pointer)
exe_modref DD // 98 MODREF for the process EXE (pointer)
top_filter DD // 9c Top exception filter (pointer)
priority DD // a0 Priority level
heap_list DD // a4 Head of process heap list
heap_handles DD // a8 Head of heap handles list (pointer)
unknown4 DD // ac Unknown
console_provider DD // b0 Console provider (??)
env_selector DD // b4 Selector to process environment
error_mode DD // b6 Error mode
load_done_evt DD // b8 Event for process loading done
UTState DD // bc Head of Univeral Thunk list
unknown5 DD // c0 Unknown (NT)
locale DD // c4 Locale to be queried by GetThreadLocale (NT)
ENDS