Lab 1: Heap manager
Lab 2: Shell
Lab 3: Elevator
Lab 4: Devil Filer
We intend a fifth lab adding networking and measurement to the Devil Filer.-->

Policies for the Labs

We expect you to know this information.

Handing in your work

Use the websubmit tool to submit a directory of files for each lab: https://www.cs.duke.edu/csed/websubmit
Submit as often as you like. All submissions are timestamped. The latest eligible submission will be graded.
Submissions are logged by the NetID of the submitter. Please select one member of your group to submit, and try to stick to it. Multiple submissions from different NetIDs are a pain for us.
The submitted directory must contain all relevant source code files and a file called README in a specified format. It is important that you provide all requested information in your README.
The websubmit tool is standard at cs.duke.edu. Please let us know of any problems.

Using other people's code

We all know that there are various fragments of code available on the web that are relevant to the assignments. You are not prohibited from looking at material on the web. We believe that we have provided you with enough to start with that it will not benefit you to import source code from anywhere else. The point of the lab is to learn, and we want to make it easy for you to learn!

When you hand in the lab, we expect that your code is your own. If you incorporate source code from some external source, you must add a comment indicating the imported code and the source of that code. You must note all sources of imported code in your submitted README file. You should be able to explain any part of your code in detail, and why you chose to do it that way and not some other way. If you encounter code from some external source that diminishes your opportunity to learn by doing the lab, please inform us (we may not be aware of it).

Academic dishonesty. Be sure that you are familiar with the policy on collaboration and other policies. In particular, sharing of code among groups is strongly discouraged, and is allowable only by mutual consent. Collaboration that does not involve sharing code is allowable and encouraged. Do not obtain code from previous semesters. Take care to acknowledge any sources of code or assistance in your README.

Resources

About C. The first labs ask you to program in the C programming language. We will discuss some aspects of C in lectures and recitations, and we will provide relevant examples, but we do not teach C. If C is unfamiliar to you, you will need to read up from some other sources, or spend more time with the sample programs. You should take the time to look through some of the supporting materials on the resources page. We find that the students who struggle most have not taken the time to read up, and as a result they have found themselves spending more time debugging.

About Unix. To do the labs you will need a Unix development environment. If you are a CompSci or Engineering major then you have access to Unix systems in those departments (e.g., login.cs.duke.edu). We can create term accounts to get access to Unix systems in the CompSci department if you need it. Duke also runs a virtual machine service that can give you a private Unix system for your use. You are welcome to use your own machine if it provides a suitable Unix development environment. Apple provides a good environment for Macs, and there is software that purports to provide a usable Unix environment over Windows (but be warned that may be more trouble than it's worth).

If you are using Mac OSX. Go download and install Xcode from developer.apple.com. Launch Xcode, go to Preferences->Downloads and download the command-line tools. You may find this discussion helpful for later versions of Xcode, which says the command line tools can now be downloaded by typing 'xcode-select --install' in Terminal (after installing Xcode) or by going to developer downloads page. Next launch the built-in Mac OSX Terminal application (Applications.Utilities.Terminal). That will give you a command-line shell with the right tools.

Note also that the gdb debugger has been replaced with lldb in OSX Mavericks.

If you are using Windows. You need a Unix development environment, and Windows does not provide one (see above). If you really want to try, you might start by looking into Cygwin (google it). Some students have been successful with Cygwin, but we cannot provide support for it.

Once you have a command-line shell on a suitable system. You can compile C code with the gcc compiler, and/or build programs with the make utility. You can use the man command to learn about any C builtin library API and/or system call API or command. E.g., try man malloc or man strcpy.