2) Figure out how to handle the various file systems that people are going to be using. HFS can't handle filenames over 32 characters, HFS+ can, but they both use colons as path separators, while the OS X standard filename uses the UNIX /. Applications generally expect the colon, so an intermediate layer converts the path on the fly. File names that include a / are also converted to colons. Colons are converted to /s. And so it goes... if they don't watch out, they're going to end up with a mess like DOS filename conversion in OS 8 (which really sucked; System 7 had better compatibility). If you read the article that this thread was linked to, it covers what will happen in regards to file systems, and also the use of colons and / within OS X.
- Early on, case-sensitivity was thought be a likely stumbling block. Apple's HFS+ preserves the case of files while actually remaining case-insensitive. This stands in stark contrast to nearly all Unix file systems that are strictly case-sensitive. Surprisingly, conflicts have been rare to date. Previous ports to Windows (e.g., CygWin32) have already addressed potential conflicts in several software projects.
- Another difference in the path separators used by the file systems was also an early issue. HFS+ uses a colon (":"), while UFS uses a slash ("/"). This is now handled transparently by transforming the strings automatically, so that Carbon and Classic applications see the colon they're expecting while all other portions of the operating system see the slash.
So... they have already covered the colon and slash difficulties. In regards to the 'design over functionality', I must admit that Quicktime 4 wasn't all that functional, but the preview of Quicktime 5 (I think it was) in DP4 has put in Aqua buttons, and instead of the Scroll Wheel for volume, there are buttons, I think.
