rajiv@ur-valhalla.UUCP (Rajiv Arora) (10/09/86)
Hi, Pardon my ignorance, but I don't quite understand why initialized single sided disks, using the MacPlus with System 3.2 and Finder 5.3, show "4K in disk 387K free". As I remember, it used to be "0K in disk 399K free". I thought the single sided initialization created an MFS volume as before. Why, then, the missing 9K? While I'm at it, here's another question for the cognoscenti: Why does Switcher 5.0 run out of memory when I try to open more than one application? This happens on the upgraded 512K Macs (you know, the in-between Mac). Before the upgrade, I could easily open say, MacDraw, Word and Finder. Anyone have the answer? Thanks in advance.
dlc@lanl.ARPA (Dale Carstensen) (10/10/86)
It can't hurt to run this information through again. It's bound to be more useful than talking about a 68030 Amiga -- I said talking, not having :-) The new ROMs, in any Mac, minus, zero, or plus, will only format a disk as MFS with an older System/Finder vintage (2/4 era.) The 4K is "BTree" (directory) space. The 9K is the switch from K=1000 to K=1024. Perhaps someone else knows about Switcher "running out of memory" on "upgraded" 512K Macs. Does "upgrade" mean an old Mac with the ROM/800K drive, or 512E, or both? (I know, the answer is yes.)
sdh@joevax.UUCP (The Doctor) (10/10/86)
> Pardon my ignorance, but I don't quite understand why initialized > single sided disks, using the MacPlus with System 3.2 and Finder 5.3, > show "4K in disk 387K free". As I remember, it used to be "0K in > disk 399K free". I thought the single sided initialization created > an MFS volume as before. Why, then, the missing 9K? First, the old versions of the finder did not correctly calculate the number of K free on a disk, I don't remember the exact details, but I believe it had to do with making 1K = 1000 bytes instead of 1024. Second, the new finder has corrected this bug. The 4K is probably from the file, DeskTop, which is invisible. The extra used space would be for a directory map. > While I'm at it, here's another question for the cognoscenti: > Why does Switcher 5.0 run out of memory when I try to open more than > one application? This happens on the upgraded 512K Macs (you know, the > in-between Mac). Before the upgrade, I could easily open say, MacDraw, > Word and Finder. Anyone have the answer? I haven't seen this happen. Have you checked the information window to show memory usage? Some memory may be lost because it is being used by the system heap. Do you have the RAM cache turned on? That would take a healthy chunk away. Hyperdrives will also cache 40K from you. Steve Hawley joevax!sdh
blh@vlsi.cs.cmu.edu (Bruce Horn) (10/13/86)
The way the Finder initially calculated disk space available was not a bug, but a "feature" (some of you have heard this before!) Steve Jobs said that people wanted to see 400K available on blank disks, and that I should make it so that was the case in the Finder. Since the original single-sided floppies held about 410,000 bytes, dividing by 1024 left exactly 400K; subtracting a few K for the DeskTop file made it less than 400K free. Dividing by 1000 instead of 1024 was basically a marketing decision, and an apparently defendable one: most naive users understood a K to be 1000, not some power of two near 1000. I imagine that Apple would have gotten more phone calls from naive users who wanted to know why they didn't have 400K available on a disk than from computer-sophisticates who wanted to know why the Finder was "wrong". Debatable, to be sure. On something entirely different: given the latest version of LightspeedC, why would anyone want to use MPW? MacApp is the only reason I can think of, but someday LSC will have support for objects. (MacApp is a very nice package, by the way, and I would probably be using it if I could.) It seems to me that MPW will never be able to be as fast as LSC, but that LSC could well end up with all the features of MPW that you wanted (e.g. tight code optimization, maybe as a compiler option, and support for the object-oriented programming style). -- Bruce Horn, Carnegie Mellon CSD uucp: ...!seismo!cmucspt!cmu-cs-vlsi!blh ARPA: blh@vlsi.cs.cmu.edu