Richard Hartman wrote:
> For those of -not- using "certain devices", who only
> need the single-byte character support
(This is more of a David Fedor topic but) the Palm design lets you write
a single executable that can run on any organizer in the field, so the
code must adapt at run-time instead of compile-time. For example, a
properly i18n'd English app should run perfectly on a Japanese WorkPad.
Except for the whole interface being in English, that is.
> we shouldn't have to pay the overhead of library routines built
> for multi-byte support.
The ROM on each device is built for the encoding in that device. For
single byte encodings (all except Japanese, for now) the basic text
routines are probably quite trivially implemented.
> #if MULTIBYTE_SUPPORT
> #define StrCpy mbStrCpy
> #define XCHAR int
I guess the Palm folks should answer about the reasons they chose
run-time encoding adaptability instead of Microsoft style compile-time
configuration as you're asking for here.
> btw: is there any real reason that "StrCpy" is being
> used by the Palm libraries instead of the standard
> name, "strcpy"?
Pure evil, as best I can determine. :-)
-slj-
