views:

37

answers:

3

My question is:

  1. What is the flow of execution of an executable file in WINDOWS? (i.e. What happens when we start a application.)
  2. How does the OS integrate with the application to operate or handle the application?
  3. Does it have a central control place that checks execution of each file or process?
  4. Is the process registered in the execution directory? (if any)
  5. What actually happens that makes the file perform its desired task within WINDOWS environment?

All help is appreciated...

A: 

This is high-level and misses many details:

  1. The OS reads the PE Header to find the dlls that the exe depends on and the exe's entry point
  2. The DllMain function in all linked dlls is called with the DLL_PROCESS_ATTACH message
  3. The entry point of the exe is called with the appropriate arguments

There is no "execution directory" or other central control other than the kernel itself. However, there are APIs that allow you to enumerate and query the currently-running processes, such as EnumProcesses.

JSBangs
A: 

Your question isn't very clear, but I'll try to explain.

When you open an application, it is loaded into RAM from your disk. The operating system jumps to the entry point of the application.

The OS provides all the calls required for showing a window, connecting with stuff and receiving user input. It also manages processing time, dividing it evenly between applications.

FrozenFire
+1  A: 

There's plenty going on beyond the stages already stated (loading the PE, enumerating the dlls it depends on, calling their entry points and calling the exe entry point).

Probably the earliest action is the OS and the processor collaborating to create a new address space infrastructure (I think essentially a dedicated TLB). The OS initializes a Process Environment Block, with process-wide data (e.g., Process ID and environment variables). It initializes a Thread Environment Block, with thread-specific data (thread id, SEH root handlers, etc). Once an appropriate address is selected for every dll and it is loaded there, re-addressing of exported functions happens by the windows loader. (very briefly - at compile time, the dll cannot know the address at which it will be loaded by every consumer exe. the actual call addresses of its functions is thus determined only at load time). There are initializations of memory pages shared between processes - for windows messages, for example - and I think some initialization of disk-paging structures. there's PLENTY more going on. The main windows component involved is indeed the windows loader, but the kernel and executive are involved. Finally, the exe entry point is called - it is by default BaseProcessStart.

Typically a lot of preparation happens still after that, above the OS level, depending on used frameworks (canonical ones being CRT for native code and the CLR for managed): the framework must initialize its own internal structures to be able to deliver services to the application - memory management, exception handling, I/O, you name it.

A great place to go for such in depth discussions is Windows Internals. You can also dig a bit deeper in forums like SO, but you have to be able to break it down into more focused bits. As phrased, this is really too much for an SO post.

Ofek Shilon
Can we read the process id. and the information related to the process using c++ or java or any other programming language.????
prasad
Yes, there are Win32 APIs for that, available from probably any language. For your currently executing process- there's GetProcessID: http://msdn.microsoft.com/en-us/library/ms683215%28VS.85%29.aspx . For all currently running processes, there's EnumProcesses - http://msdn.microsoft.com/en-us/library/ms682629%28VS.85%29.aspxFor system-wi
Ofek Shilon