Operating Systems

Laboratory Manual

Student Name Government College University Faisalabad

Preface

Table of contents

Lab # 1
Hard Disk Drive Setup - Partition and Format
This procedure explains how to setup a new hard disk. Warning - if you are setting up a hard disk which contains data, the following procedure would completely erase your hard disk and the data would be unrecoverable. Before a new hard disk can be used it needs to be setup. This involves partitioning and formatting the hard disk. Windows 98 or ME boot disk contains the required software to perform this procedure. FDISK.EXE and FORMAT.COM are the files required in your bootable floppy disk. Start the partition and format procedure by booting your PC using a Windows boot disk. Make sure you set the BIOS so that the boot sequence is set to detect the floppy disk first. If your system has no problems booting you will be presented with a Windows boot disk menu. This gives you the option to start the system with or without CDROM support. At this stage you do not need the CD-ROM support, so choose the option to boot without CD-ROM support. You should end up in the MS DOS prompt A: (A drive). From A: command prompt type FDISK. You will be presented with following message:

Choose "Y" to enable large disk support. You will now be presented with the FDISK main menu as shown below.

From the menu, choose option 1 - Create DOS partition or Logical DOS drive. Another menu will present the following options.

Choose option 1 - Create primary DOS Partition. FDISK verifies the integrity of your drive and will ask you if want to use the maximum available size of your hard disk to create the primary partition and set it active. To keep things simple we will create one large partition. Choose "Y" to use maximum available space. When the partition has been created successfully you will be notified by the system. Your drive is now known as C: (C drive). Press "Esc" to return to the menu. Press "Esc" again to exit FDISK. You need to restart your system for the changes to take effect. Leave boot disk in the drive. When the system reboots, choose start without CD-ROM from the boot disk menu. While booting from floppy disk you might get error message like "Invalid media type reading drive C" this is OK for this stage as the hard disk is not formatted. From A: command prompt type format c: You will get a message saying "WARNING, ALL DATA ON NON-REMOVABLE DISK DRIVE C: WILL BE LOST. Proceed with Format (Y/N)? Don't worry about the message as you do not have any data in the new hard disk. Choose "Y". The format will proceed and would show you a progress indicator. The time it takes to format a hard disk depends on the size and speed of the drive. This could be around 5-30 minutes. Once the format is complete you need to reset your system. You are now ready to install an operating system.

Lab # 2
Windows Seven Installation
The best way to install Windows 7 is to do a clean install. It is not difficult to perform a clean installation. If you don't have Windows 7 drivers for all your hardware, it is a good idea to download all the drivers from the hardware manufacturers website and save all the necessary drivers on a CD-R or a USB drive before you start the installation. Windows 7 DVD is bootable. In order to boot from the DVD you need to set the boot sequence. Look for the boot sequence under your BIOS setup and make sure that the first boot device is set to CD-ROM/DVD-ROM. Step 1 - Place Windows 7 DVD in your DVD-ROM drive and start your PC. Windows 7 will start to boot up and you will get the following progress bar.

Step 2 - The next screen allows you to setup your language, time and currency format, keyboard or input method. Choose your required settings and click next to continue.

Step 3 - The next screen allows you to install or repair Windows 7. Since we are doing a clean install we will click on "install now".

Step 4 - Read the license terms and tick I accept license terms. Then click next to continue.

Step 5 - You will now be presented with two options. Upgrade or Custom (Advanced). Since we are doing a clean install we will select Custom (Advanced).

Step 6 - Choose where you would like to install Windows 7. If you have one hard drive you will get a similar option to the image below. You can click next to continue. If you have more than one drive or partition then you need to select the appropriate drive and click next. If you need to format or partition a drive then click Drive options (advance) before clicking next.

Step 7 - Windows 7 starts the installation process and starts copying all the necessary files to your hard drive as shown on the image below.

Step 8 - It will go through various stages of the setup and will reboot your system few times.

Step 9 - When your PC reboots it attempts to boot from DVD as its the first boot device. Do not press any key during the boot prompt so Windows 7 will continue with the installation by booting from the hard drive.

Step 10 - After the reboot your computer will be prepared for first use.

Step 11 - At this stage you need to choose a user name and computer name. Click next to continue. The user account you create here is the Administrator account which is the main account for your Windows 7 that has all the privileges.

Step 12 - Choose your password and password hint just incase you forget your password and need to jog your memory.

Step 13 - You can now type the product key that came with Windows 7 and click next. If you do not enter the product key you can still proceed to the next stage. However Windows 7 will run in trial mode for 30 days. You must therefore activate Windows within 30 days otherwise you cannot access your computer after 30 days.

Step 14 - Help protect your computer and improve Windows automatically. Choose Use recommended settings.

Step 15 - Review your time and date settings. Select your time zone, correct the date and time and click next to continue.

Step 16 - Select your computer's current location. If you are a home user then choose Home network otherwise select the appropriate option.

Step 17 - Windows will now finalize the settings for your computer and restart.

Step 18 - After the final restart Windows 7 will start to boot up.

Step 19 - Finally you have the logon screen. Just type your password and press enter or click on the arrow to logon to Windows 7 for the first time.

Step 20 - After you have logged on to Windows 7 for the first time, you will see similar desktop to the image below. At this point you can start using your computer. However it may not be fully configured. You need to make sure that all the hardware is detected correctly and the necessary device drivers are installed. This can be done from the device manager.

Step 21 - To go to device manager click - Start Menu -> Control Panel -> System and Security -> System -> Device Manager. You will see all your hardware listed as shown on the image below. You need to check if you have any yellow exclamation marks next to the name of the devices, similar to "Multimedia Audio Controller" on the image below. This indicates that the driver has not been installed for this device. At this stage you can install the driver for this device. To do so, Right Mouse click on Multimedia Audio Controller -> Update Driver Software...

Step 22 - You can choose to "Search automatically for updated driver software" or "Browse my computer for driver software". If you have the driver CD or if the driver is on a USB drive then choose "browse my computer for driver software". Window 7 will search and install the driver from the CD or you can locate the driver manually.

Once you have removed all the yellow exclamation marks from the device manager your Windows 7 configuration would be fully complete.

Step 23 - Finally check if you have successfully activated Windows 7. Click Start Menu -> Control Panel -> System and Security -> System. You will get a window similar to the image below. Towards the bottom you will see Windows is activated followed by your product ID. This shows that your copy of Windows 7 is fully activated.

Lab # 3

Installing Fedora 10
Fedora 10, also known as Cambridge, was released on November 25th, 2008, and it brings GNOME 2.24 and KDE 4.1, faster boot experience with Plymouth, better printing, better webcam support, improved wireless network connection sharing, better software maintenance and update (powered by PackageKit and RPM 4.6), and virtualization storage. Plus, it adds a new security tool for IDS (Intrusion Detection System) called SecTool.

What do I need to get started?

You will need the Fedora 10 DVD image that corresponds to your hardware architecture (i386 or amd64), and which can be downloaded from here. When the download is over, burn the ISO image with your favourite CD/DVD burning application (Brasero on Linux or Nero, CDBurnerXP, Roxio on Windows) on a blank DVD at 4x speed. It is always recommend having an empty hard drive for a Linux installation (that means no other operating system on it, no Windows), and you must have a minimum of 10 GB free space for the Fedora installation. Great, now let's begin. Insert or leave the DVD in your CD/DVD-ROM device, and reboot the computer in order to boot from the DVD. Hit the F8 or F12 key (depending on your BIOS) to select the CD/DVD-ROM as the boot device. You'll be presented with a very nice Fedora artwork GRUB splash and some options.

At this stage, we simply suggest you press Enter, and wait for the system to load.

Select the "Skip" option when you're asked if you want to check the media before installation, and press "Enter".

Anaconda (the Fedora installer) will load and you'll see the welcome screen. Click "Next"..

Choose your language.

Choose your keyboard layout.

Type a name for the computer. It can be anything you want.

Select your location (country/city).

Enter the root (System Administrator) password. The longer, the better (WRITE IT SOMEWHERE).

Here comes the partitioning part! If you have an empty hard drive, all you have to do is click "Next," but make sure the "Remove all partitions on selected drives and create default layout" option is selected. If you don't have an empty hard drive and you still want to install

Fedora 10 on your machine, then make sure you select the "Use free space on the selected drives and create default layout" option (10 GB minimum of free space is required). Click "Next".

We also recommend selecting the "Encrypt system" option. Enter a password (the longer, the better) for the encrypted partition.

Click the "Write changes to disk" button when asked.

The hard drive will be formatted and the partitions will be created.

Now, you can select the desired packages.

Hit the "Next" button and everything will be done automatically from now on, just sit back and watch how the packages are copied to your hard drive or you can read the latest news while enjoying a cup of coffee. The installation process will take about 8-10 minutes(depending on your computer specs and the selected packages).

When the installation is over, you will get a "Congratulations, the installation is complete" screen. Click the "Reboot" button and your computer will automatically restart.

Remove the DVD from your optical drive. Your brand new Fedora 10 operating system will boot for the first time.

If you've chosen to encrypt your partition, then you'll be prompted for the passphrase.

The system will continue to boot and in a few seconds you will see the First Boot Configuration Wizard. Click "Forward" on the Welcome screen.

Click "Forward" on the License screen.

Create a regular user for the system.

Set the date and time.

Send your hardware profile to the Fedora Project (optional).

Click "Finish" and you will see the login screen. Enter the password for the regular user you've just created.

That's it! Enjoy the ultimate and breathtaking Fedora 10 Linux distribution!

Lab # 4
Process Monitor
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. Process Monitor runs on Windows XP SP2, Windows Server 2003 SP1, and Windows Vista as well as x64 versions of Windows XP, Windows Server 2003 and Windows Vista.

Using Process Monitor

Executing Process Monitor requires local Administrative group membership. When you launch Process Monitor it immediately starts monitoring three classes of operation: file system, Registry and process.

FileSystem Process Monitor displays file system activity for all Windows file systems, including local storage and remote file systems. Process Monitor automatically detects the arrival of new file system devices and monitors them. All file system paths are displayed relative to the user session in which a file system operation executes. To remove file system operations from the display de-select the file system push-button in the Process Monitor toolbar and to add back file system operations depress the button.

Registry Process Monitor logs all Registry operations and displays Registry paths using conventional abbreviations for Registry root keys (e.g. HKEY_LOCAL_MACHINE is represented as HKLM). To remove Registry operations from the display de-select the Registry push-button in the Process Monitor toolbar and to add back Registry operations depress the button. Process In its process/thread monitoring subsystem Process Monitor tracks all process and thread creation and exit operations as well as DLL and device driver load operations. To remove Process operations from the display de-select the process push-button in the Process Monitor toolbar and to add back process operations depress the button. Network Process Monitor uses Event Tracing for Windows (ETW) to trace and record TCP and UDP activity. Each network operation includes the source and destination addresses, as well as the amount of data sent or received, but does not include the actual data. To remove Network operations from the display de-select the network push-button in the Process Monitor toolbar and to add back network operations depress the button. Profiling This event class can be enabled from the Options menu. When active, Process Monitor scans all the active threads in the system and generates a profiling even for each one that records the kernel and user CPU time consumed, as well as the number of context switches executed, by the thread since its previous profiling event.

There are a number of basic options that control basic Process Monitor operation: Capture: Use the Capture Events menu item in the File menu, capture toolbar button or Ctrl+E hotkey to toggle Process Monitor's monitoring. Autoscroll: Select Autoscroll entry in the Edit menu, the autoscroll toolbar button or Ctrl+A hotkey to toggle Process Monitor's autoscroll behavior, which causes it to ensure that the most recent operation is visible in the display. Clear: To clear the display of all items choose Clear Display from the Edit menu or use the Ctrl+X hotkey.

Column Selection
We can drag columns to rearrange their order and customized the columns displayed by choosing Select Columns from the Options menu to open the column selection dialog. Columns that are available for selection include:

Application Details

Process Name The name of the process in which an event occurred. Image Path The full path of the image running in a process. Command Line The command line used to launch a process. Company Name The text of the company name version string embedded in a process image file. This text is optionally defined by the application developer. Description The text of the product description string embedded in a process image file. This text is optionally defined by the application developer. Version The product version number embedded in a process image file. This information is optionally specified by the application developer.

Event Details

Sequence Number The relative position of the operation with respect to all events included in the current filter. Event Class The class (File, Registry, Process) of the event. Operation The specific event operation (e.g. Read, RegQueryValue, etc.). Date & Time Both the date and the time of an operation. Time of Day Only the time of an operation. Path The path of the resource that an event references. Detail Additional information specific to an event. Result The status code of a completed operation. Relative Time The time of the operation relative to Process Monitor's start time or the last time that the Process Monitor display was cleared. Duration The duration of an operation that has completed.

Process Management

User Name The name of the user account in which the process that performed an operation is executing. Session ID The Windows session in which the process that executed an operation is executing. Authentication ID The logon session in which the process that executed an operation is executing. Process ID The Process ID (PID) of the process that executed an operation. Thread ID The Thread ID (TID) of the thread that executed an operation. Integrity Level The integrity level at which the process that executed an operation is running (Windows Vista only). Virtualized The virtualization status of the process that executed an operation (Windows Vista only).

Experiments
Experiment #1

Experiment #2

Lab # 5
Process Explorer
Process Explorer is an advanced process management utility that picks up where Task Manager leaves off. It will show us detailed information about a process including its icon, command-line, full image path, memory statistics, user account, security attributes, and more. When we zoom in on a particular process we can list the DLLs it has loaded or the operating system resource handles it has open. A search capability enables us to track down a process that has a resource opened, such as a file, directory or Registry key, or to view the list of processes that have a DLL loaded. The Process Explorer display consists of two sub-windows. The top always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window, which we can close, depends on the mode that Process Explorer is in: if it is in handle mode we will see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode we will see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show us which processes have particular handles opened or DLLs loaded. The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work. Process Explorer does not require administrative privileges to run and works on clients running Windows XP and higher (Including IA64) and servers running Windows Server 2003 and higher (Including IA64).

The Main Window

Views
The Process Explorer window shows by default two panes: the upper pane is always a process list and the bottom either shows the list of DLLs loaded into the process selected in the upper pane, or the list of operating system resource handles (files, Registry keys, synchronization objects) the process has open; the view mode determines which information is shown in the bottom pane. To switch the view, use the View|Lower Pane View menu item, the corresponding toolbar button (which toggles), or the Ctrl+D (DLL view) and Ctrl-H (handle view) accelerator keys. If we are only interested in seeing the processes running on our system we can hide the lower pane by selecting View|Hide Lower Pane, the corresponding toolbar button, the Ctrl+L accelerator, or by dragging the pane divider to the bottom of the Process Explorer window. We can bring back the lower pane by selecting View|Show Lower Pane, typing Ctrl+L or selecting the toolbar button again.

Mini Graphs Process Explorer includes a toolbar and mini graphs for CPU, memory, and if on Windows 2000 or higher, I/O history, at the top of the main window. They can be resized with respect to one another or dragged such that each is on a separate row. The mini-graphs show history of system activity and hovering the mouse over a point on a graph displays in a tooltip the associated time and the process information for point in time. Refresh Rate and Difference Highlighting Configure the rate at which Process Explorer refreshes its window by using the View|Update Speed menu item. we can refresh the view manually at any time with View|Refresh, the refresh toolbar button, or by pressing F5. Some checks, such as whether a process is part of a Job object or uses the .NET runtime, only occur during process startup. Press F5 to have Process Explorer recheck the status of all processes. Process Explorer uses difference highlighting to help us, see what items change between refreshes. Items, including processes, DLLs, and handles, that exit or are closed show in red and new items show in green. If the refresh rate is not paused the highlighting remains in effect for the interval specified by the Options|Difference Highlight Duration dialog, which has a default value of 1 second. If we pause the display the difference highlighting is in effect only until the next time we manually refresh. Opacity We can make the Process Explorer window partially transparent so that windows beneath it show through on systems that support it by making a selection under the View|Opacity menu item. Saving When we choose File|Save Process Explorer saves the contents of the Process and lower pane, if it is showing, as a tab-delimited text file.

Shutting Down or Logging Off Use the File|Shutdown menu items to shutdown, reboot, lock or logoff the system. When available, the menu also offers options for hibernating and suspending the system. Run Use this option to run other applications from Process Explorer using the standard Windows Run dialog. Runas This variant on the Run command allows us to enter alternate credentials for the launching application. Process Explorer leverages the same Windows functionality as the Runas Windows command to provide this support. The Runas menu item is not present on Windows 9x. Run as Limited User This variant on the Run command runs the application we specify in the same account as that of Process Explorer, but without administrative privileges or membership in the local administrators group. This option restricts the exposure of our system from applications, such as Internet Explorer, that might be compromised through access of untrusted data.

System Information
On Windows NT and higher the System Information entry in the View menu and typing Ctrl+I opens a dialog box that shows global system performance metrics like those shown in Task Manager. The information includes the amount of committed and available virtual and physical memory as well as paged and nonpaged kernel buffer usage.

Graphs show the CPU usage history of the system as well as the committed virtual memory usage, and on Windows 2000 or higher systems an I/O graph shows I/O throughput history. Red in the CPU usage graph indicates CPU usage in kernel-mode whereas green is the sum of kernel-mode and user-mode execution. When committed virtual memory, which Task Manager labels in its graphs on Windows 2000 and higher as "PF Usage" and on NT 4 as "Mem Usage", reaches the system Commit Limit, applications and the system become unstable. The Commit Limit is the sum of most of physical memory and the sizes of any paging files. In the I/O graph the blue line indicates total I/O traffic, which is the sum of all process I/O reads and writes, between refreshes and the pink line shows write traffic. When we move the mouse over the CPU graph a popup displays either on the far left or right of the graph that shows the CPU usage and name of the process that had the largest contribution to CPU usage at the corresponding point in time, as well as the time of the point. Similarly, time stamp information for a point is shown in the Commit graph. Finally, on the I/O graph the tooltip shows the process performing the most I/O at the time of the point, including the amount of data it read and wrote. The popups update as data moves under the mouse, but we can freeze a popup by left clicking and the move the mouse to unfreeze the popup. On systems with multiple CPUs the System Information dialog includes a Show one graph per CPU checkbox. Checking it switches the display into a per-processor view. Hyperthreaded (SMT) processors sharing the same core and NUMA processors sharing the same node are grouped together and the mouse tooltip shown when hovering over a graph displays the processor and core or node numbers. Note that the mouse tooltips for a processor graph show the name of the process that consumed the most CPU on the entire system at the associated time, not the process that consumed the most CPU on the particular CPU.

Columns and Column Sets

Column Selection The information Process Explorer displays in its main window is fully configurable. You can reorder columns by dragging them to their new position. To select which columns of data you want visible in each of the views and the status bar, choose View|Select Columns or rightclick on a column header and use Select Columns from the resulting context menu. A column selection editor opens that let's you pick the columns you want to enable for the Process, DLL, handle panes, and status bar. Column Sets You can save a column configuration and its associated sort settings by choosing View|Save Column Set. Process Explorer will prompt you to name the column set. You can load a saved column set by selecting it in the View|Load Column Set menu or by entering its associated accelerator keys. To reorder or rename existing column sets go to View|Organize Column Sets to open the column set organizer.

Experiments
Experiment # 1

Experiment # 2

Lab # 6
Handle
Handle is targeted at searching for open file references, so if you do not specify any command-line parameters it will list the values of all the handles in the system that refer to open files and the names of the files. It also takes several parameters that modify this behaviour. usage: handle [[-a] [-u] | [-c <handle> [-l] [-y]] | [-s]] [-p <processname>|<pid>> [name] -a Dump information about all types of handles, not just those that refer to files. Other types include ports, Registry keys, synchronization primitives, threads, and processes. -c Closes the specified handle (interpreted as a hexadecimal number). You must specify the process by its PID. WARNING: Closing handles can cause application or system instability. -l Dump the sizes of pagefile-backed sections. -y Don't prompt for close handle confirmation. -s Print count of each type of handle open. -u Show the owning user name when searching for handles. -p Instead of examining all the handles in the system, this parameter narrows Handle's scan to those processes that begin with the name process. Thus: handle -p exp would dump the open files for all processes that start with "exp", which would include Explorer. name This parameter is present so that you can direct Handle to search for references to an object with a particular name. For example, if you wanted to know which process (if any) has "c:\windows\system32" open you could type: handle windows\system The name match is case-insensitive and the fragment specified can be anywhere in the paths you are interested in.

Handle Output
When not in search mode (enabled by specifying a name fragment as a parameter), Handle divides its output into sections for each process it is printing handle information for. Dashed lines are used as a separator, immediately below which you will see the process name and its process id (PID). Beneath the process name are listed handle values (in hexadecimal), the type of object the handle is associated with, and the name of the object if it has one. When in search mode, Handle prints the process names and id's are listed on the left side and the names of the objects that had a match are on the right.

Lab # 7
Scheduling Simulator Installation on Windows 95/98/Me/NT/2000 Systems Purpose
This document provides instructions for the installation of the Scheduling Simulator on Microsoft Windows operating systems. This procedure should be the same or similar on Windows 95, 98, Me, NT, and 2000 systems. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001). The Scheduling Simulator was written by Alex Reeder ([email protected]). This installation guide only provides information about installing the software and testing the configuration for Windows operating systems.

Requirements
The following software components are required to install and use the Scheduling Simulator.

Microsoft Windows 95, 98, Me, NT, or 2000 Java Development Kit (JDK) 1.0 or greater Text program editor (e.g., notepad)

Pre-Installation
Before installation, you should verify:

that you have a working java runtime environment, that you have a working java development environment, and that the working directory is in the classpath for the runtime environment.

If you're using a standard command-line java compiler, the following instructions will help determine if your environment is configured correctly. 1. Verify that you have java installed and configured in your environment.
2. C:\WINDOWS> java -version

You should see a message like this with possibly a different version number.
java version "1.1.8"

If you get a message like:

Bad command or file name

Then java may not be installed on your system, or may not be configured for your use.

If you think that Java may already be installed on your system but may not be in your "path", you can find it by choosing Start -> Find -> Files or Folders and enter "java.exe" in the "Named:" field and click the Find Now button. If found, make note of the directory folder in which it resides (e.g., "C:\jdk1.1.8\bin"). While you're at it, also search for javac.exe to see if the Java compiler is installed and whether it's in the same directory as the java.exe file. If Java isn't available on your system, you should check with your instructor or system administrator. If you administer your own system, then you should be able to find a copy of Java for your operating system. If you find that java is installed but not configured for your use, then perhaps you need to add it to your path. Consult your instructor or system administrator if you need help adding this to your path. 3. Verify that the java compiler is installed and configured in your environment.
4. C:\WINDOWS> javac

If you're using a standard java command-line compiler, you should see a message similar to this.
use: javac [-g][-O][-debug][-depend][-nowarn][-verbose][-classpath path][-nowrite][-deprecation][-d dir][-J] file.java...

If you get a message like:

Bad command or file name

then the java compiler may not be installed on your system, or may not be configured for your use. Consult your instructor or system administrator. 5. Verify that that the current directory is in your classpath.
6. C:\WINDOWS> echo "%CLASSPATH%"

You should see a list of directories separated by semi-colons (";") or possibly just "". If you don't see the directory "." (a single period, which stands for the current directory), then you should add it to the classpath.
C:\WINDOWS> set CLASSPATH=.;%CLASSPATH%

If you have a working java runtime environment, a working java compiler, and the current directory is in your path, then you're ready to proceed with the installation.

Installation
Installation of the software can be accomplished with these simple steps:

1. Create a directory folder in which you wish to install the simulator (e.g., "C:\\sched"). You can do this using the Windows explorer, or from the MS-DOS prompt. To create the directory from the MS-DOS prompt:
2. 3. 4. 5. 6. 7. C:\WINDOWS> cd \ C:\> mkdir C:\> cd C:\> mkdir sched C:\> cd sched C:\\sched>

8. Download the self-extracting ZIP archive (sched.exe) into the directory folder. 9. Double-click on the file you downloaded (sched.exe), or invoke it using Start -> Run..., or invoke it from an MS-DOS command prompt:
10. C:\\sched> sched.exe

Files
The directory should now contain the following files: Files Description sched.exe Self-extracting ZIP archive which contains all the other files. Common.java Java source files (*.java) Process.java Results.java Scheduling.java SchedulingAlgorithm.java sProcess.java Common.class Compiled Java class files (*.class) Process.class Results.class Scheduling.class SchedulingAlgorithm.class sProcess.class scheduling.conf install_unix.html install_windows.html user_guide.html COPYING.TXT

Sample configuration file Documentation

Gnu General Public License: Terms and Conditions for Copying, Distribution, and Modification

Compilation
The distribution includes compiled class files as well as the source java files. You should not need to recompile unless you decide to change the code. If you wish to compile the code, the following commands should work if you're using a Java compiler that accepts the normal "javac" command line.
C:\\sched> javac -nowarn *.java

The -nowarn flag suppresses warning messages, of which there may be several. For backward compatibility we use only those features of Java which have been present from the beginning, some of which are deprecated and are usually reported by the compiler with warning messages.

Test
To test the program, enter the following commands.
C:\\sched> java Scheduling scheduling.conf

The program will simply run the simulation based on the information provided in scheduling.conf and write its output to the Summary-Results and Summary-Processes files. You should see the following output.
Working... Completed.

The simulation configuration information is read from a file called "scheduling.conf". The "scheduling.conf" file looks something like this:
// # of Process numprocess 3 // mean deivation meandev 1100 // standard deviation standdev 510 // process # I/O blocking process 100 process 500 process 30 // duration of the simulation in milliseconds runtime 5000

If things are working correctly, the "Summary-Results" file should look something like this:
Scheduling Type: Batch (Nonpreemptive) Scheduling Name: First-Come First-Served Simulation Run Time: 2750 Mean: 1100 Standard Deviation: 510 Process # CPU Time IO Blocking CPU Completed CPU Blocked 0 1372 (ms) 100 (ms) 1372 (ms) 13 times 1 689 (ms) 500 (ms) 689 (ms) 1 times 2 689 (ms) 30 (ms) 689 (ms) 22 times

and the "Summary-Processes" file should look something like this:

Process: 0 registered... (1372 100 0 0)

Process: 0 I/O blocked... (1372 100 100 100) Process: 1 registered... (689 500 0 0) Process: 1 I/O blocked... (689 500 500 500) Process: 0 registered... (1372 100 100 100) Process: 0 I/O blocked... (1372 100 200 200) Process: 1 registered... (689 500 500 500) Process: 1 completed... (689 500 689 689) Process: 0 registered... (1372 100 200 200) Process: 0 I/O blocked... (1372 100 300 300) Process: 2 registered... (689 30 0 0) Process: 2 I/O blocked... (689 30 30 30) Process: 0 registered... (1372 100 300 300) Process: 0 I/O blocked... (1372 100 400 400) Process: 2 registered... (689 30 30 30) Process: 2 I/O blocked... (689 30 60 60) Process: 0 registered... (1372 100 400 400) Process: 0 I/O blocked... (1372 100 500 500) Process: 2 registered... (689 30 60 60) Process: 2 I/O blocked... (689 30 90 90) Process: 0 registered... (1372 100 500 500) Process: 0 I/O blocked... (1372 100 600 600) Process: 2 registered... (689 30 90 90) Process: 2 I/O blocked... (689 30 120 120) Process: 0 registered... (1372 100 600 600) Process: 0 I/O blocked... (1372 100 700 700) Process: 2 registered... (689 30 120 120) Process: 2 I/O blocked... (689 30 150 150) Process: 0 registered... (1372 100 700 700) Process: 0 I/O blocked... (1372 100 800 800) Process: 2 registered... (689 30 150 150) Process: 2 I/O blocked... (689 30 180 180) Process: 0 registered... (1372 100 800 800) Process: 0 I/O blocked... (1372 100 900 900) Process: 2 registered... (689 30 180 180) Process: 2 I/O blocked... (689 30 210 210) Process: 0 registered... (1372 100 900 900) Process: 0 I/O blocked... (1372 100 1000 1000) Process: 2 registered... (689 30 210 210) Process: 2 I/O blocked... (689 30 240 240) Process: 0 registered... (1372 100 1000 1000) Process: 0 I/O blocked... (1372 100 1100 1100) Process: 2 registered... (689 30 240 240) Process: 2 I/O blocked... (689 30 270 270) Process: 0 registered... (1372 100 1100 1100) Process: 0 I/O blocked... (1372 100 1200 1200) Process: 2 registered... (689 30 270 270) Process: 2 I/O blocked... (689 30 300 300) Process: 0 registered... (1372 100 1200 1200) Process: 0 I/O blocked... (1372 100 1300 1300) Process: 2 registered... (689 30 300 300) Process: 2 I/O blocked... (689 30 330 330) Process: 0 registered... (1372 100 1300 1300) Process: 0 completed... (1372 100 1372 1372) Process: 2 registered... (689 30 330 330) Process: 2 I/O blocked... (689 30 360 360) Process: 2 registered... (689 30 360 360) Process: 2 I/O blocked... (689 30 390 390) Process: 2 registered... (689 30 390 390) Process: 2 I/O blocked... (689 30 420 420) Process: 2 registered... (689 30 420 420)

Process: 2 I/O blocked... (689 30 450 450) Process: 2 registered... (689 30 450 450) Process: 2 I/O blocked... (689 30 480 480) Process: 2 registered... (689 30 480 480) Process: 2 I/O blocked... (689 30 510 510) Process: 2 registered... (689 30 510 510) Process: 2 I/O blocked... (689 30 540 540) Process: 2 registered... (689 30 540 540) Process: 2 I/O blocked... (689 30 570 570) Process: 2 registered... (689 30 570 570) Process: 2 I/O blocked... (689 30 600 600) Process: 2 registered... (689 30 600 600) Process: 2 I/O blocked... (689 30 630 630) Process: 2 registered... (689 30 630 630) Process: 2 I/O blocked... (689 30 660 660) Process: 2 registered... (689 30 660 660) Process: 2 completed... (689 30 689 689)

Scheduling Simulator Purpose

This document is a user guide for the Scheduling Simulator. It explains how to use the simulator and describes the various input and output files used by the simulator. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001). The Scheduling Simulator was written by Alex Reeder ([email protected]).

Introduction
The scheduling simulator illustrates the behaviour of scheduling algorithms against a simulated mix of process loads. The user can specify the number of processes, the mean and standard deviation for compute time and I/O blocking time for each process, and the duration of the simulation. At the end of the simulation a statistical summary is presented. Students may also be asked to write their own scheduling algorithms to be used with process loads defined by the instructor.

Running the Simulator

The program reads a configuration file (scheduling.conf) and writes two output files (Summary-Results and Summary-Processes). To run the program, enter the following command line.
$ java Scheduling scheduling.conf

The program will display "Working..." while the simulation is working, and "Completed." when the simulation is complete.
Working... Completed.

The simulator reads parameters from the configuration file ("scheduling.conf"). It creates a specified number of processes, each of which blocks for input or output after a number of milliseconds that can be specified for each process. Each process is allowed to run for a randomly generated amount of time, with the amount of time constrained by a specified average (mean) in milliseconds, and standard deviations from that average. The simulation may also be bounded in the total length of its run. After reading the configuration file, the scheduling algorithm then "runs" the processes, causing each to block for input or output after the specified interval until all processes have completed their randomly generated amount of runtime, or until the maximum amount of runtime for the simulation is exceeded. As the simulation proceeds, a log file ("Summary-Processes") is generated which shows the activity of the scheduling algorithm as it considers each process in the process queue. After the simulation halts, a summary report ("Summary-Results") is generated which shows statistics for each process and for the simulation as a whole.

The Configuration File

The configuration file (scheduling.conf) is used to specify various parameters for the simulation, including:

the number of processes, the mean runtime for a process, the standard deviation in runtime for a process, for each process, how long the process runs before it blocks for input or output, and how long the simulation should run.

Configuration File Options

There are a number of options which can be specified in the configuration file. These are summarized in the table below.

Keyword Values Description

numprocess n meandev

The number of processes to create for the simulation. The average length of time in milliseconds that a process should execute before terminating. The number of standard deviations from the average length of time a process should execute before terminating. The amount of time in milliseconds that the process should execute before blocking for input or output. There should be a separate process directive for each process specified by the numprocess directive.

n n n

standdev

process

runtime

The maximum amount of time the simulation should run in milliseconds.

Sample Configuration File

The "scheduling.conf" configuration file looks like this:

// # of Process numprocess 3 // mean deivation meandev 1100 // standard deviation standdev 510 // process # I/O blocking process 100 process 500 process 30 // duration of the simulation in milliseconds runtime 5000

The Summary-Results File

The Summary-Results file contains a summary report describing the simulation and includes one line of summary information for each process. The fields and columns in the report are described in the following table.
Field Scheduling Type: Scheduling Name: Simulation Run Time: Mean: Standard Deviation: Process # Description The type of the scheduling algorithm used. The value displayed is "hard coded" in the SchedulingAlgorithm.java file. The name of the scheduling algorithm used. The value displayed is "hard coded" in the SchedulingAlgorithm.java file. The number of milliseconds that the simulation ran. This may be less than or equal to the total amount of time specified by the "runtime" configuration parameter. The average amount of runtime for the processes as specified by the "meandev" configuration parameter. The standard deviation from the average amount of runtime for the processes as specified by the "standdev" configuration parameter. The process number assigned to the process by the simulator. The process number is between 0 and n-1, where n is the number specified by the "numprocess" configuration parameter. The randomly generated total runtime for the process in milliseconds. This is determined by the "meandev" and "standdev" parameters in the configuration file. The amount of time the process runs before it blocks for input or output. This is

CPU Time IO Blocking

specified for each process by a "process" directive in the configuration file. CPU Completed The amount of runtime in milliseconds completed for the process. Note that this may be less than the CPU Time for the process if the simulator runs out of time as specified by the "runtime" configuration parameter.

CPU Blocked The number of times the process blocked for input or output during the simulation. Sample Summary-Results File

The output "Summary-Results" file looks something like this:

Scheduling Type: Batch (Nonpreemptive) Scheduling Name: First-Come First-Served Simulation Run Time: 2750 Mean: 1100 Standard Deviation: 510 Process # CPU Time IO Blocking 0 1372 (ms) 100 (ms) 1 689 (ms) 500 (ms) 2 689 (ms) 30 (ms)

CPU Completed 1372 (ms) 689 (ms) 689 (ms)

CPU Blocked 13 times 1 times 22 times

The Summary-Processes File

The Summary-Processes file contains a log of the actions taken by the scheduling algorithm as it considers each process in the scheduling queue. Each line in the log file is of the following form:
Process: process-number process-status... (cpu-time block-time accumulated-time accumulated-time)

The fields in the line are described in the table below.

Field processnumber Description The process number assigned to the process by the simulator. This is a number between 0 and n-1, where n is the value specified for the "numprocess" configuration parameter.

process-status The status of the process at this point in time. If "registered" then the process is under consideration by the scheduling algorithm. If "I/O blocked", then the scheduling algorithm has noticed that the process is blocked for input or output. If "completed", then the scheduling algorithm has noticed that the process has met or exceeded its allocated execution time. cpu-time The total amount of run time allowed for this process. This number is randomly generated for the process based on the "meandev" and "standdev" values specified in the configuration file. The amount of time in milliseconds to execute before blocking process. This number is specified for the process by the "process" directive in the configuration file.

block-time

accumulated- The total amount of time process has executed in milliseconds. (This number appears time twice in the log file; one should be removed). Sample Summary-Processes File

The output "Summary-Processes" file looks something like this:

Process: 0 registered... (1372 100 0 0) Process: 0 I/O blocked... (1372 100 100 100) Process: 1 registered... (689 500 0 0) Process: 1 I/O blocked... (689 500 500 500) Process: 0 registered... (1372 100 100 100) Process: 0 I/O blocked... (1372 100 200 200) Process: 1 registered... (689 500 500 500) Process: 1 completed... (689 500 689 689) Process: 0 registered... (1372 100 200 200) Process: 0 I/O blocked... (1372 100 300 300) Process: 2 registered... (689 30 0 0) Process: 2 I/O blocked... (689 30 30 30) Process: 0 registered... (1372 100 300 300) Process: 0 I/O blocked... (1372 100 400 400) Process: 2 registered... (689 30 30 30) Process: 2 I/O blocked... (689 30 60 60) Process: 0 registered... (1372 100 400 400) Process: 0 I/O blocked... (1372 100 500 500) Process: 2 registered... (689 30 60 60) Process: 2 I/O blocked... (689 30 90 90) Process: 0 registered... (1372 100 500 500) Process: 0 I/O blocked... (1372 100 600 600) Process: 2 registered... (689 30 90 90) Process: 2 I/O blocked... (689 30 120 120) Process: 0 registered... (1372 100 600 600) Process: 0 I/O blocked... (1372 100 700 700) Process: 2 registered... (689 30 120 120) Process: 2 I/O blocked... (689 30 150 150) Process: 0 registered... (1372 100 700 700) Process: 0 I/O blocked... (1372 100 800 800) Process: 2 registered... (689 30 150 150) Process: 2 I/O blocked... (689 30 180 180) Process: 0 registered... (1372 100 800 800) Process: 0 I/O blocked... (1372 100 900 900) Process: 2 registered... (689 30 180 180) Process: 2 I/O blocked... (689 30 210 210) Process: 0 registered... (1372 100 900 900) Process: 0 I/O blocked... (1372 100 1000 1000) Process: 2 registered... (689 30 210 210) Process: 2 I/O blocked... (689 30 240 240) Process: 0 registered... (1372 100 1000 1000) Process: 0 I/O blocked... (1372 100 1100 1100) Process: 2 registered... (689 30 240 240) Process: 2 I/O blocked... (689 30 270 270) Process: 0 registered... (1372 100 1100 1100) Process: 0 I/O blocked... (1372 100 1200 1200) Process: 2 registered... (689 30 270 270) Process: 2 I/O blocked... (689 30 300 300) Process: 0 registered... (1372 100 1200 1200) Process: 0 I/O blocked... (1372 100 1300 1300) Process: 2 registered... (689 30 300 300)

Process: 2 I/O blocked... (689 30 330 330) Process: 0 registered... (1372 100 1300 1300) Process: 0 completed... (1372 100 1372 1372) Process: 2 registered... (689 30 330 330) Process: 2 I/O blocked... (689 30 360 360) Process: 2 registered... (689 30 360 360) Process: 2 I/O blocked... (689 30 390 390) Process: 2 registered... (689 30 390 390) Process: 2 I/O blocked... (689 30 420 420) Process: 2 registered... (689 30 420 420) Process: 2 I/O blocked... (689 30 450 450) Process: 2 registered... (689 30 450 450) Process: 2 I/O blocked... (689 30 480 480) Process: 2 registered... (689 30 480 480) Process: 2 I/O blocked... (689 30 510 510) Process: 2 registered... (689 30 510 510) Process: 2 I/O blocked... (689 30 540 540) Process: 2 registered... (689 30 540 540) Process: 2 I/O blocked... (689 30 570 570) Process: 2 registered... (689 30 570 570) Process: 2 I/O blocked... (689 30 600 600) Process: 2 registered... (689 30 600 600) Process: 2 I/O blocked... (689 30 630 630) Process: 2 registered... (689 30 630 630) Process: 2 I/O blocked... (689 30 660 660) Process: 2 registered... (689 30 660 660) Process: 2 completed... (689 30 689 689)

Lab # 8
Deadlock Simulator Installation on Windows 95/98/Me/NT/2000 Systems Purpose
This document provides instructions for the installation of the Deadlock Simulator on Microsoft Windows operating systems. This procedure should be the same or similar on Windows 95, 98, Me, NT, and 2000 systems. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001). This installation guide only provides information about installing the software and testing the configuration for Windows operating systems.

Requirements
The following software components are required to install and use the Deadlock Simulator.

Microsoft Windows 95, 98, Me, NT, or 2000 Java Development Kit (JDK) 1.0 or greater Text program editor (e.g., notepad)

Pre-Installation
Before installation, you should verify:

that you have a working java runtime environment, that you have a working java development environment, and that the working directory is in the classpath for the runtime environment.

If you're using a standard command-line java compiler, the following instructions will help determine if your environment is configured correctly. 1. Verify that you have java installed and configured in your environment.
2. C:\WINDOWS> java -version

You should see a message like this with possibly a different version number.
java version "1.1.8"

If you get a message like:

Bad command or file name

Then java may not be installed on your system, or may not be configured for your use. If you think that Java may already be installed on your system but may not be in your "path", you can find it by choosing Start -> Find -> Files or Folders and enter

"java.exe" in the "Named:" field and click the Find Now button. If found, make note of the directory folder in which it resides (e.g., "C:\jdk1.1.8\bin"). While you're at it, also search for javac.exe to see if the Java compiler is installed and whether it's in the same directory as the java.exe file. If Java isn't available on your system, you should check with your instructor or system administrator. If you administer your own system, then you should be able to find a copy of Java for your operating system. If you find that java is installed but not configured for your use, then perhaps you need to add it to your path. Consult your instructor or system administrator if you need help adding this to your path. 3. Verify that the java compiler is installed and configured in your environment.
4. C:\WINDOWS> javac

If you're using a standard java command-line compiler, you should see a message similar to this.
use: javac [-g][-O][-debug][-depend][-nowarn][-verbose][-classpath path][-nowrite][-deprecation][-d dir][-J] file.java...

If you get a message like:

Bad command or file name

then the java compiler may not be installed on your system, or may not be configured for your use. Consult your instructor or system administrator. 5. Verify that that the current directory is in your classpath.
6. C:\WINDOWS> echo "%CLASSPATH%"

You should see a list of directories separated by semi-colons (";") or possibly just "". If you don't see the directory "." (a single period, which stands for the current directory), then you should add it to the classpath.
C:\WINDOWS> set CLASSPATH=.;%CLASSPATH%

If you have a working java runtime environment, a working java compiler, and the current directory is in your path, then you're ready to proceed with the installation.

Installation
Installation of the software can be accomplished with these simple steps: 1. Create a directory folder in which you wish to install the simulator (e.g., "C:\\deadlock"). You can do this using the Windows explorer, or from the MS-DOS prompt. To create the directory from the MS-DOS prompt:
2. 3. C:\WINDOWS> cd \ C:\> mkdir

4. 5. 6. 7.

C:\> cd C:\> mkdir deadlock C:\> cd deadlock C:\\deadlock>

8. Download the self-extracting ZIP archive (deadlock.exe) into the directory folder. 9. Double-click on the file you downloaded (deadlock.exe), or invoke it using Start -> Run..., or invoke it from an MS-DOS command prompt:
10. C:\\deadlock> deadlock.exe

Files
The directory should now contain the following files: Files deadlock.exe Command.java CommandParser.java ControlPanel.java DatFilenameFilter.java DeadlockManager.java Kernel.java OptionsDialog.java Process.java ProcessesDialog.java ProcessesPanel.java Resource.java ResourcesDialog.java ResourcesPanel.java deadlock.java Command.class CommandParser.class ControlPanel.class DatFilenameFilter.class DeadlockManager.class Kernel.class OptionsDialog.class Process.class ProcessesDialog.class ProcessesPanel.class Resource.class ResourcesDialog.class ResourcesPanel.class deadlock.class a0.dat a1.dat Sample input files b0.dat b1.dat Description Self-extracting ZIP archive which contains all the other files. Java source files (*.java)

Compiled Java class files (*.class)

install_unix.html install_windows.html user_guide.html user_guide_1.gif copying.txt

Documentation and associated images

Gnu General Public License: Terms and Conditions for Copying, Distribution, and Modification

Compilation
The distribution includes compiled class files as well as the source java files. You should not need to recompile unless you decide to change the code. If you wish to compile the code, the following commands should work if you're using a Java compiler that accepts the normal "javac" command line.
C:\\deadlock> javac -nowarn *.java

The -nowarn flag suppresses warning messages, of which there may be several. For backward compatibility we use only those features of Java which have been present from the beginning, some of which are deprecated and are usually reported by the compiler with warning messages.

Test
To test the installed program, enter the following command line.
C:\\deadlock> java deadlock a 2 1 >a.log

The program will display a window allowing you to run the simulator. When the window presents itself, click on the "run" button. You should see the program "execute" cycles, about one per second. When the simulation completes, click the "exit" button. The program simulated the creation of two processes and read commands for each process from the files "a0.dat" and "a1.dat". It also simulated creation of a resource with an available quantity of 1. During the execution of the simulator, a process executes, or requests or frees a resource. If there are no available instances of the resource, the process blocks. The simulation runs until all processes halt. The input file "a0.dat" looks like this:
/* a0.dat The "a" collection of process data files is meant to simulate two processes competing for a single resource. If you run the simulator with one resource available, one of the processes will block until the other is done using the resource. */ C 10 // compute for 10 milliseconds R 0 // request resource 0

C 10 // compute for 10 milliseconds F 0 // free resource 0 H // halt process

The input file "a1.dat" looks like this:

/* a1.dat The "a" collection of process data files is meant to simulate two processes competing for a single resource. If you run the simulator with one resource available, one of the processes will block until the other is done using the resource. */ C 10 // compute for 10 milliseconds R 0 // request resource 0 C 10 // compute for 10 milliseconds F 0 // free resource 0 H // halt process

If things are working correctly, the "a.log" output file should look something like this:
time = 0 available = 1 blocked = 0 time = 1 available = 1 blocked = 0 time = 2 available = 1 blocked = 0 time = 3 available = 1 blocked = 0 time = 4 available = 1 blocked = 0 time = 5 available = 1 blocked = 0 time = 6 available = 1 blocked = 0 time = 7 available = 1 blocked = 0 time = 8 available = 1 blocked = 0 time = 9 available = 1 blocked = 0 time = 10 available = 0 blocked = 1 time = 11 available = 0 blocked = 1 time = 12 available = 0 blocked = 1 time = 13 available = 0 blocked = 1 time = 14 available = 0 blocked = 1 time = 15 available = 0 blocked = 1 time = 16 available = 0 blocked = 1 time = 17 available = 0 blocked = 1 time = 18 available = 0 blocked = 1 time = 19 available = 0 blocked = 1 time = 20 available = 0 blocked = 0 time = 21 available = 0 blocked = 0 time = 22 available = 0 blocked = 0 time = 23 available = 0 blocked = 0 time = 24 available = 0 blocked = 0 time = 25 available = 0 blocked = 0 time = 26 available = 0 blocked = 0 time = 27 available = 0 blocked = 0 time = 28 available = 0 blocked = 0 time = 29 available = 0 blocked = 0 time = 30 available = 1 blocked = 0

Note that both processes computed for 10 milliseconds, then one process was blocked while the other utilized the scarce resource for 10 milliseconds, then the block process was able to use the resource, then the simulation completed.

Deadlock Simulator User Guide Purpose

This document is a user guide for the Deadlock Simulator. It explains how to use the simulator and describes the display and the various input files used by and output files produced by the simulator. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001).

Introduction
The deadlock simulator illustrates multiple processes competing for one or more resources to investigate the nature and causes of deadlock conditions and how they can be avoided, detected, and resolved. The simulator includes a graphical user interface that allows the student to step through the "programs" being concurrently "executed" by each of the processes and see which processes are blocked by which resources. A typical student lab exercise might require students to write simple "programs" for the simulator to investigate different kinds of resource contention conditions. More advanced students might write a deadlock manager (in Java) based on the template provided, and test it using "programs" of their own design.

Overview
The deadlock simulator performs the following steps as part of the simulation:

It creates a specified number of simulated processes. For each process, it reads a command file of actions to be performed by that process. Each action is one of the following: o compute for a specified length of time o request an instance of a specified resource o free an instance of a specified resource o end or halt the process It creates a specified number of instances for each of several resources. It "executes" the simulation by considering the commands for each process, one at a time, and either allowing the process to execute, granting it an instance of a requested resource, blocking the process until a requested is available, or ending a process. As the execution proceeds, the display is updated to reflect the status of each process, and the number of available instances of each resource. At the end of each cycle of execution, the simulator writes a "log" message indicating the time since the beginning of the simulation, the number of available instances of each resource, the number of blocked processes, etc. The user may "step" through the simulation to view the action at each cycle, or may "run" the simulation to completion.

When all processes are halted, the simulation stops.

Running the Simulator

To run the program, enter the following command line.
$ java deadlock a 2 1 >a.log

In this example, a is the prefix for the names of the files containing the commands, (the actual names of the files are "a0.dat", and "a1.dat"), 2 is the number of processes to be created, 1 is the number of instances to create for the first resource, and a.log is the name of the output file.

The program will display a window allowing you to run the simulator. You will notice a row of command buttons across the top, and an informational display below. The left side of the information display lists the resources and the number of available instances for each, and the right side lists the processes and the current status for each.

Typically you will use the step button to execute a cycle of the simulation and observe the effect on the resources and processes. When you're done, quit the simulation using the exit button.
The Command Line

The general form of the command line is

$ java deadlock file-name-prefix initial-number-of-processes initial-available-for-resource ...

where

Parameter file-nameprefix

Description Specifies the name prefix for the process command files. The default command file names are generated from this prefix, followed by the number of the process, followed by ".dat" (e.g, "a0.dat", "a1.dat" if "a" is the prefix). The actual names of the files may be entered or modified in the Processes Dialog (see below).

initial-number- Specifies the number of processes to create for the simulation. This should be a nonof-processes negative number, usually greater than one. This number may also be entered or modified using the Options Dialog (see below). initialSpecifies the initial number of instances available for each resource. This should be a available-for- sequence of non-negative numbers. For example, "2 1 2 0" indicates that there are four resource... resources, and there are initially two instances of resource 0, one instance of resource 1, two instances of resource 2, and zero instances of resource 3. The number of resources may also be entered or modified using the Options Dialog (see below). The initial number of instances available for each resource may be entered or modified using the Resources Dialog (see below). The Control Panel

The main control panel for the simulator includes a row of command buttons, and an informational display.

The buttons:
Button Description
run

runs the simulation to completion. Note that the simulation pauses and updates the screen between each step. stops the simulation if it is running. This button is only active if the run button has been pressed. runs a single setup of the simulation and updates the display. initializes the simulator and starts from the initial values for each process and resource. allows you to change various options for the simulator, including the number of resources and

stop

step reset options

the number of processes.

resources allows you to change the configuration for each resource, including the initial and current

number of instances available for each resource.

processes allows you to change the configuration for each process, including current state and the name

of the command file for that process.

exit

exits the simulation.

The informational display:

Field
Time:

Description number of "milliseconds" since the start of the simulation. zero.

Resource Id: A number which identifies the particular resource. Resources are numbered starting with

Resource Available:

The number of instances available for the particular resource. This is a non-negative number. zero.

Process Id: A number which identifies the particular process. Processes are numbered starting with

Process State:

The current state of the process. This may be U (unknown), C (computable), W (waiting), or H (halted). At the beginning of the simulation, all processes have U status. While a process is computable, it has a C status. If it requests a resource which is unavailable, it enters W status until the resource becomes available. When a process has completed all the commands in its command file or performs a halt command, it enters H status. The resource for which this process is waiting, if any. This field only has a value if the process is in W status.

Process Resource:

The Options Dialog Box

The Options Dialog Box allows you to set general options for the simulator.

The options:
Field Description

Number Processes:

of The number of processes to use in the simulation. This should be a non-negative

number, usually at least two. Although the program does not enforce a limit, you may not be able to view more than about 10 processes on the informational display on your display screen. The initial value for this option is obtained from the second parameter on the command line, or zero, if not specified. Keep in mind that each process should have a process command file. To set properties for individual processes, use the Processes Dialog (see below).

Number of The number of resources available in the simulation. This should be a non-negative Resources: number, usually at least one. Although the program does not enforce a limit, you may

not be able to view more than about 10 resources on the informational display on your display screen. The initial value for this option is obtained from the number of initial instances for each resource specified on the command line (see above), or zero, if none are specified. This number should be one more than the largest resource number mentioned in any of the process command files for the simulation. To set properties for individual resources, use the Resources Dialog (see below).
Milliseconds per step:

The number of real-time milliseconds to pause between each cycle of the simulator in "run" mode. This is the pause between cycles when you hit the run button. The default value is 1000 milliseconds, or, one second.

The Processes Dialog Box

The Processes Dialog Box allows you to enter or modify properties for each process.

The process properties:

Field Description

Number of The number of processes in the simulation. To change this value, use the Options Dialog Processes: (see above). Process Id

The id number for the process. These numbers are used to identify each process and are assigned by the simulator, starting with zero. These numbers cannot be changed.

Process File The name of the file from which process commands are read. This may be any valid Name filename. For convenience, there is a choose button which allows you to browse the file

system to choose the file. By default, the name is the prefix string, followed by the

process number, followed by ".dat". The Resources Dialog Box

The Resources Dialog Box allows you to enter and modify properties for each resource.

The resource properties:

Field Description

Number of The number of resources available in the simulation. To change this value, use the resources: Options Dialog (see above). Resource Id The id number assigned to the resource. This number is used to identify the resource and

is assigned by the simulator and cannot be changed. This is the number which appears in the R (request resource) and F (free resource) commands in the process command files.
Resource Initial Resource Current

The initial number of available instances of the resource. This number is used when the simulator starts or is reset. The current number of available instances of the resource. This number may be changed during the simulation to see the effect it may have on processes waiting for the resource.

The Process Command Files

The process command files for the simulator specifies a sequence operations to be performed by the process or processes which use the file. There are four operations defined C (compute), R (request resource), F (free resource) and H (halt).
Operation Description
C msec

Compute for the specified number of milliseconds (cycles). the resource becomes available. The resource id should be a non-negative number less than the total number of resources available. requested by the process. The resource id should be a non-negative number less than the total number of resources available.

R resource- Request an instance of the specified resource. If none are available, block the process until

id

F resource- Free an instance of the specified resource. This is usually a resource that was previously

id

Halt the process. This is usually the last operation in the file. Any commands which follow it in the file are ignored. Any file that does not end with this operation is implicitly halted.

Sample Process Command Files

The "a0.dat" input file looks like this:

/* a0.dat The "a" collection of process data files is meant to simulate two processes competing for a single resource. If you run the simulator with one resource available, one of the processes will block until the other is done using the resource. */ C 10 // compute for 10 milliseconds R 0 // request resource 0 C 10 // compute for 10 milliseconds F 0 // free resource 0 H // halt process

Note that the "a1.dat" file is identical. In other words, both files request the same resources at approximately the same time.

The Output File

The output file contains a log of the simulation since the simulation started. The output file contains one line per cycle executed. The format of each line is:
time = t available = r0 r1 ... rn blocked = n

where t is the number of milliseconds since the start of the simulation, ri is the number of available instances of each resource, and n is the number of blocked processes. Sample Output

The output file "a.log" looks something like this:

time = 0 available = 1 blocked = 0 time = 1 available = 1 blocked = 0 time = 2 available = 1 blocked = 0 time = 3 available = 1 blocked = 0 time = 4 available = 1 blocked = 0

time = 5 available = 1 blocked = 0 time = 6 available = 1 blocked = 0 time = 7 available = 1 blocked = 0 time = 8 available = 1 blocked = 0 time = 9 available = 1 blocked = 0 time = 10 available = 0 blocked = 1 time = 11 available = 0 blocked = 1 time = 12 available = 0 blocked = 1 time = 13 available = 0 blocked = 1 time = 14 available = 0 blocked = 1 time = 15 available = 0 blocked = 1 time = 16 available = 0 blocked = 1 time = 17 available = 0 blocked = 1 time = 18 available = 0 blocked = 1 time = 19 available = 0 blocked = 1 time = 20 available = 0 blocked = 0 time = 21 available = 0 blocked = 0 time = 22 available = 0 blocked = 0 time = 23 available = 0 blocked = 0 time = 24 available = 0 blocked = 0 time = 25 available = 0 blocked = 0 time = 26 available = 0 blocked = 0 time = 27 available = 0 blocked = 0 time = 28 available = 0 blocked = 0 time = 29 available = 0 blocked = 0 time = 30 available = 1 blocked = 0

In this example, the simulation runs for a total of 30 "milliseconds" and then halts. During the simulation, all processes are computable for 10 milliseconds. During the next 10 milliseconds, the one instance of the resource is allocated to one process, while the other process is blocked. During the final 10 milliseconds, the first process frees the resource, but it is immediately allocated by the second process, which then continues to compute, unblocked, to the end of the simulation.

Lab # 9
VMMap
VMMap is a process virtual and physical memory analysis utility. It shows a breakdown of a process's committed virtual memory types as well as the amount of physical memory (working set) assigned by the operating system to those types. Besides graphical representations of memory usage, VMMap also shows summary information and a detailed process memory map. Powerful filtering, refresh and snapshot comparison capabilities allow you to identify the sources of process memory usage and the memory cost of application features. VMMap works on Windows XP and higher, including x64 64-bit versions of Windows.

Memory Types VMMap categorizes memory into one of several types: Image The memory represents an executable file such as a .exe or .dll and has been loaded into a process by the image loader. It does not include images mapped as data files, which would be included in the Mapped File memory type. Image mappings can include shareable memory like code. When data regions, like initialized data, is modified, additional private memory is created in the process. The Details column shows the file's path. Private

Private memory is memory allocated by VirtualAlloc and not suballocated either by the Heap Manager or the .NET run time. It cannot be shared with other processes, is charged against the system commit limit, and typically contains application data. Shareable Shareable memory is memory that can be shared with other processes, is backed by the paging file (if present), is charged against the system commit limit and typically contains data shared between DLLs in different processes or inter-process communication messages. The Windows APIs refer to this type of memory as pagefile-backed sections. Mapped File The memory is shareable and represents a file on disk. The Details column shows the file's path. Mapped files typically contain application data. Heap Heaps represent private memory managed by the user-mode heap manager and, like the Private memory type, is charged against the system commit limit and contains application data. Application memory allocations using the C runtime malloc library, HeapAlloc and LocalAlloc, use Heap memory. Managed Heap Managed heap represents private memory that's allocated and used by the .NET garbage collector and, like the Private memory type, is charged against the system commit limit and contains application data.

Stack Stacks are private memory used to store function parameters, local function variables and function invocation records for individual threads. Stacks are charged agains the commit limit and typically grow on demand. System System memory is private kernel-mode physical memory associated with the process. The vast majority of System memory consists of the process page tables. Free Free memory regions are spaces in the process address space that are not allocated. Unknown Process private memory that can't be attributed to any other category. This typically includes process page tables and copy-on-write pages that have been modified, but that are no longer writable.

Note: The VirtualProtect API can change the protections of any page to something different than that implied by the original allocation's memory type. That means that there can potentially be pages of memory private to the process in a shareable memory region, for instance, because the region was created as a pagefile-backed section, but then the application changed the protection on some pages to copy-on-write and modified them. The protection shown for a region isn't necessarily the protection it had since it's creation.

The VMMap Window

When you run VMMap, it will present a process selection dialog. After you select a process it analyzes the process and presents the graphs:

Commit Summary Graph This graph shows the committed (memory that represents data or code) memory usage of the process by type. The graph's scale is the total committed virtual memory usage of the process. Private Summary Graph This graph shows the committed private virtual memory. This memory is backed by the paging file and charged against the system commit limit. It corresponds to the PrivateBytes performance counter. Working Set Summary Graph This graph shows the working set usage of the process by memory type. Working set represents the amount of commited virtual memory that's in physical memory and owned by the process. The graph's scale is the total committed virtual memory.

The color key for the regions in the graphs is presented in the Summary View. Below the graphs VMMap shows two windows:

Summary View This shows a summary of the virtual and physical usage of the process by type. Details View This shows the memory regions of the process address space.

For each region, VMMap displays the memory type, memory protection, and virtual and physical memory usage. Selecting a type in the Summary View filters the Details View to just show regions of the selected type. Select Total to show all memory types in the Details View. In order to reduce noise in the output, VMMap does not show entries that have a value of 0.

Both windows include the following columns of information: Size

Total size of the allocated type or region. For the Summary View and regions in the Details View that do not have reserved areas, this is equal to the maximum amount of physical memory required to store the region's data. Committed The amount of the allocation backed by system virtual memory (RAM and paging files) and charged against the system commit limit. Private The amount of the allocation that, if modified, is private to the process (copy-on-write pages that have not been modified are included). This represents the charge to the system commit limit (sum of RAM plus the paging files) of the region. Total WS The amount of physical memory assigned to the type or region. Private WS The amount of physical memory assigned to the type or region that cannot be shared with other processes. Shareable WS The amount of physical memory assigned to the type or region that can be shared with other processes. Shared WS The amount of Shareable WS that is currently shared with other processes. Largest The largest block of the particular size.

Note: Because of limitations in the APIs provided by the operating system, on 64-bit Windows XP or 64-bit Windows Server 2003, Vmmap does not show the regions corresponding to 32-bit thread stacks when analyzing 32-bit processes. Strings In some cases, the purpose of a memory region can be revealed by the string data stored within it. To view printable strings (ASCII or UNICODE strings of three or more characters in length), select a region and then the Strings menu item from the Edit menu.

Refreshing a Scan You can refresh a scan by hitting F5 or selecting Refresh from the Refresh Menu. The Empty Working Set menu item in the Refresh menu releases all physical memory assigned to the process and then refreshes the scan. This feature is useful for measuring the memory cost of an application feature where you would empty the working set, exercise the feature and then refresh the display to look at how much physical memory the application referenced. Viewing Changes VMMap saves the two most recent refresh snapshots and allows you to view the differences by selecting the Show Changes entry in the Options menu. When you toggle to that mode, the status bar shows the times of the refreshes being compared and the summary and details lists shows the differences between them. VMMap shows address ranges that are in the most recent snaphot but not the previous one with a green highlight color and those that were deleted in red. You can toggle back to viewing the statistics of the most recent snapshot by deselecting the option. Options The options menu contains the following items:

Expand All This expands all memory regions in the Details View Collapse All This collapses all memory regions in the Details View Show Free Regions Selecting this causes Details View to include free memory regions Font Use this to change the font of the Summary and Details Views.

Saving, Loading and Copying Saving and Loading Scan Results The Save menu item in the File menu includes several ways to save output from a VMMap scan. The Save dialog has options for the following output format:

.MMP This is the native VMMap file format. Use this format if you want to load the output back into the VMMap display. .CSV This is comma-seperated value output, which is ideal for generating output that you can easily import into Excel. .TXT This format is ideal for sharing the text form of scan results in a readable form.

Note that a saved .MMP file includes the two most recent snapshots, enabling you to view differences with the Refresh Shows Changes option when you load the file back into VMMap. Copying The Edit menu includes two selections for copying output to the clipboard

Copy Address This menu item copies just the address of the currently selected line in the Details View. Copy All This copies the text from the display, including the process name and ID, Summary View and Details View.

Command Line Options VMMap supports the following command-line options: usage: vmmap [-64] [-p <pid or process name> [outputfile]] [-o inputfile] -64 -p Use the 64-bit version to analyze a 32-bit process instead of the 32-bit version.

Process ID or process name. If you specify a name, VMMap will match it against the first process that has a name that begins with the specified text. output file If you specify an output file, VMMap will scan the target process and then terminate. If you don't include an extension, VMMap will add .mmp and save in its native format. Add a .csv extension to save as CSV format; any other extension will save as .txt. inputfile Has VMMap open the specified .mmp file on startup.

Lab #10
File System Simulator Installation on Windows 95/98/Me/NT/2000 Systems Purpose
This document provides instructions for the installation of the File System Simulator on Microsoft Windows operating systems. This procedure should be the same or similar on Windows 95, 98, Me, NT, and 2000 systems. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001).

Requirements
The following software components are required to install and use the File System Simulator.

Java Development Kit (JDK) 1.0 or greater Text program editor (e.g., notepad)

Installation
Installation of the software can be accomplished with these simple steps: 1. Create a directory folder in which you wish to install the simulator (e.g., "C:\moss\filesys"). 2. Download the self-extracting ZIP archive (filesys.exe) into the directory folder. 3. Double-click on the file you downloaded (filesys.exe), or invoke it using the Start -> Run..., or invoke it from an MS-DOS command prompt: 4. C:\moss\filesys> filesys.exe

Files
The directory should now contain the following files: Files Description filesys.exe Self-extracting ZIP archive which contains all the other files. BitBlock.java Java source files (*.java) Block.java DirectoryEntry.java FileDescriptor.java FileSystem.java IndexNode.java Kernel.java ProcessContext.java Stat.java

SuperBlock.java cat.java cp.java dump.java ls.java mkdir.java mkfs.java tee.java BitBlock.class Compiled Java class files (*.class) Block.class DirectoryEntry.class FileDescriptor.class FileSystem.class IndexNode.class Kernel.class ProcessContext.class Stat.class SuperBlock.class cat.class cp.class dump.class ls.class mkdir.class mkfs.class tee.class install_unix.html Documentation install_windows.html user_guide.html javadoc copying.txt Directory containing documentation on java classes (generated by the javadoc utility). Gnu General Public License: Terms and Conditions for Copying, Distribution, and Modification

Compilation
The distribution includes compiled class files as well as the source java files. You should not need to recompile unless you decide to change the code. If you wish to compile the code, the following commands should work if you're using a Java compiler that accepts the normal "javac" command line. C:\moss\filesys> set CLASSPATH=. C:\moss\filesys> javac *.java

Test
To test the program, enter the following sequence of commands.

C:\moss\filesys> java mkfs filesys.dat 256 16 C:\moss\filesys> java mkdir /root C:\moss\filesys> java ls / C:\moss\filesys> dir /b *.java | java tee /root/t.lis C:\moss\filesys> java ls /root C:\moss\filesys> java cat /root/t.lis If things are working correctly, the program will produce output that looks something like this: C:\moss\filesys> java mkfs filesys.dat 256 16 block_size: 256 blocks: 16 super_blocks: 1 free_list_blocks: 1 inode_blocks: 3 data_blocks: 11 block_total: 16

C:\moss\filesys> java mkdir /root C:\moss\filesys> java ls / /: 0 48 . 0 48 .. 1 32 root total files: 3

C:\moss\filesys> dir /b *.java | java tee /root/t.lis BitBlock.java Block.java DirectoryEntry.java FileDescriptor.java FileSystem.java IndexNode.java Kernel.java ProcessContext.java Stat.java SuperBlock.java cat.java cp.java dump.java ls.java mkdir.java mkfs.java tee.java

C:\moss\filesys> java ls /root /root: 1 48 . 0 48 .. 2 236 t.lis total files: 3

C:\moss\filesys> java cat /root/t.lis BitBlock.java Block.java DirectoryEntry.java FileDescriptor.java FileSystem.java IndexNode.java Kernel.java ProcessContext.java Stat.java

SuperBlock.java cat.java cp.java dump.java ls.java mkdir.java mkfs.java tee.java

The programs and their input and output files are described more fully in the File System Simulator User Guide.

File System Simulator User Guide Purpose

This document is a user guide for the File System Simulator. It explains how to use the simulator and describes the programs and the various input files used by and output files produced by the simulator. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001).

Introduction
The file system simulator shows the inner workings of a UNIX V7 file system. The simulator reads or creates a file which represents the disk image, and keeps track of allocated and free blocks using a bit map. A typical exercise might be for students to write a program (in Java) which invokes various simulated operating system calls against a well-known disk image provided by the instructor. Students may also be asked to implement indirect blocks, listbased free block management, or write a utility (like fsck) to check and repair the file system.

Overview
The File System Simulator is a collection of Java classes which simulate the file system calls available in a typical Unix-like operating system. The "Kernel" class contains methods (functions) like "creat()", "open()", "read()", "write()", "close()", etc., which read and write blocks in an underlying file in much the same way that a real file system would read and write blocks on an underlying disk device. In addition to the "Kernel" class, there are a number of underlying classes to support the implementation of the kernel. The classes FileSystem, IndexNode, DirectoryEntry, SuperBlock, Block, BitBlock, FileDescriptor, and Stat contain all data structures and algorithms which implement the simulated file system. Also included are a number of sample programs which can be used to operate on a simulated file system. The Java programs "ls", "cat", "mkdir", "mkfs", etc., perform file system operations to list directories, display files, create directories, and create (initialize) file systems. These programs illustrate the various file system calls and allow the user to carry out various read and write operations on the simulated file system. As mentioned above, there is a backing file for our simulated file system. A "dump" program is included with the distribution so that you can examine this file, byte-by-byte. Any dump program may be used (e.g., the "od" program in Unix); we include this one which is simple to use and understand, and can be used with any operating system. There are a number of ways you can use the simulator to get a better understanding of file systems. You can

use the provided utility programs (mkfs, mkdir, ls, cat, etc.) to perform operations on the simulated file system and use the dump program to examine the underlying file and observe any changes, examine the sample utility programs to see how they use the system call interface to perform file operations, enhance the sample utility programs to provide additional functionality, write your own utility programs to extend the functionality of the simulated file system, and modify the underlying Kernel and other implementation classes to extend the functionality of the

In the sections which follow, you will learn what you need to know to perform each of these activities.

Using File System Simulator Programs

Using mkfs

The mkfs program creates a file system backing file. It does this by creating a file whose size is specified by the block size and number of blocks given. It writes the superblock, the free list blocks, the inode blocks, and the data blocks for a new file system. Note that it will overwrite any existing file of the name specified, so be careful when you use this program.

This program is similar to the "mkfs" program found in Unix-like operating systems. The general format for the mkfs command is java mkfs file-name block-size blocks where file-name is the name of the backing file to create (e.g., filesys.dat). Note that this is the name of a real file, not a file in simulator. This is the file that the simulator uses to simulate the disk device for the simulated file system. This may be any valid file name in your operating system environment. block-size is the block size to be used for the file system (e.g., 256). This should be a multiple of the index node (i-node) size (usually 64) and the directory entry size (usually 16). Modern operating systems usually use a size of 1024, or 512 bytes. We use 128 or 256 byte block sizes in many of our examples so that you can quickly see what happens when directories grow beyond one block. This should be a decimal number not less than 64, but less than 32768. blocks is the number of blocks to create in the file system(e.g., 40). This number includes any blocks that may be used for the superblock, free list management, inodes, and data blocks. We use a relatively small number here so that you can quickly see what happens if you run out of disk space. This can be any decimal number greater than 3, but not greater than 224 - 1 (the maximum number of blocks), although you may not have sufficient space to create a very large file. For example, the command java mkfs filesys.dat 256 40 will create (or overwrite) a file "filesys.dat" so that it contains 40 256-byte blocks for a total of 10240 bytes. The output from the command should look something like this: block_size: 256 blocks: 40 super_blocks: 1 free_list_blocks: 1 inode_blocks: 8 data_blocks: 30 block_total: 40

From the output you can see that one block is needed for the superblock, one for free list management, eight for index nodes, and the remaining 30 are available for data blocks. Why is there 1 block for free list management? Note that 30 blocks require 30 bits in the free list bitmap. Since 256 bytes/block * 8 bits/byte = 2048 bits/block, clearly one bitmap block is sufficient to track block allocation for this file system. Why are there 8 blocks for index nodes? Note that 30 blocks could result in 30 inodes if many one-block files or directories are created. Since each inode requires 64 bytes, only 4 will fit in a block. Therefore, 8 blocks are set aside for up to 32 inodes.
Using mkdir

The mkdir program can be used to create new directories in our simulated file system. It does this by creating the file specified as a directory file, and then writing the directory entries for "." and ".." to the newly created file. Note that all directories leading to the new directory must already exist. This program is similar to the "mkdir" command in Unix-like and MS-DOS-related operating systems. The general format for the mkdir command is java mkdir directory-path where directory-path is the path of the directory to be created (e.g., "/root", or "temp", or "../home/rayo/moss/filesys"). If directory-path does not begin with a "/", then it is appended to the path name for working directory for the default process. For example, the command java mkdir /home creates a directory called "home" as a subdirectory of the root directory of the file system.

Similarly, the command java mkdir /home/rayo creates a directory called "rayo" as a subdirectory of the "home" directory, which is presumed to already exist as a subdirectory of the root directory of the file system. Using ls The ls program is used to list information about files and directories in our simulated file system. For each file or directory name given it displays information about the files named, or in the case of directories, for each file in the directories named. This program is similar to the "ls" command in Unix-like operating systems, or the "dir" command in DOS-related operating systems. The general format for the ls command is java ls path-name ... where path-name ... is a space-separated list of one or more file or directory path names. For example, the command java ls /home lists the contents of the "/home" directory. For each file in the directory, a line is printed showing the name of the file or subdirectory, and other pertinent information such as size. The output from the command should look something like this: /home: 1 32 . 0 48 .. total files: 2

In this case we see that the "/home" directory contains entries for ".", "..", and "rayo". Using tee The tee program reads from standard input and writes whatever is read to both standard output and the named file. You can use this program to create files in our simulated file system with content created in the operating system environment. This program is similar to the "tee" command found in many Unix-like operating systems. The general format for the tee command is java tee file-path where file-path is the name of a file to be created in the simulated file system. If the named file already exists, it will be overwritten. For example, echo "howdy, podner" | java tee /home/rayo/hello.txt causes the single line "howdy, podner" to be written to the file "/home/rayo/hello.txt". The output from the command is howdy, podner which you should note was the same as the input sent to the tee program by the "echo" command. Note that the "|" (pipe) is almost always used with the tee program. Users of Unix-like operating systems will find the "echo", and "cat" commands useful to produce input for the pipe to tee. Users of MS-DOS-related operating systems will find the "echo" and "type" commands to be useful in this regard. If you wish to simply enter text directly to a file, then you may use tee directly (i.e., without the pipe). Users of Unix-like operating systems will need to use CTRL-D to signal the end of input. Users of MS-DOS-related operating systems will need to use CTRL-Z to signal the end of input.

Using cp The cp program allows you to copy the contents from one file to another in our simulated file system. If the destination file already exists, it will be overwritten. This program is similar to the "cp" command in Unix-like operating systems, and the "copy" command in MS-DOS-related operating systems. The general format of the "cp" command is java cp input-file-name output-file-name where input-file-name is the path-name for the file to be copied (i.e., the source file, and output-file-name is the path-name for the file to be created (i.e., the target file. For example, java cp /home/rayo/hello.txt /home/rayo/greeting.txt creates a new file "/home/rayo/greeting.txt" by copying to it the contents of file "/home/rayo/hello.txt". Using cat The cat program reads the contents of a named file and writes it to standard output. The cat program is generally used to display the contents of a file. This program is similar to the "cat" command in Unix-like operating systems, or the "type" command in MS-DOS-related operating systems. The general format of the cat command line is java cat file-name where file-name is the name of the file from which data are to be read for writing to standard output. For example, java cat /home/rayo/greeting.txt causes the file "/home/rayo/greeting.txt" to be read, the contents of which are written to standard output. In this case, the output from the program might look something like this howdy, podner

Dumping the File System

While you are working with the file system simulator, you may wish to dump the contents of the backing file to see if it contains what you think it contains. The dump program shows the contents of a file in the operating environment, one byte at a time, in various formats (hexadecimal, decimal, ASCII). Note that dump dumps the contents of a real file, not a file in our simulated file system. The general format of the dump command line is java dump file-name where file-name is the name of the file to be dumped. This should generally be the name of the backing file for the file system simulator (e.g., "filesys.dat"). The general format of the dump output is addr hex dec asc where addr is the decimal address of the byte, hex is the hexadecimal value of the byte, dec is the decimal value of the byte, and asc is the corresponding ASCII character if the value is between 33 and 127 (decimal). Each line of dump output corresponds to a single byte in the file. To keep the listing brief, dump only displays non-zero bytes from the input file. For example java dump filesys.dat | more causes the contents of the file "filesys.dat" to be displayed, one line per byte. The "| more" causes you to be prompted for each page of the output. The first page of the output should look something like this: 011

5 28 40 ( 911 13 2 2 17 a 10 256 1f 31 512 40 64 @ 515 3 3 523 30 48 0 527 ff 255 528 ff 255 529 ff 255 530 ff 255 531 ff 255 532 ff 255 533 ff 255 534 ff 255 535 ff 255 536 ff 255 537 ff 255 538 ff 255 539 ff 255 540 ff 255 541 ff 255

You should notice, for example, that the first block (the super block) contains a few numeric values corresponding to the block size (the 1 in the 0 byte means 256), number of blocks, etc. The second block (starting at byte 256) contains a few bits that are set, indicating that the first few blocks are allocated. The third block (starting at 512) contains a few index nodes; the FF/255 values indicate that a direct block is unallocated. A little further down you will see ".", and ".." for the directory entries for the root file system, and other data blocks.

Simulator Configuration File

Each file system simulator program must call Kernel.initialize() before calling any of the other Kernel methods. The initialize() method reads a configuration file ("filesys.conf" is the default), opens the backing file for the file system ("filesys.dat" is the default), and performs other initializations. This section of the user guide describes the various options which may be set in the configuration file.
Configuration File Options Name Description Default Value

filesystem.root.filename The name of the file containing the root file system for the filesys.dat simulation. filesystem.root.mode The mode to use when opening the root file system backing file. rw The mode should either be "rw" for reading and writing, or "r" for read-only access. The numeric user id (uid) to use for the default process context. 1 This should be a number between 0 and 32767. The numeric group id (gid) to use for the default process context. 1 This should be a number between 0 and 32767. The umask to use for the default process context. This should be 022 an octal number between 000 and 777. The working directory in the simulated file system to be used for /root the default process context. This should be a string that starts with "/". The maximum number of files that may be open at a time by a 10 process. When a process context is created, this many slots are created for possible open files. The maximum number of files that may be open at one time by 20 all processes in the simulation. When the simulator starts, this many slots are created for possible open files.

process.uid

process.gid

process.umask

process.dir

process.max_open_files

kernel.max_open_files

A Sample Configuration File In addition to the standard configuration file, "filesys.conf", the distribution also includes a smaller sample configuration file, "sample.conf". This is shown below to illustrate a typical configuration file. !

! my personal filesys configuration file ! filesystem.root.filename = rayo.dat filesystem.root.mode = r process.uid = 1000 process.gid = 1000 process.umask = 002 process.dir = /home/rayo In this particular example, the file system is contained in the backing file "rayo.dat", which is here being opened for read-only access. The working directory for the default process context is "/home/rayo", with the uid, gid, and umask shown. Specifying an Alternate Configuration File The default configuration file is named "filesys.conf" and is included in the application distribution. You may modify this file directly to set various options, or you may create your own configuration file and specify the name of this new file when you launch your simulator programs. If you choose to create your own configuration file, you will need to define a system property "filesys.conf" which contains the name of file. For example, suppose you wanted to run the "ls" program using "my_filesys.conf" as the configuration file. Your java command would look something like this: java -Dfilesys.conf=my_filesys.conf ls /home If there is no value set for the "filesys.conf" system property, then the name "filesys.conf" is used as the default configuration filename.

Writing File System Simulator Programs

Writing programs that use the File System Simulator requires the use of the Kernel class, and may involve the use of the classes Stat and DirectoryEntry. If you're writing ordinary programs that use the standard file system calls, you should not need to reference any other classes. These three classes are described briefly here. For more information, follow the link for the class to the javadoc for that class. Kernel Sets up the simulator environment and defines all the system calls. This class defines: the method initialize(), which is used to initialize the file system simulator; the creat(), open(), read(), write(), close(), and other methods which simulate the work of a file system; and constants like EBADF, S_IFDIR, and O_RDONLY which are used to represent parameter or return values for the system calls. All the methods and fields of Kernel are static; you do not instantiate a Kernel object. For examples, see any of the sample programs (i.e., cat.java, cp.java, ls.java, etc.)

Stat A data structure that represents information about a file or directory. This intends to faithfully represent the Unix stat struct. You may reference fields within a stat object directly (e.g., stat.st_ino), or using JavaBean-style accessor/mutator methods (e.g., stat.getIno() or stat.setIno(). Stat objects are updated by the methods Kernel.stat() and Kernel.fstat(). For examples, see mkdir.java. DirectoryEntry A data structure that represents a single record in a directory file. This intends to faithfully represent a Unix dirent struct. It contains an index node number and a file name. You may reference the fields directly (e.g., dirent.d_ino), or using JavaBeanstyle accessor/mutator methods (e.g., dirent.getIno() or dirent.setIno()). However, Java programmers my find it more convenient to use the getName() and setName() (which use String) instead of the field d_name (which is byte[]). DirectoryEntry objects are updated by the method Kernel.readdir(). For examples, see mkdir.java and ls.java. For more information about Unix system calls and the stat and dirent structs, refer to a Unix system manual. Users of Unix-like systems may find the commands "man -S 2 creat", "man -S 2 open", etc. to be helpful. All programs that use the File System Simulator should adhere to the following guidelines:

Invoke the method Kernel.initialize() before any other File System Simulator calls. Use Kernel.exit() when you wish to terminate processing in your program. Check for errors after each system call (e.g., creat(), open(), read(), write(), etc.). Nearly all the system calls return -1 if an error occurs. Use Kernel.perror() to print the message associated with an error. Use Kernel.getErrno() to determine which error occurred, if needed. Note that in standard Unix programs you would reference the static process variable "errno".

Collectively, these sample programs invoke all of the core methods (system calls) of the file system simulator.

Enhancing the File System Simulator

Adding new features to the File System Simulator is an excellent way to probe your understanding of file system operation, and to investigate new features. Enhancements will almost certainly require changes to the class Kernel, and may necessitate changes to the sample programs described above. This section describes the other classes that implement the functionality of the simulator so that you may understand the intended organization of these components when making a proposed enhancement. The following are the internal classes for the file system simulator: BitBlock A data structure that views a device block as a sequence of bits. The methods setBit(), resetBit(), and isBitSet() are used to set, reset, or check a bit in the block. This

structure is used to implement bitmaps, and is used by the file system simulator to track allocated and free data blocks in the file system. BitBlock extends Block. Block A data structure that views a device block as a sequence of bytes. The field bytes is an array of byte, and is directly accessible. Included are methods to read() and write() the block to a java.io.RandomAccessFile, which simulate the action of reading or writing a device block. FileDescriptor A structure and collection of methods that represent an open file. It includes a number of get and set methods for various tidbits of information about the open file, and provides readBlock and writeBlock() methods for reading and writing the blocks of the file. FileSystem A structure and collection of methods that represent an open (mounted) file system. It includes a few get and set methods for various fields about the file system, but more importantly, includes methods to open() the file behind the file system, to read() and write() blocks of the device, to manage blocks (allocateBlock() and freeBlock()) and to manage inodes (allocateIndexNode()). In general, Kernel methods should call FileSystem methods when they want to read or write data in the file system. IndexNode A structure and collection of methods for representing an index node. This is meant to reflect the exact structure on disk for an index node. It includes get and set methods for each of the fields in the index node. Also included are read() and write() methods which are used to copy data to and from byte arrays (not disk files). ProcessContext A structure and collection of methods to represent a process. This is where the simulator stores the uid, gid, umask, dir, and other information for the current process. It includes get and set methods for each of the fields in a process. SuperBlock A structure and collection of methods for representing the superblock on the disk. In our implementation, the superblock contains information about the block size, number of blocks, offsets to the first block of the free list, inode block, and data block areas of the device. It includes get and set methods for each of the fields in the superblock. Also included are methods to read() and write() the superblock.

Lab #11
Memory Management Simulator Installation on Windows 95/98/Me/NT/2000 Systems Purpose
This document provides instructions for the installation of the Memory Management Simulator on Microsoft Windows operating systems. This procedure should be the same or similar on Windows 95, 98, Me, NT, and 2000 systems. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001). This installation guide only provides information about installing the software and testing the configuration for Windows operating systems.

Requirements
The following software components are required to install and use the Memory Management Simulator.

Microsoft Windows 95, 98, Me, NT, or 2000 Java Development Kit (JDK) 1.0 or greater Text program editor (e.g., notepad)

Pre-Installation
Before installation, you should verify:

that you have a working java runtime environment, that you have a working java development environment, and that the working directory is in the classpath for the runtime environment.

If you're using a standard command-line java compiler, the following instructions will help determine if your environment is configured correctly. 1. Verify that you have java installed and configured in your environment. 2. C:\WINDOWS> java -version You should see a message like this with possibly a different version number. java version "1.1.8" If you get a message like: Bad command or file name Then java may not be installed on your system, or may not be configured for your use.

If you think that Java may already be installed on your system but may not be in your "path", you can find it by choosing Start -> Find -> Files or Folders and enter "java.exe" in the "Named:" field and click the Find Now button. If found, make note of the directory folder in which it resides (e.g., "C:\jdk1.1.8\bin"). While you're at it, also seach for javac.exe to see if the Java compiler is installed and whether it's in the same directory as the java.exe file. If Java isn't available on your system, you should check with your instructor or system administrator. If you administer your own system, then you should be able to find a copy of Java for your operating system. If you find that java is installed but not configured for your use, then perhaps you need to add it to your path. Consult your instructor or system administrator if you need help adding this to your path. 3. Verify that the java compiler is installed and configured in your environment. 4. C:\WINDOWS> javac If you're using a standard java command-line compiler, you should see a message similar to this. use: javac [-g][-O][-debug][-depend][-nowarn][-verbose][-classpath path][-nowrite][deprecation][-d dir][-J] file.java... If you get a message like: Bad command or file name then the java compiler may not be installed on your system, or may not be configured for your use. Consult your instructor or system administrator. 5. Verify that that the current directory is in your classpath. 6. C:\WINDOWS> echo "%CLASSPATH%" You should see a list of directories separated by semi-colons (";") or possibly just "". If you don't see the directory "." (a single period, which stands for the current directory), then you should add it to the classpath. C:\WINDOWS> set CLASSPATH=.;%CLASSPATH% If you have a working java runtime environment, a working java compiler, and the current directory is in your path, then you're ready to proceed with the installation.

Installation
Installation of the software can be accomplished with these simple steps:

1. Create a directory folder in which you wish to install the simulator (e.g., "C:\moss\memory"). You can do this using the Windows explorer, or from the MSDOS prompt. To create the directory from the MS-DOS prompt: 2. C:\WINDOWS> cd \ 3. C:\> mkdir moss 4. C:\> cd moss 5. C:\moss> mkdir memory 6. C:\moss> cd memory 7. C:\moss\memory> 8. Double-click on the file you downloaded (memory.exe), or invoke it using Start -> Run..., or invoke it from an MS-DOS command prompt: 9. C:\moss\memory> memory.exe Files The directory should now contain the following files: Files Description memory.exe Self-extracting ZIP archive which contains all the other files. Common.java Java source files (*.java) ControlPanel.java Instruction.java Kernel.java MemoryManagement.java PageFault.java Page.java Virtual2Physical.java Common.class Compiled Java class files (*.class) ControlPanel.class Instruction.class Kernel.class MemoryManagement.class PageFault.class Page.class Virtual2Physical.class commands memory.conf install_unix.html install_windows.html user_guide.html user_guide_1.gif copying.txt

Sample input command file Sample configuration file Documentation and associated images

Gnu General Public License: Terms and Conditions for Copying, Distribution, and Modification

Compilation

The distribution includes compiled class files as well as the source java files. You should not need to recompile unless you decide to change the code. If you wish to compile the code, the following commands should work if you're using a Java compiler that accepts the normal "javac" command line. C:\moss\memory> javac -nowarn *.java The -nowarn flag supresses warning messges, of which there may be several. For backward compatability we use only those features of Java which have been present from the beginning, some of which are deprecated and are usually reported by the compiler with warning messages.

Test
To test the program, enter the following command line. C:\moss\memory> java MemoryManagement commands memory.conf The program will display a window allowing you to run the simulator. When the window presents itself, click on the Run button. You should see the program "execute" 7 memory operations, about one per second. When the simulation completes, click the Exit button. The memory operation commands are read from a file called "commands", and the initial configuration and various options are specified in the file "memory.conf". The program also produces a log file called "tracefile" in the working directory. The "commands" file looks something like this: // Enter READ/WRITE commands into this file // READ <OPTIONAL number type: bin/hex/oct> <virtual memory address or random> // WRITE <OPTIONAL number type: bin/hex/oct> <virtual memory address or random> READ bin 100 READ 19 WRITE hex CC32 READ bin 10000000000000000 READ bin 10000000000000000 WRITE bin 11000000000000001 WRITE random If things are working correctly, the "tracefile" should look something like this: READ 4 ... okay READ 13 ... okay WRITE 3acc32 ... okay READ 10000000 ... okay READ 10000000 ... okay WRITE c0001000 ... page fault WRITE 1ff82cdc ... okay

The program and its input and output files are described more fully in the Memory Management Simulator User Guide.

Memory Management Simulator User Guide Purpose

This document is a user guide for the Memory Management Simulator. It explains how to use the simulator and describes the display and the various input files used by and output files produced by the simulator. The software is designed for use with Andrew S. Tanenbaum, Modern Operating Systems, 2nd Edition (Prentice Hall, 2001). The Memory Management Simulator was written by Alex Reeder ([email protected]). .

Introduction
The memory management simulator illustrates page fault behavior in a paged virtual memory system. The program reads the initial state of the page table and a sequence of virtual memory instructions and writes a trace log indicating the effect of each instruction. It includes a graphical user interface so that students can observe page replacement algorithms at work. Students may be asked to implement a particular page replacement algorithm which the instructor can test by comparing the output from the student's algorithm to that produced by a working implementation.

Running the Simulator

The program reads a command file, optionally reads a configuration file, displays a GUI window which allows you to execute the command file, and optionally writes a trace file. To run the program, enter the following command line. $ java MemoryManagement commands memory.conf The program will display a window allowing you to run the simulator. You will notice a row of command buttons across the top, two columns of "page" buttons at the left, and an informational display at the right.

Typically you will use the step button to execute a command from the input file, examine information about any pages by clicking on a page button, and when you're done, quit the simulation using the exit button.

The buttons:
Button Description
run

runs the simulation to completion. Note that the simulation pauses and updates the screen between each step. runs a single setup of the simulation and updates the display. initializes the simulator and starts from the beginning of the command file.

step reset

exit

exits the simulation.

page n display information about this virtual page in the display area at the right.

The informational display: Field status: time: instruction: address: page fault: virtual page: Description RUN, STEP, or STOP. This indicates whether the current run or step is completed. number of "ns" since the start of the simulation. READ or WRITE. The operation last performed. the virtual memory address of the operation last performed. whether the last operation caused a page fault to occur. the number of the virtual page being displayed in the fields below. This is the last virtual page accessed by the simulator, or the last page n button pressed.

physical page: the physical page for this virtual page, if any. -1 indicates that no physical page is associated with this virtual page. R: M: inMemTime: whether this page has been read. (1=yes, 0=no) whether this page has been modified. (1=yes, 0=no) number of ns ago the physical page was allocated to this virtual page.

lastTouchTime: number of ns ago the physical page was last modified. low: high: low virtual memory address of the virtual page. high virtual memory address of the virtual page.

The Command File

The command file for the simulator specifies a sequence of memory instructions to be performed. Each instruction is either a memory READ or WRITE operation, and includes a virtual memory address to be read or written. Depending on whether the virtual page for the address is present in physical memory, the operation will succeed, or, if not, a page fault will occur. Operations on Virtual Memory There are two operations one can carry out on pages in memory: READ and WRITE. The format for each command is operation address or operation random where operation is READ or WRITE, and address is the numeric virtual memory address, optionally preceeded by one of the radix keywords bin, oct, or hex. If no radix is supplied, the number is assumed to be decimal. The keyword random will generate a random virtual memory address (for those who want to experiment quickly) rather than having to type an address. For example, the sequence READ bin 01010101 WRITE bin 10101010 READ random WRITE random causes the virtual memory manager to: 1. 2. 3. 4. read from virtual memory address 85 write to virtual memory address 170 read from some random virtual memory address write to some random virtual memory address

Sample Command File The "commands" input file looks like this: // Enter READ/WRITE commands into this file // READ // WRITE READ bin 100 READ 19 WRITE hex CC32 READ bin 100000000000000 READ bin 100000000000000

WRITE bin 110000000000001 WRITE random

The Configuration File

The configuration file memory.conf is used to specify the the initial content of the virtual memory map (which pages of virtual memory are mapped to which pages in physical memory) and provide other configuration information, such as whether operation should be logged to a file. Setting Up the Virtual Memory Map The memset command is used to initialize each entry in the virtual page map. memset is followed by six integer values: 1. 2. 3. 4. 5. 6. The virtual page # to initialize The physical page # associated with this virtual page (-1 if no page assigned) If the page has been read from (R) (0=no, 1=yes) If the page has been modified (M) (0=no, 1=yes) The amount of time the page has been in memory (in ns) The last time the page has been modified (in ns)

The first two parameters define the mapping between the virtual page and a physical page, if any. The last four parameters are values that might be used by a page replacement algorithm. For example, memset 34 23 0 0 0 0 specifies that virtual page 34 maps to physical page 23, and that the page has not been read or modified. Note:

Each physical page should be mapped to exactly one virtual page. The number of virtual pages is fixed at 64 (0..63). The number of physical pages cannot exceed 64 (0..63). If a virtual page is not specified by any memset command, it is assumed that the page is not mapped.

Other Configuration File Options There are a number of other options which can be specified in the configuration file. These are summarized in the table below. Keyword Values Description Whether logging of the operations should be enabled. If logging is enabled, then the program writes a one-line message for each READ or WRITE operation. By default, no logging is enabled. See also the

enable_logging true false

log_file option. log_file tracefilename The name of the file to which log messages should be written. If no filename is given, then log messages are written to stdout. This option has no effect if enable_logging is false or not specified.

pagesize

n The size of the page in bytes as a power of two. This can be given as power p a decimal number which is a power of two (1, 2, 4, 8, etc.) or as a power of two using the power keyword. The maximum page size is 67108864 or power 26. The default page size is power 26. n The radix in which numerical values are displayed. The default radix is 2 (binary). You may prefer radix 8 (octal), 10 (decimal), or 16 (hexadecimal).

addressradix

Sample Configuration File The "memory.conf" configuration file looks like this: // memset virt page # physical page # R (read from) M (modified) inMemTime (ns) lastTouchTime (ns) memset 0 0 0 0 0 0 memset 1 1 0 0 0 0 memset 2 2 0 0 0 0 memset 3 3 0 0 0 0 memset 4 4 0 0 0 0 memset 5 5 0 0 0 0 memset 6 6 0 0 0 0 memset 7 7 0 0 0 0 memset 8 8 0 0 0 0 memset 9 9 0 0 0 0 memset 10 10 0 0 0 0 memset 11 11 0 0 0 0 memset 12 12 0 0 0 0 memset 13 13 0 0 0 0 memset 14 14 0 0 0 0 memset 15 15 0 0 0 0 memset 16 16 0 0 0 0 memset 17 17 0 0 0 0 memset 18 18 0 0 0 0 memset 19 19 0 0 0 0 memset 20 20 0 0 0 0 memset 21 21 0 0 0 0 memset 22 22 0 0 0 0 memset 23 23 0 0 0 0 memset 24 24 0 0 0 0 memset 25 25 0 0 0 0 memset 26 26 0 0 0 0 memset 27 27 0 0 0 0

memset 28 28 0 0 0 0 memset 29 29 0 0 0 0 memset 30 30 0 0 0 0 memset 31 31 0 0 0 0 // enable_logging 'true' or 'false' // When true specify a log_file or leave blank for stdout enable_logging true // log_file // Where is the name of the file you want output // to be print to. log_file tracefile // page size, defaults to 2^14 and cannot be greater than 2^26 // pagesize or <'power' num (base 2)> pagesize 16384 // addressradix sets the radix in which numerical values are displayed // 2 is the default value // addressradix addressradix 16 // numpages sets the number of pages (physical and virtual) // 64 is the default value // numpages must be at least 2 and no more than 64 // numpages numpages 64

The Output File

The output file contains a log of the operations since the simulation started (or since the last reset). It lists the command that was attempted and what happened as a result. You can review this file after executing the simulation. The output file contains one line per operation executed. The format of each line is: command address ... status where:

command is READ or WRITE, address is a number corresponding to a virtual memory address, and status is okay or page fault.

Sample Output The output "tracefile" looks something like this: READ 4 ... okay READ 13 ... okay

WRITE 3acc32 ... okay READ 10000000 ... okay READ 10000000 ... okay WRITE c0001000 ... page fault WRITE 2aeea2ef ... okay

Lab #12
PsTools
The Windows NT and Windows 2000 Resource Kits come with a number of command line tools that help you administer your Windows NT/2K systems. Over time, I've grown a collection of similar tools, including some not included in the Resource Kits. What sets these tools apart is that they all allow you to manage remote systems as well as the local one. The first tool in the suite was PsList, a tool that lets you view detailed information about processes, and the suite is continually growing. The "Ps" prefix in PsList relates to the fact that the standard UNIX process listing command-line tool is named "ps", so I've adopted this prefix for all the tools in order to tie them together into a suite of tools named PsTools. All of the utilities in the PsTools suite work on Windows NT, Windows 2000, Windows XP, and Server 2003 and none of the tools requires any special installation. You don't even need to install any client software on the remote computers at which you target them. Run them by typing their name and any command-line options you want. To show complete usage information, specify the "-?" command-line option. The tools included in the PsTools suite are:

PsGetSid - display the SID of a computer or a user PsInfo - list information about a system PsKill - kill processes by name or process ID PsList - list detailed information about processes PsLoggedOn - see who's logged on locally and via resource sharing PsLogList - dump event log records PsService - view and control services

Requirements Some of the tools require that the default admin$ share be available and/or that the Remote Registry service be active.
PsGetSid

Have you performed a rollout and only to discover that your network might suffer from the SID duplication problem? In order to know which systems have to be assigned a new SID (using a SID updater like Sysinternals' own NewSID) you have to know what a computer's machine SID is. Up until now there's been no way to tell the machine SID without knowing Regedit tricks and exactly where to look in the Registry. PsGetSid makes reading a computer's SID easy, and works across the network so that you can query SIDs remotely. PsGetSid also lets you see the SIDs of user accounts. Installation Copy PsPsGetSid onto your executable path and type "psgetsid". Usage

Usage: psgetsid [\\computer[,computer[,...] | @file [-u username [-p password]]] [account] If you want to see a computer's SID just pass the computer's name as a command-line argument. If you want to see a user's SID, name the account (e.g. "administrator") on the command-line and an optional computer name. Specify a user name if the account you are running from doesn't have administrative privileges on the computer you want to query. If you don't specify a password as an option PsGetSid will prompt you for one so that you can type it in without having it echoed to the display.

PsInfo

PsInfo is a command-line tool that gathers key information about the local or remote system, including the type of installation, kernel build, registered organization and owner, number of processors and their type, memory size, the install date of the system, and if it's a trial version, the expiration date. PsInfo command-line switches also let you view installed hotfixes and software applications. Installation Copy PsInfo onto your executable path and type psinfo. Usage By default PsInfo shows information for the local system. Specify a remote computer name to obtain information from the remote system. Since PsInfo relies on remote Registry access to obtain its data, the remote system must be running the Remote Registry service and the account from which you run PsInfo must have access to the HKLM\System portion of the remote Registry.

In order to aid in automated Service Pack updates, PsInfo returns as a value the Service Pack number of system (e.g. 0 for no service pack, 1 for SP 1, etc). usage: psinfo [\\computer[,computer[,...] | @file [-u username [-p password]]] [-h] [-s] [-d] [c [-t delimter]] computer Run the command on the computer or computers specified. If you omit the computer name the command runs on the local system and if you enter a computer name of \\* then the command runs on all computers in the current domain. Execute the command on each of the computers listed in the file. Specifies optional user name for login to remote computer. Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password. Shows installed hotfixes. Shows installed software. Show disk volume information. Dump in CSV format. The default delimiter for the -s option is a comma, but can be overriden with the specified character.

@file -u -p -h -s -d -c -t

PsKill

Windows NT/2000 does not come with a command-line 'kill' utility. You can get one in the Windows NT or Win2K Resource Kit, but the kit's utility can only terminate processes on the local computer. PsKill is a kill utility that not only does what the Resource Kit's version does, but can also kill processes on remote systems. You don't even have to install a client on the target computer to use PsKill to terminate a remote process. Installation

Copy PsKill onto your executable path and type pskill with command-line options defined below. Usage Running PsKill with a process ID directs it to kill the process of that ID on the local computer. If you specify a process name PsKill will kill all processes that have that name. usage: pskill [-t] [\\computer [-u username] [-p password]] <process name | process id> -t -u -p process id process name Kill the process and its descendants. Specifies optional user name for login to remote computer. Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password. Specifies the process ID of the process you want to kill. Specifies the process name of the process or processes you want to kill.

Image before running pskill.

Image using pskill to terminate the selected process

PsList

Most UNIX operating systems ship with a command-line tool called "ps" (or something equivalent) that administrators use to view detailed information about process CPU and memory usage. Windows NT/2K comes with no such tool natively, but you can obtain similar tools with the Windows NT Workstation or Server Resource Kits. The tools in the Resource Kits, pstat and pmon, show you different types of information, and will only display data regarding the processes on the system on which you run the tools. PsList is utility that shows you a combination of the information obtainable individually with pmon and pstat. You can view process CPU and memory information, or thread statistics. What makes PsList more powerful than the Resource Kit tools is that you can view process and thread statistics on a remote computer. Installation Copy PsList onto your executable path and type "pslist".

Usage The default behavior of PsList is to show CPU-oriented information for all the processes that are currently running on the local system. The information listed for each process includes the time the process has executed, the amount of time the process has executed in kernel and user modes, and the amount of physical memory that the OS has assigned the process. Command-line switches allow you to view memory-oriented process information, thread statistics, or all three types of data. usage: pslist [-?] [-d] [-m] [-x][-t][-s [n] [-r n] [\\computer [-u username] [-p password]] [[-e] name | pid] -d -m -x -t -s [n] -r n -u This switch has PsList show statistics for all active threads on the system, grouping threads with their owning process. This switch has PsList show memory-oriented information for each process, rather than the default of CPU-oriented information. With this switch PsList shows CPU, memory and thread information for each of the processes specified. Show process tree. Run in task-manager mode, for optional seconds specified. Press Escape to abort. Task-manager mode refresh rate in seconds (default is 1). Specifies optional user name for login to remote computer.

-p name

Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password. Instead of listing all the running processes in the system, this parameter narrows PsList's scan to those processes that begin with the name process. Thus: Pslist w would statistics for all the processes that start with "w", which would include Winword. Use the -e switch if you want the process name to be treated as an exact match instead of a partial match. Instead of listing all the running processes in the system, this parameter narrows PsList's scan to the process that has the specified PID. Thus: pslist 2884 would dump statistics for the process with the PID 2884.

-e pid

Image result for pslist w

Image result for PID 2884

PsLoggedOn

You can determine who is using resources on your local computer with the "net" command ("net session"), however, there is no built-in way to determine who is using the resources of a remote computer. In addition, NT comes with no tools to see who is logged onto a computer, either locally or remotely. PsLoggedOn is an applet that displays both the locally logged on users and users logged on via resources for either the local computer, or a remote one. If you specify a user name instead of a computer, PsLoggedOn searches the computers in the network neighborhood and tells you if the user is currently logged on. PsLoggedOn's definition of a locally logged on user is one that has their profile loaded into the Registry, so PsLoggedOn determines who is logged on by scanning the keys under the HKEY_USERS key. For each key that has a name that is a user SID (security Identifier), PsLoggedOn looks up the corresponding user name and displays it. To determine who is logged onto a computer via resource shares, PsLoggedOn uses the NetSessionEnum API. Note that PsLoggedOn will show you as logged on via resource share to remote computers that you query because a logon is required for PsLoggedOn to access the Registry of a remote system. Installation

Copy PsLoggedOn onto your executable path and type "psloggedon". Usage usage: psloggedon [-?] [-l] [-x] [\\computername | username] -l -x \\computername username Shows only local logons instead of both local and network resource logons. Don't show logon times. Specifies the name of the computer for which to list logon information. If you specify a user name PsLoggedOn searches the network for computers to which that user is loggedon. This is useful if you want to ensure that a particular user is not logged on when you are about to change their user profile configuration.

PsLogList

The Resource Kit comes with a utility, elogdump, that lets you dump the contents of an Event Log on the local or a remote computer. PsLogList is a clone of elogdump except that PsLogList lets you login to remote systems in situations your current set of security credentials would not permit access to the Event Log, and PsLogList retrieves message strings from the computer on which the event log you view resides. Installation Copy PsLogList onto your executable path and type "psloglist". Usage The default behavior of PsLogList is to show the contents of the System Event Log on the local computer, with visually-friendly formatting of Event Log records. Command line options let you view logs on different computers, use a different account to view a log, or to have the output formatted in a string-search friendly way.

usage: psloglist [-?] [\\computer[,computer[,...] | @file [-u username [-p password]]] [-s [-t delimiter]] [-m #|-n #|-h #|-d #|-w][-c][-x][-r][-a mm/dd/yy][-b mm/dd/yy][-f filter] [-i ID[,ID[,...] | -e ID[,ID[,...]]] [-o event source[,event source][,..]]] [-q event source[,event source][,..]]] [-l event log file] <eventlog> @file -a -b -c -d -e -f -g -h -i -l -m -n -o -p -q -r -s -t -u -w -x eventlog Execute the command on each of the computers listed in the file. Dump records timestamped after specified date. Dump records timestamped before specified date. Clear the event log after displaying. Only display records from previous n days. Exclude events with the specified ID or IDs (up to 10). Filter event types with filter string (e.g. "-f w" to filter warnings). Export an event log as an evt file. This can only be used with the -c switch (clear log). Only display records from previous n hours. Show only events with the specified ID or IDs (up to 10). Dump records from the specified event log file. Only display records from previous n minutes. Only display the number of most recent entries specified. Show only records from the specified event source (e.g. \"-o cdrom\"). Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password. Omit records from the specified event source or sources (e.g. \"-o cdrom\"). Dump log from least recent to most recent. This switch has PsLogList print Event Log records one-per-line, with comma delimited fields. This format is convenient for text searches, e.g. psloglist | findstr /i text, and for importing the output into a spreadsheet. The default delimeter is a comma, but can be overriden with the specified character. Specifies optional user name for login to remote computer. Wait for new events, dumping them as they generate. Dump extended data. By default PsLogList shows the contents of the System Event Log. Specify a different event log by typing in the first few letters of the log name, application, system, or security.

PsService

PsService is a service viewer and controller for Windows NT/2K. Like the SC utility that's included in the Windows NT and Windows 2000 Resource Kits and Windows XP, PsService displays the status, configuration, and dependencies of a service, and allows you to start, stop, pause, resume and restart them. Unlike the SC utility, PsService enables you to logon to a remote system using a different account, for cases when the account from which you run it doesn't have required permissions on the remote system. PsService includes a unique servicesearch capability, which identifies active instances of a service on your network. You would use the search feature if you wanted to locate systems running DHCP servers, for instance. Finally, PsService works on both NT 4 and Windows 2000, whereas the Windows 2000 Resource Kit version of SC requires Windows 2000, and PsService doesn't require you to manually enter a "resume index" in order to obtain a complete listing of service information. Installation Copy PsService onto your executable path and type "psservice". Usage

The default behavior of PsService is to display the configured services (both running and stopped) on the local system. Entering a command on the command-line invokes a particular feature, and some commands accept options. Typing a command followed by "-?" displays information on the syntax for the command. usage: psservice [\\computer [-u username] [-p password]] <command> <options> -u -p query config setconfig start stop restart pause cont security depend find Specifies optional user name for login to remote computer. Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password. Displays the status of a service Displays the configuration of a service Specify the start type (auto, demand, disabled) of a service. Starts a service Stops a service Stops and then restarts a service Pauses a service Resumes a paused service Dumps the service's security descriptor Lists the services dependent on the one specified Searches the network for the specified service