how does the application interact with the RTOS
The RTOS has an API - a set of function calls - that the application calls. For example, to create an RTOS task, you call the RTOS API function that creates a task for you. There are other API calls for sending messages, etc.
I believe in uCOS you also need wrappers on interrupt functions to tell the RTOS when you are inside an interrupt.
Inturn how does the RTOS interact with the controller (same as windows
ineracts with the intel processor?)
Normally this class of RTOS will just need to use one of the microcontrollers timer peripherals to generate a periodic tick interrupt. It may also need to use the software interrupt vector.
we specify the location of RAM, ROM, stack etc., but how are the ports
identified via the C program i.e., we specify some hex value in our
program but how are this linked back to the controller
I don't understand what you are asking in this question.
how does the rtos know where to start the execution of the program.
Unless you modify it otherwise, the C start up code will call main() as normal. Your application code in main() will then create some tasks using the RTOS API before starting the RTOS. You can also create new tasks from existing tasks after the RTOS has started.
once the application is loaded into the ROM and on switching on the
embedded device, how does it know where to start exectuing the
uCOS is statically linked. It just creates an executable binary, just as if you were not using an RTOS. When the program is compiled and linked and loaded into the microcontroller, on reset the microcontroller will run whichever code the reset vector tells it to. This will normally be C start up code, which then calls main, which then runs your application code, which will then create RTOS tasks, and then start the RTOS. From that point on the RTOS decides which task to run when.