10

I feel like I used to know the answer to this...

In classic Mac days, probably the early 90s and before, some applications would have a cursive / decorative ƒ character in their names.

What was the significance of this?

  • 1
    Perhaps it's related to Apple's ][. – wizzwizz4 Mar 9 '17 at 7:44
  • 1
    This has nothing to do with an Apple ][. APPLE]['s did not have non fixed fonts except within applications. There were no folders. – Rowan Hawkins Mar 9 '17 at 8:49
  • 1
    There were folders on ProDOS and I'm pretty sure on SoS for Apple ///. The Apple II got them before the Mac (1983 for ProDOS & 1985 for the Mac according to wikipedia) – PeterI Mar 9 '17 at 9:20
  • 1
    MFS always had folder[s] but until HFS was not truly hierarchical. Not sure whether ProDOS was similar. – Coxy Mar 9 '17 at 11:24
  • 2
    ProDOS (and SOS from which it’s derived) are truly hierarchical but until the Apple IIgs were command-line oriented via BASIC rather than graphical, and the Apple II didn’t really have things like ƒ in its character set, so nobody used conventions like that. – Chris Hanson Mar 9 '17 at 19:44
17

It wasn’t typically in the application’s name, it was in the name of the folder containing the application, and used to mean “folder.”

For example, the folder containing SurfWriter, its Apple Guide help file, its template files, and so on may have been named “SurfWriter ƒ” either by the developer or by a user.

Often developers named the folder something like “SurfWriter 1.0.5 Folder” and a user would change it to “SurfWriter ƒ” to make things line up more easily, but still return a distinguishable result when searching their disk.

  • 5
    MacOS limited filenames to 31 characters so ƒ was a way to tighten up the name as well. Due to an obscure Finder bug • (option-8) would sort last in the list so users would put that on the front of filenames to make things load last. MacOS and HFS tolerated any characters in MacRoman in filenames except for : the path separator. – Michael Shopsin Mar 9 '17 at 16:25
  • @MichaelShopsin that's not a bug -- it's a feature! option-8 produces the bullet character which had a high ASCII code, higher than any letter or number and most other symbols. So it was last in a list of things sorted alphanumerically. – Josh Feb 22 '18 at 23:06
  • @Josh the Finder sort did not use ASCII order, for example a is 0x61 while A is 0x41 but they would get the same priority and a 0x61 would come before B 0x41. Unix style pure ASCII sorts put capital letters before lower case as well as other counter-intuitive sorting with accent characters. – Michael Shopsin Feb 23 '18 at 15:50
  • Point taken, I suppose i should have said that it uses case insensitive ASCII order, that is, essentially all characters were converted to either uppercase or lowercase. I can do some test to confirm, but this is evidenced by another common trick: prefacing a name with a space character (ASCII 0x20) to place it at the top of a list – Josh Feb 23 '18 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.