Sometimes I don't understand either, I a'm a developer,
but I a'm not an Apple developer!
(In the sense Nathan Duran)
Am 03.09.2005 um 02:30 schrieb email@hidden:
On Sep 2, 2005, at 6:29 PM, Marco Ugolini wrote:
In a message dated Fri, 2 Sep 2005 10:43:17, Rolf Gierling wrote:
1) Pre-Mac OS 10.2, ColorSync internally used FSSpec-based file I/O.
Path-based locations were internally converted into FSSpecs.
2) For slightly better performance on Mac OS 10.2, ColorSync
internally uses POSIX-based file I/O. FSSpec-based locations are
internally converted into posix paths.
Does everyone else understand this, or am I the only dummy around
here going: "Uh?"?
I don't think Rolf Gierling failed horribly in explaining what was
going on. The issue is not poor definitions but rather programmer
jargon that is difficult to fully explain to those not fully steeped
in Mac OS X programming issues. Below is my best attempt at a
layman's explanation.
As I stated in a previous post, there are several ways for a
programmer to specify a file on Mac OS X. An FSSpec is one way,
although it's really a hold-over from the pre-OS X days and it has
some limitations such as being set up specifically only for HFS+
volumes and only has space for 63 character file names. For that
reason, operating system calls which accept an FSSpec need to convert
that FSSpec to some other form which it can then pass on to
"lower-level" operating system calls. Hence there is a little bit of
conversion overhead each time you use an FSSpec to specify a file.
So what Rolf Gierling is saying is that, before 10.2, ColorSync
actually did things backwards by converting a file path to an FSSpec
and then using the FSSpec each time it wanted to access the file.
After 10.2, they got smart and did the opposite by converting all
FSSpec's to file paths immediately. File paths can then be passed
directly to "low-level" operating system calls (part of a set of UNIX
system calls which are standardized in the POSIX standard) which do
not do any further conversion of the file path and hence have less
overhead.
