Operating Systems

Programming Projects

Due at midnight on the specified due date. All projects must conform to the style guidelines for this class (see below).

1. Due Thursday, September 2: bcount - count the occurrences of a specified byte in a file. Individual project.
2. Due Thursday, September 16: slush - the SLU shell. Work in pairs.
3. Due Tuesday, September 28: crack - multithreaded brute-force password hash cracker. Individual project.
4. Due Tuesday, October 12 (in class): elevators - elevator simulations. Work in pairs.
5. Due Monday, November 8: malloc -Dynamic memory allocation routines. Individual project.
6. Due Thursday, November 18: longls -List files in a directory, with details. Individual project.
7. Due Monday, December 14 Not required - for extra credit: proxy - An HTTP proxy server. You may work in pairs. (Also see additional notes)

OS Source Code Style Guidelines

Source code for all OS programming projects must adhere to the following style guidelines:

File Naming and Compilation

Programming assignments will have a standard name, specified on the assignment handout. Your final product should compile without errors or warnings with the command "make [name]", where [name] is the assignment name. For example, the bcount assignment should compile with "make bcount". For simple assignments, you can accomplish this simply by naming your source file [name].c for C programs or [name].C or [name].cpp for C++ programs. For more complicated assignments (with multiple files or that need linked libraries), you'll need to write a makefile with an appropriate target.

Source Code Commenting

Source code for each project needs to be commented. Each file must have a header comment that includes your name, the date, and a brief description of the purpose of that file. Each function should have a header comment that includes at least the followwing information:

• Function name
• A brief description of what the function is doing
• Inputs, outputs, and return values.

Comments are often said to be either strategic or tactical. A strategic comment describes what a function or section of code is intended to do, and is placed before this code. A tactical comment describes what a single line of code is intended to do, and is placed, if possible, at the end of this line. Too many tactical comments can make code unreadable. For this reason, it is recommended to primarily use strategic comments, unless trying to explain very complicated code.

Indentation

Your code should have a consistent and readable indentation scheme. The text editor you use should assist and/or enforce this indentation. If your editor doesn't help with indentation, it's time to learn a decent editor, such as emacs.

Modularity

OS programming projects are going to require more lines of code than in most of your previous courses and it is important to logically break your code into modules and functions. A function should perform a specific task or a collection of small highly related tasks. Do not stuff all your code in the main function. Source code is easier to read and debug if it is divided into multiple functions. Longer assignments will require multiple source files.

Error Checking

The following need to be error-checked in all programs:

• Number of command line arguments
• Command line argument values
• Return values of system calls that might fail.

If an error occurs make sure to output a meaningful error message to stderr/cerr and have your program exit gracefully.