You guys are talking a bit above my level of understanding of OS's. Would the move to a SrongArm (or other) 32 bit processor and a new 32 bit PALM OS
present the same type of problems that MSFT faced when they moved from a 16 bit OS to the 32 bit WIN95/98, where they had to include code to handle the
thousands of legacy 16 bit and MSDOS apps that were out there? And if so, would a new 32 bit PALM OS then be more bloated, need more memory, run
Well, since I started the original discussion, I'll feel free to explain the issue at hand.
If Palm were to move it's handheld line to a different OS (say StrongArm), then the programs out there, that currently run on the Motorola Dragonball (in the current PALM's/visor's/TRg's and CLIe's) would not be able to run natively.
Most programs available are in "binary" format. What that means is that the only thing that the program contains is the "raw" instructions to the microprocessor that executes them.
The "raw instructions" for a variety of reasons are usually completely different from one processor to the other. That is why, you cannot natively execute a windows program on a sun or alpha machine.
The issues that microsoft had when moving from 16bt windows to 32bit windows was not that bad, because the later generation of X86 processors (the 486's ,Pentimus, Athlons etc.) all support native execution of all programs that were designed all the way back to the original 8086!
I don't know of any ARM core, or any other core that can execute the Dragonball processors instructions natively. Hence the problem. (and the 2 solutions that I suggested: 1. Have software emulation, 2. Have a dragonball co-processor).
TG |
