1. 23
  1.  

  2. 6

    The Be Book still stands as the gold standard for me for OS documentation, and the Be API is the last one I that I still feel I could keep in my head all at once.

    1. 4

      There are some gems in here:

      You can kill the calling thread through exit_thread(), or kill some other thread through kill_thread(). Feeling itchy? Try killing an entire team of threads: The kill_team() function is more than a system call. It’s therapy.

      1. 7

        Oh yeah. My favorite was always:

        int32 is_computer_on();
        Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined.
        
      2. 2

        A lot of what I’m reading sounds like macOS’s AppKit. Even the language in the docs, though more relaxed in tone, uses sentence structure like “To do ___, you call the ___ function”, which feels just like the way Apple’s Objective-C docs explain a common pattern you’re meant to use. What’s the relationship between NeXT and Be?

        1. 8

          None, but the relationship between Apple and Be is quite strong. Be was founded by Jean-Louis Gassée, who had been an executive at Apple who headed the Macintosh team after Jobs’s departure from Apple, and started the Newton MessagePad project. Apple considered buying Be to be the next generation Mac operating system, but ended up buying NeXT instead.

          1. 2

            See @lorddimwit’s reply for a direct answer, but also worth noting is that in the mid-90s, this was very much the canonical way manuals were expected to be written - i.e. explicitly task-oriented, and absolutely not using the passive voice like I just did.