Windows NT Systems Programming: Spring 1999

[ Home | Syllabus | Course Notes | Assignments | Search]

1. You must program one and test one from the following two assignments
   1. Assignment 5
   2. Assignment 6 
2. For students who did not program Assignment 4, you must do Assignment 7.

Programming/Testing Policy

In order to gain experience with more examples without over burdening either me or you (too much), I want to try a split programming/testing policy. For selected assignments, one half the class will program it and one half will test it. How to decide? You must do an equal amount of both. You should e-mail you choice (program/grade) for the selected assignments. If more than half choose one option, then the first half repsonding will get their choice. I will notify by e-mail which you should do. If not enough respond, then I will assign, Decision will be made within 24 hours after the Assignment is given.

Since testing is itself an important activity in software engineering, testers will also be graded (by me). Testers are required to submit a report summarizes their testing. This report will consist of 1) Description of the tests performed and rationale for performing them (files used for testing can be attached separately if appropriate) 2) results of the tests 3) recommendation for grade (outstanding - should be placed on the website, solid - all major requirements met, unsatisfactory - some requirements not met or significant errors in the solution). This report will typically be less than a page. The original programmer will receive a copy of this report (after I review it) along with my decision. However, the identity of the tester will not be forwarded to the original programmer. Test Reports are due a week after they are assigned.

Grading the test reports: This grade is assigned by me and I will use the same scale (outstanding, solid, unsatisfactory). If I find your test report to be unsatisfactory, I will grade the program myself (which will make me very unhappy). Outstanding testing will also be published on the web site (with the identity of the programmer removed unless the program was considered outstanding).

Confused? Well this is an experiment. Remember the guiding principles.

• We are here to learn

• Testing is a very important activity

• Learn from your peers

Programming Assignments

1. Change Version 0 so that it does not store the text of all messages but rather uses direct file access to read a message when requested by the user to "Show" a message. IT is OK to store Message Topics in memory but NOT the Message Text. Change all appropriate data structures. Submit your source code and a make file in a compressed zip file using the "submit wild" command. Due: Jan 21.
   It is OK (even necessary) to store at least one Message Text body. It is OK to store all the message topics in memory but no more than 2 message text bodies. (i.e. its space complexity for message text bodies should be constant regardless of the number of messages). The User interface and file structure should remain the same.

2. Write a recursive program which will take as input a file extension (like "txt") and print a list of all files in the current directory tree (this is the current directory and all its sub directories recursively) which have that extension. Relevant material is found on pages 56-58 of the Win32 textbook) Due Feb 1
   OBJECTIVES : 1) Practice enumerating a list of kernel objects. 2) Use pattern matching in directory searches 3) See the beauty of recursive programming in action.
   (Note: only half the class has to do this assignment and the other half will grade it - see programming/grading policy.
   GRADING CRITERIA: Grader must define a set of tests and create a testing directory tree with several files with different extensions. The depth of this test directory tree must be at least 3. Three grades are possible: Outstanding, Good, Poor. All outstanding solutions will be published on the web site. A solution which only prints files in the current directory is poor.
   HINT: a recursive solution is the most elegant and easiest to write.

   1. Prompts for file extension
   2. Prints all files in the current directory
   3. Prints all files in subdirectories to any depth.
   4. Readable Code

   (For Testers: click to get testing report)

3. UPPER_CASE_SERVER: Write a client/server system which will take any string typed in at the client, send it to the server which will convert the string entirely to upper case sending the converted string back to the client to be displayed to the user. Since the string can be of arbitrary size, the client should send the size to the server so it can dynamically allocate the string. DUE Feb 2
   OBJECTIVES: 1) Practice programming with Sockets 2) Use dynamic memory allocation
   HINT: there is a function for converting to upper case in the standard library
   GRADING CRITERIA: Grade must define a set of tests and submit the results of testing. Testing should include long strings.
   
   1. Dynamically allocates string
   2. Converts short strings
   3. Converts long strings

   (For Testers: click to get testing report)

4. Monitor Version 3 of  NOMS: modify the multiclient server (Version 3) to allow its use to be monitored by a special monitoring client. When you  run the monitoring client, it will tell you whenever a new message client connects to the server. It will also notify anytime a client makes a request on the server. Due: Feb 16.
   IMPLEMENTATION REQUIREMENTS:
   1. Each message client  thread will be assigned a unique ID.
   2. Monitor clients will connect to a separate port from the message clients.
   3. Monitors can connect and disconnect at any time. You can connect multiple times to a running server.
   4. The server for a monitor client will run in its own thread.  (you can limit to one monitor thread at a time).
   5. You must use one of the following synchronization primitives to prevent the various monitor and message threads from simultaneously changing shared variables used for monitoring (critical section, mutex, semaphore, events). In particular your solution should guarantee that no monitoring information is lost due to a fast message client and a slow monitor client (you are allowed to block the message client). Also your monitoring thread should correctly process information for all client threads without losing information.
      SUGGESTION: Use a shared variables for communicating Client Id and RPC function call. Any message thread can "produce" new values and store them in these variables, but must make sure any previous values have been "consumed" by the monitor thread.

   Output Requirements from the Monitoring Client: every RPC from a message client must be displayed on the monitor client screen. Ths output should contain the name of the function being called and the client number assigned to that client.

   It is OK to work on this project in teams of 2. In that case, you must provide a testing report which describes the nature and outcome of your testing (test passed/failed).

Copyright chris wild 1999.
For problems or questions regarding this web contact [Dr. Wild].
Last updated: March 10, 1999.