Question 1

In MS-DOS, which command sequence displays the contents of a text file one screen at a time, pausing after each screenful?

Accepted Answer

Introduction / Context: MS-DOS lacks a native paging viewer like UNIX's less, so technicians often combine built-in commands to examine long text files without flooding the screen. Understanding the standard pipeline for paging is important during troubleshooting and reviewing logs or configuration files in DOS environments. Given Data / Assumptions: The goal is to view a file with pagination. We are restricted to stock DOS commands. UNIX commands (e.g., cat, pg) are not present in plain DOS. Concept / Approach: TYPE outputs the contents of a file to standard output. MORE paginates text by pausing after each screenful. Piping the output of TYPE into MORE (TYPE filename | MORE) achieves page-by-page viewing. The options using CAT and pg are UNIX-style and not valid in DOS, and MORE filename alone does not read the file in MS-DOS; it expects input from STDIN or a pipe. Step-by-Step Solution: Choose a command to emit file contents: TYPE.Choose a command to paginate output: MORE.Combine using a pipe: TYPE filename | MORE.Verify that this pauses after each screenful and continues on keypress. Verification / Alternative check: Running TYPE CONFIG.SYS | MORE on a DOS machine demonstrates pagination, confirming the correct usage pattern. Why Other Options Are Wrong: CAT filename | MORE: CAT is not a DOS command. CAT filename | pg: both components are UNIX utilities. MORE filename: in DOS 6.x, MORE does not accept a filename parameter; it paginates piped input. None of the above: incorrect because a valid DOS pipeline exists. Common Pitfalls: Attempting to run UNIX pipelines verbatim in DOS. Forgetting to use the pipe so MORE has input to paginate. Final Answer: TYPE filename | MORE.

Question 2

In MS-DOS file organization, what are the named areas used to group and manage files on a disk called?

Accepted Answer

Introduction / Context: All operating systems impose a logical structure on storage media. In MS-DOS, the File Allocation Table (FAT) file system organizes files into hierarchical containers, enabling users to separate programs, data, and configuration files. Recognizing the correct term for these containers is foundational for navigation and command-line work. Given Data / Assumptions: We are referring to the standard FAT file system under DOS. Folders and directories are used interchangeably in later GUIs; DOS uses the term “directory.” No special or vendor-specific terminology is implied. Concept / Approach: A directory is a special file that lists names of files and subdirectories, along with metadata. Users create directories with MD/MKDIR, change into them with CD, list their contents with DIR, and remove them with RD (if empty). Terms like “buckets” or generic “areas” are not part of DOS terminology, and “area directories” is not a recognized phrase in DOS documentation. Step-by-Step Solution: Identify the FAT structure that groups files.Map the general idea of “folders” to the DOS term “directories.”Confirm that DOS commands (MD, CD, RD, DIR) target directories.Select “directories.” Verification / Alternative check: DOS manuals and DIR /S output show nested directory paths (e.g., C:\DOS\UTILS), establishing the canonical name and behavior. Why Other Options Are Wrong: buckets, areas, area directories: nonstandard terms absent from DOS command reference. None of the above: incorrect as “directories” is exactly right. Common Pitfalls: Confusing directory names with volume labels; they are different metadata. Assuming GUI “folders” imply different underlying structures—DOS still uses directories. Final Answer: directories.

Question 3

Which MS-DOS DIR option displays only file and directory names (bare format) without showing sizes, dates, or times?

Accepted Answer

Introduction / Context: The DIR command is the primary tool for listing files in MS-DOS. It supports several switches to control formatting and recursion. For scripting and quick checks, technicians often need a concise “bare” list of names only, without extra metadata that clutters output or complicates parsing. Given Data / Assumptions: The requirement is to display names only (no size, date, or time). Standard DOS 6.x syntax is assumed. We compare several common DIR switches. Concept / Approach: DIR /B produces “bare” listings—only names. DIR /W shows wide format but still includes header/footer information and is not as minimal as /B. DIR /S recurses into subdirectories, producing verbose output. DIR A: merely targets the A: drive and does not alter formatting. Thus, /B is the precise switch for name-only lists, useful in batch files and redirection to text files. Step-by-Step Solution: Identify the exact output requirement: names only.Map that requirement to known DIR switches: /B (bare).Exclude /W (wide but not bare), /S (recursive), and drive specifiers.Choose DIR/B. Verification / Alternative check: Running DIR /B > list.txt creates a clean list of names suitable for scripts, demonstrating the intended behavior. Why Other Options Are Wrong: DIR/W: omits details but still not “bare”; includes headings/columns. DIR A:: selects the A: drive; does not change format. DIR/S: verbose recursive listing. None of the above: incorrect because /B fits exactly. Common Pitfalls: Confusing /W for minimal output—it is for columns, not bare mode. Forgetting that /B removes headers and summaries, ideal for batch processing. Final Answer: DIR/B.

Question 4

While using the MS-DOS DIR command, which of the following switches is not supported in classic DOS 6.x for listing files?

Accepted Answer

Introduction / Context: MS-DOS and later Windows command interpreters share many switches, but some options were introduced after DOS 6.x. Identifying which switch belongs to later command processors (like Windows 95/98 or NT) prevents confusion when writing portable batch files for pure DOS environments. Given Data / Assumptions: We are considering classic MS-DOS 6.x behavior. DIR switches under review: /P, /W, /S, /T. Goal: find the one not supported in DOS 6.x. Concept / Approach: In MS-DOS 6.x: /P paginates one screen at a time; /W provides wide columns; /S recurses subdirectories. The /T switch, which selects which time field to display (creation, last access, last write), is a later addition primarily seen in Windows 95/98 DOS sessions and Windows NT/2000's CMD. Therefore, /T is the option not supported in classic DOS 6.x DIR. Step-by-Step Solution: List documented DOS 6.x switches for DIR.Confirm /P, /W, /S exist in DOS 6.x help.Recognize /T as a post-DOS extension.Select /T as not supported in classic DOS 6.x. Verification / Alternative check: On a DOS 6.22 system, DIR /? will list supported switches and omit /T, while Windows 9x/NT command prompts document /T with sub-options (C, A, W). Why Other Options Are Wrong: /P: supported; pauses per screen. /W: supported; wide listing. /S: supported; recursive listing. None of the above: incorrect because one unsupported switch exists (/T). Common Pitfalls: Assuming Windows CMD switches work in pure DOS batch scripts. Porting scripts between environments without checking DIR /? on the target OS. Final Answer: /T.

Question 5

In MS-DOS, which command undeletes a group of recently deleted files with the .DOC extension (just deleted in the current session)?

Accepted Answer

Introduction / Context: Before the Recycle Bin era, MS-DOS offered an UNDELETE utility that could restore files removed with DEL/ERASE under certain conditions. To recover multiple files sharing an extension (such as .DOC), technicians used wildcard patterns to target the desired set efficiently after accidental deletions. Given Data / Assumptions: The files were just deleted (cluster data likely intact). We are operating in the directory where deletions occurred. We want to restore all .DOC files at once. Concept / Approach: UNDELETE supports wildcard patterns. Using UNDELETE *.DOC instructs the utility to search the directory's FAT entries for deleted names ending with .DOC and attempt restoration. Plain UNDELETE may prompt file-by-file, while switches like /ALL or /LIST change behavior (restore all without prompting or list candidates), but the most direct and controlled method for a specific extension is the wildcard form. Step-by-Step Solution: Identify the need for bulk recovery by extension.Use wildcard syntax *.DOC with UNDELETE.Run the command in the directory where files were removed.Confirm restorations and verify file integrity. Verification / Alternative check: Running UNDELETE /? shows support for wildcards and options; tests on DOS 6.x demonstrate that UNDELETE *.DOC queues all matching entries for recovery when cluster data is still available. Why Other Options Are Wrong: UNDELETE (no pattern): may require individual selections; not explicit for .DOC group. UNDELETE/ALL: restores everything it finds—too broad and potentially unsafe. UNDELETE/LIST: lists candidates only; does not perform restoration. None of the above: incorrect because a correct wildcard solution exists. Common Pitfalls: Continuing to write to disk before recovery, which can overwrite deleted clusters. Forgetting that long filenames (VFAT) behavior differs in Windows 9x DOS sessions. Final Answer: UNDELETE *.DOC.

Question 6

In MS-DOS, which command customizes the command-line prompt so it can display information such as drive, path, or time?

Accepted Answer

Introduction / Context: The default DOS prompt (e.g., C:>) can be enhanced to show additional context like the current path, time, or special characters. This is helpful for administrators who navigate deep directory trees or maintain multiple drives. DOS provides a built-in command for defining the prompt's format string. Given Data / Assumptions: We are customizing the interactive shell prompt in COMMAND.COM. Need to include dynamic elements (drive, path, time). No third-party shells are assumed. Concept / Approach: The PROMPT command accepts format codes such as $P (current drive and path), $G (>), $T (current time), $D (date), and more. For example, PROMPT $P$G yields a prompt that displays the full path followed by >. This can be placed in AUTOEXEC.BAT for persistence. Other listed terms (windows, cursor, click) are not DOS commands for prompt customization. Step-by-Step Solution: Identify the DOS facility for customizing the shell prompt.Recall PROMPT syntax and format variables ($P, $G, $T, $D).Construct a desired string (e.g., PROMPT $T $P$G).Apply it interactively or in AUTOEXEC.BAT. Verification / Alternative check: Typing PROMPT /? lists all supported tokens, confirming how to display drive, path, time, and other context in the prompt line. Why Other Options Are Wrong: windows, cursor, click: not DOS configuration commands. None of the above: incorrect because PROMPT is correct and built-in. Common Pitfalls: Forgetting to escape special characters or include $G for the familiar > symbol. Not adding the PROMPT line to AUTOEXEC.BAT, causing settings to reset at reboot. Final Answer: prompt.

Question 7

In classic MS-DOS maintenance, which single command will both format a floppy disk in drive A: and transfer the DOS system files so that the disk becomes bootable?

Accepted Answer

Introduction / Context: Technicians working with legacy PCs and MS-DOS often need to create a bootable floppy disk for recovery or installation tasks. There are two related capabilities: formatting the media at the filesystem level and transferring the DOS system files plus a proper boot sector. This question tests whether you know the exact command that performs both operations in one step. Given Data / Assumptions: The target is a floppy disk in drive A: that may be blank or previously used. The PC is already booted into a working DOS environment. You want the result to be bootable with core system files present. Concept / Approach: MS-DOS offers two primary tools here. The FORMAT command creates a new filesystem on the disk and, with the correct switch, can also transfer system files and write a boot sector. The SYS command copies system files and updates the boot sector on an already formatted disk, but it does not perform a format. Therefore, if you need to accomplish both tasks in a single action, you choose FORMAT with the system switch. Step-by-Step Solution: Step 1: Insert a floppy into A: and ensure it is not write-protected.Step 2: Run the command: FORMAT A: /SStep 3: Allow DOS to complete low-level verification, create the filesystem, and copy system files (for example, IO.SYS, MSDOS.SYS, COMMAND.COM depending on version).Step 4: Label the disk if prompted and verify the completion message that indicates a system transfer. Verification / Alternative check: Boot the computer from the floppy. If the format and system transfer were successful, the machine reaches the DOS prompt from drive A:. Alternatively, list the disk contents to confirm that the expected system files are present and hidden attributes are set appropriately. Why Other Options Are Wrong: SYS A:: Transfers system files and writes a boot sector but does not format the disk. SYS C: A:: Syntax varies by DOS version; SYS is not a formatter. FORMAT A: /T: The /T switch relates to tracks; it does not copy system files. None of the above: Incorrect because FORMAT A: /S performs both tasks together. Common Pitfalls: Assuming SYS will also format, forgetting that hidden/system files may not show with a simple DIR, and using the wrong DOS version or incorrect switches that do not exist on that particular release. Final Answer: FORMAT A: /S

Question 8

You suspect a computer virus infection. Which of the following components is typically not directly affected or altered by a DOS-era file or boot-sector virus?

Accepted Answer

Introduction / Context: Classic DOS-era malware most commonly targeted executable files and boot records because those vectors let malicious code execute at startup or when launching programs. Understanding which components are normally impacted, and which are not, helps you triage symptoms and choose appropriate remediation steps like scanning media, rewriting a boot sector, or restoring clean program files. Given Data / Assumptions: Threat model: traditional DOS file infectors and boot-sector viruses. Storage includes hard drive boot sectors and removable floppy disks. System configuration data is stored in CMOS (nonvolatile memory powered by a battery). Concept / Approach: Boot-sector viruses alter the Master Boot Record or volume boot sector to gain control early in the boot sequence. File infectors attach to or replace COM/EXE files to execute when a program runs. Removable floppies can spread infection by carrying infected boot records or executables. In contrast, CMOS mainly stores hardware configuration values (for example, date, time, drive geometry) and is not the usual target for self-replicating DOS malware. While a minority of malicious programs might attempt to corrupt CMOS settings, that behavior is uncommon compared to file and boot vectors, and standard exam convention treats CMOS as the item not normally affected. Step-by-Step Solution: Step 1: Identify virus vectors most frequently used in the DOS era: boot records and executable files.Step 2: Recognize that removable media like floppies can propagate these infections.Step 3: Note that CMOS stores configuration, not executable content; it is rarely altered by typical viruses.Step 4: Conclude that CMOS is the least likely to be directly affected. Verification / Alternative check: Run an antivirus scanner that reports infected files and boot sectors. Observe that detections occur on COM/EXE files and boot records far more often than on CMOS settings. Resetting CMOS typically addresses configuration, not malware persistence. Why Other Options Are Wrong: Boot sector: Common infection point to gain pre-OS control. Floppy disks: Frequently carry infected boot sectors or files. Program files: File infectors specifically modify executables. None of the above: Incorrect because CMOS is generally unaffected. Common Pitfalls: Confusing CMOS corruption due to battery failure with virus behavior, and assuming that cleaning files will remove a boot-sector virus without rewriting the boot record. Final Answer: CMOS

Question 9

In MS-DOS display configuration, which MODE command sets a color display adapter to 40-column text mode with color enabled?

Accepted Answer

Introduction / Context: Early DOS systems allowed users to change the text mode characteristics of the display adapter from the command line. Color adapters could be configured for 40 or 80 columns, which influenced readability on televisions and early monitors. Knowing the precise syntax of the MODE command is essential for correctly setting the screen layout. Given Data / Assumptions: You are using a color display adapter compatible with DOS MODE settings. You specifically want a 40-column text layout (wider characters, fewer columns). You also want color output active. Concept / Approach: The MODE utility accepts parameters that select display width and color capabilities. The token "CO" denotes a color mode, and the numeric suffix indicates the column count. Thus, "MODE CO40" sets the adapter to a 40-column color configuration. Other strings such as "MODE COLOUR" or symbolic verbs like "MODE CHANGE" are not valid DOS syntax for this purpose, and switches like "/C" are unrelated to text-width configuration in classic DOS. Step-by-Step Solution: Step 1: Open the DOS prompt.Step 2: Enter the command: MODE CO40Step 3: Observe the display reinitialize into 40-column mode with color enabled.Step 4: If needed, switch back using MODE CO80 to return to standard 80-column text. Verification / Alternative check: Run MODE without arguments to display current settings, then toggle to MODE CO40 and again to MODE CO80 to confirm that the width and color settings are changing as expected. Why Other Options Are Wrong: MODE COLOUR: Not a recognized DOS parameter. MODE/C: Not the syntax for setting text columns and color. MODE CHANGE: Not a DOS command. None of the above: Incorrect because MODE CO40 is valid and correct. Common Pitfalls: Assuming every DOS version supports identical MODE arguments, ignoring that some shells echo minimal feedback after a mode change, and confusing color enablement with palette control, which is separate. Final Answer: MODE CO40

Question 10

In DOS startup troubleshooting, which single function key pressed during boot bypasses both CONFIG.SYS and AUTOEXEC.BAT so that drivers and TSRs do not load?

Accepted Answer

Introduction / Context: When a DOS system fails to boot cleanly due to a problematic driver or a terminate-and-stay-resident program, one of the fastest recovery techniques is to start without processing startup files. DOS provides a built-in keypress at boot time that skips both CONFIG.SYS and AUTOEXEC.BAT, enabling you to reach a minimal environment for diagnostics. Given Data / Assumptions: The machine is booting MS-DOS or a DOS-compatible environment. Startup files may contain drivers, memory managers, or TSRs that cause issues. You want a quick bypass without editing files on disk. Concept / Approach: Pressing F5 during the early DOS boot process instructs the loader to ignore CONFIG.SYS and AUTOEXEC.BAT entirely. By contrast, F8 initiates a step-by-step confirmation mode, prompting you for each line in the startup files so you can selectively accept or reject entries. Therefore, if the goal is a full bypass, F5 is the correct choice. Step-by-Step Solution: Step 1: Restart the machine and watch for the initial DOS loading message.Step 2: Press F5 promptly to bypass processing of both files.Step 3: Arrive at a clean command prompt with minimal drivers loaded.Step 4: Optionally run F8 on the next boot to pinpoint the specific offending line. Verification / Alternative check: Compare the device and TSR listings using MEM /C after a normal boot versus an F5 bypass boot. You should see far fewer loaded components in the bypassed session. Why Other Options Are Wrong: F8: Step-by-step confirmation, not a complete bypass. F4 / F1: Not assigned to this DOS boot function in standard releases. None of the above: Incorrect because F5 performs the bypass. Common Pitfalls: Pressing the key too late, assuming F8 will skip everything automatically, or forgetting that some DOS variants display only a brief window for key detection. Final Answer: F5

Question 11

After completing a low-level format on a hard disk, what is the correct next step when configuring the drive for MS-DOS usage before installing the operating system?

Accepted Answer

Introduction / Context: Legacy disk preparation follows a specific sequence. A low-level format initializes tracks and sectors at the controller level. Next you must define logical partitions so that a filesystem can later be created within each partition. Skipping or reordering these steps prevents the OS from recognizing usable volumes. Given Data / Assumptions: The drive has just undergone a low-level format (controller level initialization). You are preparing the disk for DOS or DOS-based Windows. Standard utilities like FDISK and FORMAT are available. Concept / Approach: The correct workflow is: 1) low-level format (rarely user-performed on IDE; historically on some controllers), 2) partition the disk with FDISK to create Primary and Extended partitions and Logical drives, 3) high-level format each created partition to build the filesystem, and 4) install the operating system onto a formatted partition. Therefore, immediately after a low-level format, the next required action is to partition the disk. Step-by-Step Solution: Step 1: Run FDISK to create the Primary DOS partition and optionally an Extended DOS partition with Logical drives.Step 2: Reboot if prompted so the partition table is re-read.Step 3: Use FORMAT C: (and others) to create filesystems on the new partitions.Step 4: Proceed to install the operating system on a formatted target. Verification / Alternative check: Entering FDISK /STATUS displays current partition structures. After partitioning but before formatting, the OS will list the partitions but they will not yet contain a filesystem; after high-level formatting, directory structures appear. Why Other Options Are Wrong: Format DOS partition: You cannot format a partition that has not yet been created. Install operating system: The installer requires a valid formatted partition. Configure DMA channel and back up interrupt: Not a standard disk-prep step for DOS disks. None of the above: Incorrect because partitioning is the proper next step. Common Pitfalls: Forgetting to make the Primary partition active, formatting the wrong drive letter, or assuming low-level formatting replaces the need for FDISK and FORMAT. Final Answer: Partition hard disk

Question 12

When executed from a bootable hard drive, which command correctly makes an already formatted floppy disk in drive A: bootable by transferring DOS system files and a boot sector?

Accepted Answer

Introduction / Context: To create a bootable floppy from an already formatted disk, you must transfer the DOS system files and write a compatible boot sector. Copying visible files alone is insufficient because the boot code lives in the boot sector and some system files may be hidden or require placement rules enforced by the utility designed for this purpose. Given Data / Assumptions: The disk in A: is already formatted. You are running from a working, bootable hard drive with DOS installed. Your goal is to make A: independently bootable. Concept / Approach: The SYS command copies the necessary system files (for example, IO.SYS, MSDOS.SYS, COMMAND.COM depending on DOS version) and updates the boot sector so that the machine can boot directly from A:. While FORMAT A: /S could accomplish both formatting and system transfer in one step, the prompt here specifies that the floppy is already formatted, so SYS A: is the most direct and correct choice. Step-by-Step Solution: Step 1: Insert the formatted floppy into drive A:.Step 2: At the DOS prompt, run: SYS A:Step 3: Wait for confirmation that system files were transferred and the boot sector was updated.Step 4: Test by booting from the floppy to confirm a DOS prompt on A: appears. Verification / Alternative check: List the floppy contents and note that essential system files are now present (some may be hidden). Attempting to boot validates that the boot sector and files are correct. Why Other Options Are Wrong: XCOPY C:\DOS\.* A:\: Copies many files but does not write the boot sector and may omit hidden system constraints. COPY C:\DOS\COMMAND.COM A:\: Copies only the command interpreter, not the full boot chain. ATTRIB C:\*.SYS A:\: Changes attributes; it does not create a bootable disk. None of the above: Incorrect because SYS A: is exactly the right tool. Common Pitfalls: Assuming that copying visible files makes media bootable, forgetting that some DOS versions place strict requirements on system file placement, and running SYS on an unformatted disk. Final Answer: SYS A:

Question 13

After attempting to unload a terminate-and-stay-resident (TSR) program, you receive an error that newer TSRs were loaded after it. Which command shows the current load order and memory allocation of resident programs and device drivers?

Accepted Answer

Introduction / Context: TSRs load into conventional or upper memory and remain resident, often in a Last-In, First-Out order. Unloading a TSR requires that no other TSRs loaded after it still depend on its services or occupy memory above it. DOS provides a memory reporting utility that can display resident programs and drivers so you can understand the load order before attempting removal. Given Data / Assumptions: You are working in a DOS environment where multiple TSRs and device drivers are present. An attempt to unload one TSR failed due to load order constraints. You need a built-in command to list memory consumers by name and type. Concept / Approach: The MEM command reports memory usage. With the /C switch, it provides a detailed breakdown of conventional and upper memory, including loaded TSRs and drivers, typically in the order they occupy memory. This helps identify which TSRs were loaded later and must be removed first. Other switches or tools either only paginate output or tune memory but do not show the needed allocation detail for immediate troubleshooting. Step-by-Step Solution: Step 1: At the prompt, run: MEM /CStep 2: Review the list of programs and drivers with their sizes and regions (for example, UMBs).Step 3: Determine the newest TSRs sitting above the target and plan the correct unload order.Step 4: Use each TSR's documented unload command in reverse load order when possible. Verification / Alternative check: After unloading the upper TSRs, run MEM /C again to confirm they are gone and that the original TSR can now be removed cleanly. Why Other Options Are Wrong: MEM /P: Adds paging to MEM output but does not specifically display the allocation breakdown you need alone. MEMMAKER: An optimizer that reconfigures memory; it is not a quick view of current TSR order. SYS:: Used to transfer system files; unrelated to memory listings. None of the above: Incorrect because MEM /C provides the correct listing. Common Pitfalls: Attempting to unload TSRs out of order, not recognizing device drivers that are not unloadable, and forgetting that some TSRs lack a safe unload capability. Final Answer: MEM /C

Question 14

In MS-DOS backup and recovery, which command restores files that were previously backed up using the DOS BACKUP utility?

Accepted Answer

Introduction / Context: Before integrated GUI backup tools, MS-DOS provided command-line utilities to copy selected files to backup media and later recover them. Correctly pairing the backup and restore utilities is important because metadata, selection criteria, and archive formats must match to ensure complete recovery of the protected files. Given Data / Assumptions: You have a set of files backed up using the BACKUP command. You need to recover these files to their original or specified directories. You are operating in a standard DOS environment with the DOS utilities available. Concept / Approach: The RESTORE command is the companion to BACKUP. It reads the backup set, interprets the archive structure, and rewrites the files to the target path, preserving attributes as supported by the DOS version. Using generic copy tools does not interpret the backup format; they only duplicate raw files or disks and therefore cannot unpack the BACKUP archive correctly. Step-by-Step Solution: Step 1: Insert the media or navigate to the location containing the BACKUP archive.Step 2: Run RESTORE with appropriate parameters (for example, RESTORE A: C:\ /S) according to your DOS version.Step 3: Confirm the list of files to be restored and proceed.Step 4: Verify restored files with DIR and optional integrity checks. Verification / Alternative check: Attempting to access files directly from the backup media without RESTORE typically fails to recreate the original directory structure and attributes, underscoring the need for the paired RESTORE utility. Why Other Options Are Wrong: COPY: Copies individual files; it does not parse a BACKUP archive. DISKCOPY: Clones entire diskettes sector by sector, not BACKUP sets. STORE: Not the standard DOS recovery command name. None of the above: Incorrect because RESTORE is the dedicated tool. Common Pitfalls: Restoring to the wrong path, omitting switches for subdirectories, and overwriting newer files unintentionally by not checking timestamps and options. Final Answer: RESTORE

Question 15

What is the scope of the MS-DOS MODE command: which device-related tasks can it perform on a typical DOS system?

Accepted Answer

Introduction / Context: The MS-DOS MODE utility is a versatile command used to view and adjust settings for several device classes, notably displays, serial ports, and printers. Knowing the breadth of MODE helps troubleshoot character widths, baud rates, and printer redirection without third-party tools, especially on minimal boot disks or recovery environments. Given Data / Assumptions: You are working in an MS-DOS shell with MODE available. Your system includes a text-mode display, COM/LPT ports, and possibly attached printers. You need to either view current configurations or change them. Concept / Approach: MODE can query and configure multiple device aspects. For displays, it can change text columns (for example, MODE CO80, MODE CO40). For printers and LPT ports, it can set code pages, select devices, and redirect output. For serial ports, it can set parameters such as baud rate, parity, data bits, and stop bits and show current statuses. Consequently, the comprehensive answer that captures MODE's range is that it can both display information and provide control across these device types. Step-by-Step Solution: Step 1: Use MODE without parameters to show summaries of supported devices on your system.Step 2: Adjust display width with commands like MODE CO80 or MODE CO40.Step 3: Configure serial ports, for example, MODE COM1:9600,N,8,1.Step 4: Manage printers by directing output to LPT ports or changing settings as required. Verification / Alternative check: After issuing a MODE change, run MODE or an appropriate command again to confirm the updated state (for example, a new baud rate on COM1 or a shift to 40 columns on the display). Why Other Options Are Wrong: Display information only: Too narrow; MODE also configures devices. Control printers only: Ignores display and serial configuration capabilities. Change display only: Ignores printer and serial features. None of the above: Incorrect because MODE handles all of the listed areas. Common Pitfalls: Assuming MODE affects graphics modes or mouse settings, misusing regional code page options, and forgetting that different DOS versions may expose slightly different MODE features. Final Answer: All of the above

Question 16

In MS-DOS disk setup, which command-line switch makes FDISK display the current partition status of your hard disk without invoking interactive changes or writing anything?

Accepted Answer

Introduction / Context: FDISK is the classic DOS tool for creating and managing disk partitions. Sometimes you need a safe, read-only look at the existing partition map to document the layout or confirm active partitions without risk of altering anything. DOS provides a simple switch to print the status and then exit immediately. Given Data / Assumptions: You are using MS-DOS or a DOS-compatible FDISK utility. Your goal is to view partition information only, not to make changes. You prefer a single, noninteractive command that exits after display. Concept / Approach: Running FDISK with the /STATUS switch outputs the partition table details, such as drive letter assignments (if applicable), partition types, sizes, and which primary partition is marked active. It then returns to the command prompt without entering the interactive partitioning menu, thereby avoiding any chance of accidental modification. Step-by-Step Solution: Step 1: At the DOS prompt, type: FDISK /STATUSStep 2: Read the printed summary of primary, extended, and logical partitions along with their sizes and active flags.Step 3: Record the information for planning or troubleshooting.Step 4: Exit occurs automatically; no changes are made. Verification / Alternative check: Compare FDISK /STATUS output to the information shown by other tools, such as the BIOS setup or third-party partition viewers, to confirm consistency in partition sizes and the active flag. Why Other Options Are Wrong: /display and /show: Not standard switches for the DOS FDISK utility. /part: Not a recognized read-only option in classic DOS. None of the above: Incorrect because /STATUS is the documented switch for this purpose. Common Pitfalls: Running FDISK without the switch and entering the interactive tool unintentionally, or misreading cylinder-based size displays common in older utilities. Final Answer: /status

Question 17

In legacy MS-DOS memory management, where are Upper Memory Blocks (UMBs) located within the PC's address space?

Accepted Answer

Introduction / Context: Understanding the classic IBM PC memory map is essential for configuring DOS-era systems and troubleshooting legacy software. Upper Memory Blocks (UMBs) were a key optimization in MS-DOS to free precious conventional memory for applications by loading drivers and TSRs high. Knowing where UMBs reside helps explain HIMEM.SYS/EMM386.EXE configuration and why some drivers can be loaded with DEVICEHIGH or LOADHIGH. Given Data / Assumptions: Environment: DOS/real-mode memory map. Conventional memory spans 0 to 640 KB. The address space between 640 KB and 1 MB is often called the Upper Memory Area (UMA). Concept / Approach: The PC's first 1 MB address space is split into conventional memory (0–640 KB) and the UMA (640 KB–1 MB). The UMA is largely reserved for BIOS ROMs, video memory, and adapter ROMs. Memory managers (e.g., EMM386) can reclaim unused holes in this reserved region as Upper Memory Blocks, creating allocatable chunks where drivers/TSRs can be loaded “high.” Therefore, UMBs are carved from the reserved region, not from extended (XMS) or expanded (EMS) directly, although managers may map XMS into UMA holes. Step-by-Step Solution: Identify UMA range: 640 KB–1 MB.Recognize this area is reserved for ROMs and device memory.Memory managers map available UMA holes into UMBs.Hence, UMBs reside in the reserved memory area. Verification / Alternative check: Examining MEM /C /P output on DOS shows UMB regions located between segment A000 and F000, confirming their placement in the reserved portion above 640 KB. Why Other Options Are Wrong: Conventional Memory: 0–640 KB; UMBs are not here. Extended Memory: memory above 1 MB (XMS), not where UMBs physically reside. Expanded memory: EMS is a paging scheme via a page frame, conceptually different from UMB placement. None of the above: incorrect because “Reserved Memory” is correct. Common Pitfalls: Confusing EMS (expanded) with UMBs because both involve memory managers. Assuming UMBs are the same as extended memory; they are mapped within UMA. Final Answer: Reserved Memory.

Question 18

In DOS-based systems, what does the acronym TSR stand for, and what does it describe?

Accepted Answer

Introduction / Context: Before preemptive multitasking became ubiquitous, MS-DOS used small utilities that could remain in memory after execution to offer background services like key macros, print spooling, or clocks. These were commonly called TSRs. Knowing what TSR stands for and how it behaves is foundational for tuning legacy systems and avoiding memory conflicts. Given Data / Assumptions: DOS environment with real-mode memory limitations. Programs may need to remain resident to provide hotkeys or asynchronous services. The question asks for the meaning of the acronym and its concept. Concept / Approach: TSR stands for terminate and stay resident program. Unlike regular programs that exit and fully relinquish memory, a TSR returns control to DOS but keeps a portion of itself loaded in memory, usually hooking interrupts (e.g., INT 9 keyboard) to provide on-demand features. Because conventional memory is scarce, TSRs often load high into UMBs when possible to conserve base memory. Step-by-Step Solution: Identify the expansion of TSR.Recall its behavior: partial termination while remaining in memory.Associate with DOS interrupt hooking for background functionality.Select the option that exactly states this expansion. Verification / Alternative check: Classic examples include DOSKEY (command history) and various popup utilities that load and remain in memory after initial execution, verifying the concept of “stay resident.” Why Other Options Are Wrong: Other expansions are fabricated phrases unrelated to DOS architecture. They do not capture the semantics of staying resident after termination. Common Pitfalls: Loading too many TSRs causing “Out of memory” errors. Interrupt conflicts when multiple TSRs hook the same vectors improperly. Final Answer: terminate and stay resident program.

Question 19

In DOS startup configuration, which file contains commands that configure system devices and drivers during boot?

Accepted Answer

Introduction / Context: Classic DOS systems relied on two key startup files: CONFIG.SYS and AUTOEXEC.BAT. Understanding their roles is critical for loading device drivers, setting buffers, and preparing the environment for applications. This distinguishes kernel-level configuration from user-level initialization scripts. Given Data / Assumptions: Platform: MS-DOS 5/6 era. Goal: identify the file that configures devices/drivers at boot. Typical entries include DEVICE, DEVICEHIGH, FILES, BUFFERS, LASTDRIVE. Concept / Approach: CONFIG.SYS is processed by DOS during boot to load low-level device drivers (e.g., HIMEM.SYS, EMM386.EXE, OAKCDROM.SYS) and set kernel parameters. AUTOEXEC.BAT runs afterward to set environment variables and start TSRs. COMMAND.COM is the command interpreter itself, not the configuration file. WIN.INI applies to Windows 3.x/9x, not pure DOS hardware configuration. Step-by-Step Solution: Recall boot order: IO.SYS > MSDOS.SYS > CONFIG.SYS > COMMAND.COM > AUTOEXEC.BAT.Identify which stage loads device drivers and sets kernel options.CONFIG.SYS performs device configuration.Select CONFIG.SYS. Verification / Alternative check: Typical line: DEVICEHIGH=C:\DOS\OAKCDROM.SYS /D:MSCD001 confirms CONFIG.SYS's role in device setup prior to the command interpreter launching. Why Other Options Are Wrong: Command.com: the shell, not a config script. Autoexec.bat: user-level initialization after CONFIG.SYS. Win.ini: Windows-specific, not DOS hardware drivers. None of the above: incorrect because CONFIG.SYS is correct. Common Pitfalls: Placing DEVICE lines in AUTOEXEC.BAT—drivers won't load properly. Forgetting DEVICEHIGH to conserve conventional memory. Final Answer: Config.sys.

Question 20

After upgrading to a newer DOS version, an older application reports “Incorrect DOS version.” What should you do to run the application successfully?

Accepted Answer

Introduction / Context: Many DOS programs perform a simple version check and refuse to run if the reported DOS version is unexpected. Reverting the OS is overkill; DOS provides a built-in way to control the version string reported to specific executables so legacy software remains compatible after upgrades. Given Data / Assumptions: System has been upgraded to a newer DOS (e.g., 6.22). Legacy app expects an older version (e.g., 5.0). Goal: run the app without downgrading the whole system. Concept / Approach: SETVER.EXE maintains a version table used by DOS to report an alternate version to specified programs. By adding the program to the SETVER table with the expected version, the app's version check passes. Typically SETVER is loaded in CONFIG.SYS (or referenced in AUTOEXEC) so the mapping is active on boot. Step-by-Step Solution: Load SETVER (e.g., DEVICE=C:\DOS\SETVER.EXE in CONFIG.SYS).Add an entry: SETVER APP.EXE 5.00 (example version expected).Reboot if necessary to activate the mapping.Run the legacy application successfully. Verification / Alternative check: Running SETVER without arguments lists current mappings; you can confirm the app's filename and version override are present. Why Other Options Are Wrong: DOS+: not a standard DOS command. Restore the old DOS version: unnecessary and risky; SETVER is safer. Contact vendor: not required for a simple version check issue. None of the above: incorrect; SETVER is the right tool. Common Pitfalls: Forgetting exact executable name; mapping must match the filename. Not loading SETVER so the table is inactive at runtime. Final Answer: Use the SETVER command.

Disk Operating System (DOS) Questions