Shell Basics
Shell Basics
REQUIREMENTS
Released 2/2000
Computer: IBM or 100% compatible
Processor: Intel Pentium 133 MHz or equivalent
Memory: 32 MB
Drives: 650 MB Disk space
CD-ROM / DVD drive
Sound:
Video: VGA or higher
Controls: Microsoft mouse / keyboard or compatible
Operating System: Requires Windows 95, 98 NT 3.5 or 4.0 for upgrade.
Direct X: Direct X 7.0
Other: NIC required for network installation
PROFESSIONAL
Windows 2000 Professional is the latest edition of the Microsoft Operating System series
for end-users. Windows 2000 is based of the Windows NT Kernel and is sometimes
referred to as Windows NT 5.0. Windows 2000 contains over 29 Million lines of code
mainly written in C++ 8 Million of those lines alone are written for drivers. Currently
Windows 2000 is currently by far one of the largest commercial projects ever built.
ADVANCED SERVER
Shell
1. A software interface that enables the user to interact with the computer. Some
examples of a shells are MS-DOS Shell, command.com, csh, ksh, and sh.
2. When referring to a script, a shell script is a type of script designed for a
particular type of shell.
Bourne shell
The Bourne shell was first developed by Steven Bourne at AT&T and is commonly using
for scripting. The Bourne shell is executed at the Linux or UNIX prompt by running the
bsh or sh command.
Korn shell
When referring to UNIX, Linux or one of the UNIX / Linux variants, Korn refers to a
shell used to navigate through the command line. If available, the user can execute the
Korn shell by typing ksh (k, for korn and sh for shell).
Additional information about Korn can be found on our ksh command page.
Kernel
When referring to a computer operating system the kernel is the first section of the
operating system to load into memory. The computer kernel can be responsible for one or
more of the following: disk drive management, interrupt handler, file management,
memory management, process management, etc..
Mach kernel
Mach was a project at the Carnegie-Mellon University that started in 1985 and ended
October 1994. While there is still some work being done at CMU, today most
development and support on the Mach Kernel is done elsewhere.
Safe mode
A software mode that enables users who use Microsoft Windows 95, Windows 98,
Windows ME, Windows 2000, and Windows XP users to enter safely into Windows and
correct any problems that may be preventing them from entering normal mode. What
makes safe mode different from normal mode is it uses Windows default drivers and
settings, this helps users correct issues so they can get back into normal mode. Safe mode
was first introduced in Microsoft Windows 95 and is available in all versions of
Microsoft Windows except Microsoft Windows 3.x, Windows NT 3.0, and Windows NT
4.0.
Security fixes are not WSE’s only concern. In fact, once a version of Windows is released to
manufacturing—or declared "golden"—the product team that developed it transfers the source code to
the group. WSE then has primary responsibility for any further work over the next seven years (the
supported life of the product), including hotfixes, security patches, updates (critical and noncritical),
security rollups, feature packs, and service packs. WSE is also central to Microsoft's efforts to improve
the patching process itself. (For definitions of these deliverables, see the chart "Sustained Engineering
Deliverables".)
Although it is primarily responsible for ongoing modifications, WSE does maintain links with the
product design team. All changes to the released code are reviewed by the appropriate developer
("buddy") on the core development team. Ideally, this developer was involved in writing the particular
area of code that is the subject of the WSE effort.
Although WSE uses a team and process similar to the Windows product group, it differs in how it
works on bugs and triages new problems. Rather than creating specifications and designs for new
features, WSE typically reviews any bug fixes that were postponed during the development process
and works with PSS and the Security Response Team to triage and fix new problems.
Triage includes understanding the problem, vulnerability, or bug; reproducing it; and then supplying a
fix. During this triage phase, WSE may create a "private" version of the fix for a customer to ensure
that the fix addresses the reported problem.
Once the problem is understood, a public fix will be developed and WSE will begin to build the patch
for all the required languages, versions, and installation types (e.g., full install versus upgrade).
Testing, which is performed across all languages and versions simultaneously, parallels the original
release testing and falls into three basic categories: depth, integration, and setup testing.
Depth testing. First, fixes are tested to ensure that the reported defect has indeed been fixed. In
addition, they are tested for functionality (the rest of the feature still works), security (the fix does not
create a new vulnerability), interoperability (a fix to a single feature does not break other features), and
code coverage (to ensure that all paths through the source code have been tested and that every
instance of the code was in fact fixed).
Integration testing. Second, WSE tests the entire product, including the fix, for application compatibility,
by using the product internally (self-hosting, or as Microsoft often calls it, "dogfooding"), stress testing
(running multiple applications and services simultaneously), long-haul testing (running test suites for
long durations without restarting), and performance and scalability testing.
Setup testing. Third, the fixed code is run through the full matrix of installation variations, such as new
installations and upgrades over existing versions.
Only service packs and feature packs receive the same full testing cycle that a released product
receives. The main difference in testing between a service pack and a hotfix is the number and
duration of the tests. Microsoft also runs service packs through a beta and release candidate process
similar to the process used for a new version of the product. This provides customer feedback and
exposure to hardware and software environments to which WSE might not have access. The full test
cycle for a service pack can take from six to nine months.
In contrast, the test cycle for a security patch (in the absence of an exploit) or critical update can take
five weeks, and a hotfix less than a week. The amount of testing that a security patch receives can
depend on when an exploit for the vulnerability starts to circulate. The more imminent the threat of an
exploit is, the shorter the testing cycle is likely to be.
In addition to delivering fixes, WSE is developing technologies that ease their deployment. Among
other initiatives, WSE is overseeing the effort to move Microsoft from eight to two patching
technologies—one for OSs and one for applications—and trying to reduce the overall size of patches
to improve the time it takes to download and install fixes and service packs.
WSE will face two big challenges in the future. First, Microsoft is putting a lot of focus on the next
release of Windows, code-named Longhorn. As the Windows development team works toward
releasing Windows, the WSE team could find it more challenging to support the current versions from
the continuing onslaught of security and other problems, such as requests to extend the functionality
or support new hardware—for example, the buddies who help develop and review changes will be
focusing on Longhorn work. The second challenge may come from reduced resources for WSE,
Microsoft is starting to put less money aside from the current sales of Windows and other products to
cover the costs of future support. This may be a natural consequence of the age of the products and
the efficiencies of the sustained engineering process, but it could also mean fewer resources for
support in the future.
Sustained
Engineering
Process
(Illustration)
Sustained engineering takes over support of a Windows version on the date the code is
"golden," or released to manufacturing. On that date, the source code is effectively split into three
parts: the gold code goes to manufacturing and is archived, sustained engineering begins on the
released version (Version n in the chart), and development begins on the next version (Version n+1).
Windows Sustained Engineering (WSE) is already supporting the previous version (Version n-1).
When a customer reports a problem via Product Support Services or a vulnerability is reported through
the Security Response Center, WSE helps triage the problem and then develops and tests the
appropriate hotfix, security patch, or update for release via Windows Update and inclusion in the next
service pack for that version.
WSE must also ensure that any change to the code to fix the problem or vulnerability is incorporated in
the next version and, if appropriate, in the next service pack for the previous version
Sustained
Engineering
Deliverables
(Chart)
Posted: Oct. 13, 2003
Security Patch Broadly released fix Yes Yes Limited depth and
to address a specific integration testing
security vulnerability (until exploit exists)