The title says it all: is there a way to get an older program designed to use a single CPU core to use multiple CPU cores?
Unfortunately, a legacy program written for a single CPU cannot be forced to use multiple CPU cores. The usage of multiple CPU cores requires multiple threads, which need to communicate with each other while ensuring that race conditions and other problems do not occur. An older application cannot be made to use more than CPU core unless it is rewritten to do so, and only if the nature of the application allows it to be parallelized.
There are at least three techniques for exploiting multiple processors in a program designed for using a single core. The most straightforward of these techniques is to use libraries and system code that uses multiple cores or can execute at least partially in parallel with the application code. Garbage collection is an example of functionality that can be parallelized and might be possible to do in parallel with application execution. Even without automatic memory management, there is some potential for parallelism in memory deallocation functions because the memory allocator may have some work to do beyond simply marking the section of memory as available.
A second technique is binary translation. While this might be considered "rewriting the application", it is done by software and without access to source code. Producing thread-level parallelism seems not to have been the main goal of most research and development using binary translation (which often concerns running legacy code on a different ISA, exploiting ISA extensions or optimizing for a particular microarchitecture, and using dynamic information to provide higher quality profile-guided optimization), but the potential is obvious.
A third technique is speculative multithreading. Currently no processors (that I know of) support hardware-managed speculative multithreading. However, with the introduction of hardware transactional memory, having a runtime system implement such becomes somewhat more practical because the HTM can be used to detect conflicts in memory use. Software-managed speculative multithreading would typically involve some binary translation, but its speculative nature justifies considering a separate technique.
The practicality of these techniques is limited by costs associated with existing systems (including the cost of communication between threads and of spawning threads), by the limited parallelism that they can exploit, and by the limited return on investment (important applications that can be beneficially parallelized are likely to be rewritten, many applications would benefit relatively little if at all from such techniques (especially with power/thermal limits allowing a single core to run at a higher frequency than multiple cores), and the development costs are significant). Yet these techniques do exist and it is theoretically possible to use multiple cores with an application designed to use a single core.
No it can't be. A program is explicitly written to use multiple cores. It is not trivial to do the job in multiple cores. It requires synchronizations of all threads. Like one throws the ball, the other catches, one polishes the ball, one cleans, one check the ball whether it has good amount of air in it. Now imagine each character as running in a thread independently of each other. Someone tries to catch the ball when its not thrown. Or someone tries to polish the ball when it is being played. Or two characters trying to catch and throw the ball simultaneously. There are so many ways to crash. So programmers need to carefully redesign a single core application so that it can take advantage of multiple cores.