____                                         ___   ____  _
   |  _ \ _ __ ___   ___ ___  ___ ___  ___  ___ ( _ ) |  _ \(_)_ __   ___  ___
   | |_) | '__/ _ \ / __/ _ \/ __/ __|/ _ \/ __|/ _ \/\ |_) | | '_ \ / _ \/ __|
   |  __/| | | (_) | (_|  __/\__ \__ \  __/\__ \ (_>  <  __/| | |_) |  __/\__ \
   |_|   |_|  \___/ \___\___||___/___/\___||___/\___/\/_|   |_| .__/ \___||___/
                                                              |_|

Description
-----------

When you start a program through a command in the shell, or other interaction
with the operating system, the system will spawn a new process for that
program. But this is not the only way that new processes are created, it is
also possible to create processes programmatically.

This programming exercise is about creating two processes programmatically, and
connecting the created processes with a unidirectional communication channel, a
pipe.

The semantics of process creation are different between different families of
operating systems. In POSIX compliant systems, there is the fork system call,
which duplicates the currently executing process and all its resources. On the
other hand, the CreateProcess Function on Windows creates a new process from a
blank slate, without duplicating the current process.

Because of this difference in semantics, the programming interface is used very
differently as well. The difference is outlined in the sketch below:


  POSIX semantics:               |   Windows semantics:
                                 |
           ...                   |                        ...
            |                    |                         |
            v                    |                         v
     fork() * ---- x             |         CreateProcess() *      o
            |      |             |                         |      |
   pid != 0 |      | pid == 0    |                         |      |
            v      v             |                         v      |
     wait() *      * exec(...)   |   WaitForSingleObject() *      |
           ---     |             |                        ---     |
                  ...            |                               ...
                   |             |                                |
                   v             |                                v
                   * exit()      |                                * exit()
           ---    ---            |                        ---    ---
            |                    |                         |
            v                    |                         v
           ...                   |                        ...
                                 |

Exercise Questions
------------------

Choose whether to do this exercise on Windows or a UNIX-like system. Depending
on your choice of System, use the following functions to implement process
creation:

  Windows: CreateProcess
  POSIX: fork, exec*

The code already implements the comprehension of the command line arguments,
and provides your code with two arrays representing a first and a second
command. The first element of these arrays is the program to start, and all
further arguments are the arguments that are to be passed to the program as
parameters. Remember that on UNIX, the first argument to the program executing
through exec is the name of the program itself. Refer to `man 3 exec` for
details.

When you are able to successfully start the two processes, begin to connect
them through a pipe, such that the output of the first command becomes the
input of the second command. Use the following functions to implement the pipe:

  Windows: CreatePipe
  POSIX: pipe, dup*

Content
-------

This repository contains the following source code files:

processes_pipes.c
~~~~~~~~~~~~~~~~~

This file contains the main function, as well as several utilitiy functions for
input and output, which are explained with inline comments. Extend the main
function with your code for process creation and creation of the pipe.

Credits
-------

This repository was created by the Operating Systems and Middleware Group at
Hasso Plattner Institute, University of Potsdam, to help teach operating system
behaviour and internals.

For feedback and more information, contact bs@hpi.de