Mr Draper,
I decided to post seperatley on the multiprocessor/multi core issue as this is a different subject all together.
A single application running is referred to as a process, within a process there is typically one thread of execution unless the developer themselves decide to start up particular tasks on a seperate thread.
Common practice nowadays is to have the user interface on one thread and a second thread (or indeed more) for the actual processing, this allows the user interface to continue to be responsive even while heavy computation takes place.
A multi-core machine is effectively more than 1 CPU on a single chip - thus a dual core machine allows two threads to be executed simultaneously. A multi-processor machine is one as in your example where more than one chip is implemented (each chip could have multiple cores).
It is the operating systems task scheduler that decides what will run on which cores/cpu's - typically (as is the case with Windows) the first CPU is the only CPU the operating system itself will run on so will achieve the highest utilisation.
Writing multi-threaded code is not simple to do by any means as you have many timing issues - for example one thread may try reading an area of memory as another is writing to it and thus garbage may be read as it was changed half way through the operation. In programming parlence Semaphores and Critical Sections are often used to prevent this, however if you read up on those and why they are used you will gain an appreciation on why multi-threaded applications are more costly and time consuming to develop.
Multi-threading an application only makes sense if you can perform two operations at the same time that are not interdependent. Server based applications are a prime example of good use of multi-threading however typical user based applications spend most of the time waiting for the user so benefit little.
Because each process has at least a single thread, the more concurrent applications running the more the cores/cpu's will be utilised.