Red flags are statements of concern, things that need to be taken care of if the project is to succeed. Most red flags are threats of various kinds. It is important both to state the flag and to declare an action to take care of it.
(1) mv command can only move file object down the file system structure. More time is required to fix this problem.
(2) Code for all of the file system files must be changed to represent changes make in the command interpreter.
(2) More work needs to be done on the file system and parser to make the
command interpreter all work together properly as one unit. This is mostly
due for next
report.
When a red flag is resolved, move it into this section at the next report, and drop it from this section at the report after that.
(2) Command interpreter is not done and is not required for this PAR.
Each promise consists of a person responsible, the condition of satisfaction, and the due date. The table provides extra columns to state the actual completion date and when it was due.
| Responsibility | Assignment | Planned Date | Actual Date | Due Date |
| Dennis | Parser Revisions | 3/12/01 | 2/14/01 | |
| John | mv command | 3/12/01 | 2/28/01 | |
| Team | Set up meeting with Professor Denning | 3/14/01 | 3/14/01 | |
| Team | Baseline simulator works (+ pipes, I/O redirection) | 3/26/01 | 3/28/01 | |
| TBD | Enhanced OS | 4/9/01 | 4/11/01 | |
| Team | Whole simulator works; draft report URL submitted | 4/9/01 | 4/11/01 | |
| John | Project URL delivered | 4/21/01 | 4/23/01 | |
| Team | Exihibition | 5/1/01 | 5/1/01 |
When a promise is completed it is moved to this section.
| Responsibility | Assignment | Planned Date | Actual Date | Due Date |
| Team | Form team | 1/17/01 | 1/17/01 | 1/17/01 |
| Team | Select team leader | 1/24/01 | 1/22/01 | |
| Ely | Create Console Window | 1/24/01 | 1/24/01 | 1/31/01 |
| Ely | Console window operational | 1/29/01 | 1/27/01 | 1/31/01 |
| John | System Specifications | 2/12/01 | 2/12/01 | 2/14/01 |
| Dennis | Prototype Parser Works | 2/12/01 | 2/13/01 | 2/14/01 |
| John & Ely | Testing and Understanding of Parser | 2/12/01 | 2/13/01 | 2/14/01 |
| John | File System(all but mv) | 2/26/01 | 2/27/01 | 2/28/01 |
| John | 'cat' function operational | 2/26/01 | 2/27/01 | 2/28/01 |
| Dennis & Ely | Testing and Understanding of File System | 2/26/01 | 2/28/01 | 2/28/01 |
| Dennis | Command interpreter operational | 3/12/01 | 3/12/01 | 3/14/01 |
The Command Interpreter:
The command interpreter is a complex piece that includes all the various functions and classes needed to create a program and execute it in an organized fashion. It includes the VMachine, VMMonitor, StreamManager, PipeManager, Login, and Shell classes. These classes are all organized according the model described in the Virtual Machine Notes. Each class had an important function, specifically, the VMachine class wraps the programs, the VMMonitor that creates, deletes, and otherwise controls the Vmachines, the StreamManager and PipeManager create and handle files and pipes respectively, Login creates a user and a shell after authentication, and finally the Shell contains the means to parse and load our executables.
There
are a few differences in our Virtual Machine model compared to that described
in the Virtual Machine notes. The largest and most important difference is
that we do not use the sibling handle and instead have the parent contain an
array or list of pointers to all its children. We did this because we believed
that the method of seeking out a particular Virtual Machine and modifying the
Process Tree was not very efficient and neat. By using this method we can seek
and modify the tree by looking at only one object with the particular child
array. Other minor differences
are that instead of using a thread ID in the Virtual Machine wrapper, we use a
pointer to Handle of the particular Virtual Machine, which has the thread ID
as the Handle ID. The handles are still contained by the user and this is the
only location that contains a pointer the handle thus allowing DeleteVM() an
easy time in removing Virtual Machines and their respective Handles.
We had various difficulties in handling the different cases in which login and opendevice() were called. These two cases, first original login, and other subsequent logins had to be handled differently because each case had a different set of information available to them. Furthermore, we had to do some things differently since we were doing the multiple users enhancement and thus we had to modify the Virtual Machine tree by creating a new tree during a new login.
It is impossible to show that this is working without a demonstration.
ConsoleWindow.java
FileClassLoader.java
help.java
KeyboardBuffer.java
listproc.java
login.java
logout.java
Osvm.java
sample.java
shell.java
User.java
VMachine.java
VMMonitor.java
Contents | PAR #1 | PAR #2 | PAR #3 | PAR #4 | PAR #5 | PAR #6