The Serial Experiments: Lain Game is in Japanese and is available at Toys n' Joys
Page1
Page2
Page 1 The first page is barely visible. What can be seen are:
that can identify
number that's
the semaphore.

It is most likely from
http://www.acm.uiuc.edu/bug/Be%20Book/The%20Kernel%20Kit/Semaphores.html

Page 2 The below is the first mostly visible page in the game. This content is also located a
http://www.acm.uiuc.edu/bug/Be%20Book/The%20Kernel%20Kit/Threads.html
Thread Function
When you call spawn_thread(), you must identify the new thread's thread function. This is a global C function (or a static C++ member function) that the new thread will execute when it's told to run. When the thread function exits, the thread is automatically killed. 

The thread_func type represents a pointer to a thread function: 


   typedef int32 (*thread_func)(void *);

The function accepts a pointer to a buffer of arbitrarily-typed data. What the function does with the data is up to your application. (See The Thread Function's Argument for more information and caveats.) 

The return value is a 32-bit integer value that's typically interpreted as an error code. To whom the value is returned is explored in Thread Function Return Values. 

The function's name isn't prescribed by the protocol; in other words, a thread function doesn't have to be named "thread_func". 
You specify a thread function by passing a thread_func as the first argument to spawn_thread(); the last argument to spawn_thread() is forwarded as the thread function's data argument. Since data is delivered as a void *, you have to cast the value to the appropriate type within your implementation of the thread function. For example, let's say you define a thread function called lister() that takes a pointer to a BList object as an argument: 


   int32 lister(void *data)
   {
      /* Cast the argument. */
      BList *listObj = (BList *)data;
      ...
   }

Page 4
Full text located
http://www.acm.uiuc.edu/bug/Be%20Book/The%20Kernel%20Kit/Images.html Loading an app image is like running a "sub-program." The image that you load is launched in much the same way as had you double-clicked it in the Tracker, or launched it from the command line. It runs in its own team--it doesn't share the address space of the application from which it was launched--and, generally, leads its own life. Any application can be loaded as an app image; you don't need to issue special compile instructions or otherwise manipulate the binary. The one requirement of an app image is that it must have a main() function; hardly a restrictive request. To load an app image, you call the load_image() function, the protocol for which is: thread_id load_image(int32 argc, const char **argv, const char **env) The function's first two arguments identify the app image (file) that you want to launch--we'll return to this in a moment. Having located the file, the function creates a new team, spawns a main thread in that team, and then returns the thread_id of that thread to you. The thread that's returned is the executable's main thread. It won't be running: To make it run you pass the thread_id to resume_thread() or wait_for_thread() (as explained in the major section "Threads and Teams"). The argc/argv argument pair is copied and forwarded to the new thread's main() function: The first string in the argv array must be the name of the image file that you want to launch; load_image() uses this string to find the file. You then install any other arguments you want in the array, and terminate the array with a NULL entry. argc is set to the number of entries in the argv array (not counting the terminating NULL). It's the caller's responsibility to free the argv array after load_image() returns (remember--the array is copied before it's passed to the new thread). Anything below this line is Tripod's doing.