Why is there no main() function in vxWorks?

Question

When using vxWorks as a development platform, we can't write our application with the standard main() function. Why can't we have a main function?

Monteverdi

Answer 1

Before the 6.0 version VxWorks only supported kernel execution environment for tasks and did not support processes, which is the traditional application execution environment on OS like Unix or Windows. Tasks have an entry point which is the address of the code to execute as a task. This address corresponds to a C or assembly function. It can be a symbol named "main" but there are C/C++ language assumptions about the main() function that are not supported in the kernel environment (in particular the traditional handling of the argc and argv parameters). Furthermore, prior to VxWorks 6.0, all tasks execute kernel code. You can picture the kernel as a common repository of code all linked together and then you'll see that you cannot have several symbols of the same name ("main") since this would create name collisions.

Now this is accurate only if you link your application code to the kernel image. If you were to download your application code then the module loader will accept to load several modules each with a main() routine. However the last "main" symbol registered in the system symbol table is the only one you can access via the target shell. If you want to start tasks executing the code of one of the first loaded modules you'd have to use the addresses of the previous main() function. This is possible but not convenient. It is far more practical to give different names to the entry points of tasks (may be like "xxxStart" where "xxx" is a name meaningful for what the task is supposed to do).

Starting with VxWorks 6.0 the OS supports a process environment. This means, among many other things, that you can have a traditional main() routine and that its argc and argv parameters are properly handled, and that the application code is executing in a context (user context) which is different from the kernel context, thus ensuring the isolation between application code (which can be flaky) and kernel code (which is not supposed to be flaky). PAD

Monteverdi