CSS 360 E

Lecture 15

Arkady Retik aretik@uw.edu

<End of Quarter Learning> $ diff student.* programmer.*
Season of Testing
 TODAY’S CONTENT
1. Test 2

2. SwE topics

3. DEVELOPING, MANAGING, & RELEASING CODE

• Thu – no class; Thanksgiving

Next week

• Project 2 ; Case Study 2; Activity 5 => POGIL in class

• Tu -- Refresh: Chapter 8 Software Testing

=================================
Your Last Quiz 3 will be week 10

❖ QUIZ 3: ~12-15 mins – canvas based => multiple choice mainly

REFRESH | continue from L14
Software development
 Open Source Development
Open-source software (OSS) is a type of computer software whose source code is released under a license in
which the copyright holder grants users the rights to study, change, and distribute the software to anyone
and for any purpose (from Wikipedia).

▪ Community software development

▪ Collaboration among paid and unpaid developers
▪ Often used a source of software for custom, embedded, or
web service development
▪ OSS – Open Source Software
▪ FOSS – Free and Open Source Software
Open Source Development: References
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses

Distinguish between OSS and FOSS (by Free Software Foundation)

https://opensource.org/ https://www.fsf.org/

GPL 3 is viral / copyleft

Software Engineering Topics

Portions taken and adapted from M. Kochanski, HazelineA I. Sommerville, Software Engineering
SWEBOK
▪ Software Engineering Body of Knowledge (SWEBOK)

www.swebok.org

▪ Describes the knowledge areas that comprise all of the

concepts, methods, and practices related to software
engineering

Note: we often use :

▪ SW (sw) for software
▪ SwE for Software Engineering
V3: updated 2014

V3 Copy is posted for

your edu/ individual
use only
Knowledge Areas (KAs) & Related Disciplines

Guide to SwE Body of Knowledge

DEVELOPING, MANAGING, & RELEASING CODE

Partially adapted from M. Kochanski and H. Asuncion

Development
Development: Pair Programming
▪ Two people work together on a computer

• Driver – person typing the code or recording the design

• Navigator – person watching the work of the driver, asks

clarifying questions and makes suggestions

• Roles can be switched from time to time

 Development: IDEs
▪ Integrated Development Environments

▪ Source code editors

▪ Compilers, linkers, and other make tools

▪ Interactive debuggers

▪ Static analysis tools (metrics)

▪ Team management tools

Managing Code & the Release Process

Builds
Version
And
Control
Staging

Management
Processes

Release Setup and

Management Installation
Configuration Management
▪ Means of managing changing artifacts over the course of
the software development lifecycle

▪ Aka Version Control

▪ Here’s an overview: Watch at

home

▪ http://softwareconfidence.com/?p=25

▪ The next slides cover definitions
GitHub provides hosting for software
development and version control using Git. It
offers the distributed version control and
source code management functionality of Git,
plus its own features.
Baseline
▪ A complete set of items that comprises an official version
▪ Note: You are unlikely to start from Null / scratch……

▪ A major starting point for additional development

X
Req
Spec
v1.50
Test Cases and Design Documents User Manuals &
Test Results v1.3 v1.02 Help Files v1.5
Java
package X Component Y Library Z v1.5
v1.23 v2.2

Configuration Each item is a software

File A v1.2 configuration item
 Version
• Incremental change from the baseline

• Always has a unique identifier, which is

often the configuration item plus a version
number
Common Version Names

• bb.vv.pp 10.3.124
• bb (date) 8 (02/03/03)
• bb (build sequence) 10 (4569)
• code name baker

Where bb = baseline, vv=version, pp=patch

 Common Version Names

• EXAMPLES?
Android
Wikipedia 2018
CASE STUDY
sources
Wikipedia 2017
 Workspace, Check-in & Check-out
▪ Workspace (work station, dev machine, dev server, etc)
▪ a private work area where software can be modified without
affecting other developers who may be using or modifying that
software. Contains the working copy of the code

▪ Check-in – also known as commit

▪ When a developer saves the local workspace to the CM system

▪ Check-out
▪ when a developer gets the latest version from the CM system and
saves it to the local workspace
Workspace, Check-in & Check-out

▪ Both are checking-in the same code, C

▪ To avoid overwriting each other’s changes, the version control system informs them of the
conflict and they can either
▪ examine the conflicts manually
▪ create a new branch and merge later
Branching and Merging
• Branching – the creation of a codeline (a version
line) that allows for parallel development
• Merging – the creation of a codeline by merging
two versions from different version lines
 $ diff baseline codeline

Base product content

Steps toward release
1. Build
▪ Source code and scripts required to create deliverables

2. Staging
▪ A controlled set of deliverables appropriate for use with a given environment

3. Release
▪ Set of production or “stable” deliverables
1. Builds
▪ Builds are the processes of creating
deliverables (usually for a release)

▪ The build process is usually at least partially

automated– “make” files and IDE scripts

▪ There are often separate “development”

builds and “team” builds
2. Staging
• Managing and using builds for use within different “environments”
• Testing a build against a specific environment

• Staging may involve different platforms (hardware, o/s, etc.)

• Examples of staging environments include:

• Individual developer “builds”
• Periodic (daily) team builds
• Alpha / beta test builds
• Released builds
Example of Staging
Could include symbols for
debugging – aka ‘checked’ builds

Could be a localized
build, or specific
Developer installation testing
Changing
Version 2.6
Tester

Controlled
Version 2.5

Version Controlled
Control Version 2.0
Documents
User
 Daily Build and Smoke Tests
▪ A staged build created from currently
checked-in source code for a team
▪ Scheduled daily or at least periodically

▪ Scripted or otherwise automated build instead of interactively built

▪ Incorporates automated testing (smoke tests)

▪ The smoke test should exercise the entire system from end to end.
▪ It does not have to be exhaustive, but it should be capable of exposing major
problems.

BVT ( Build Verification Testing) = ‘Smoke Testing’

 Daily Build and Smoke Tests: goals and benefits
▪ Forces integration early and often in the software process

▪ Reduces the introduction of new bugs in tested areas

▪ Provides a project build for internal usage, testing, and quality assurance

▪ Demonstrates forward progress on development

 3. Release Management

▪ Identifies and manages “stable” builds of deliverables for the “project”

▪ Release management applies to each phase and the development

effort as well as the deployed deliverables

▪ Releases are coordinated with the creation of setup and installation

scripts or process

Release for Testing; Release Candidate (RC1; RC2, …); Alpha Release, Beta Release ….
Release for Testing; Release Candidate (RC1; RC2, …); Alpha Release, Beta Release ….
 Release Decision Making
▪ To release is most important decision associated with software development

▪ Many factors to consider

▪ Market

▪ Infrastructure

▪ Technical Support

▪ Quality of Software

▪ Reputation

▪ Developers only part of the decision Example: Releasing WMIC

Bug conversion
Setup and Installation
▪ Involves the packaging and delivery of deliverables to
deploy in an operational environment

▪ Usually involves the setup scripts and archives in

conjunction with configuration and migration utilities

▪ Common CASE tools include archiving like “tar” and “zip”

1 mins
and installation tools like Installshield, VISE, and related
How many different
types of installation do
products you know?
Attended installation
Silent installation
Unattended installation
Headless installation
Scheduled or automated installation Image-based installation (*.wim; *.iso)
Clean installation
A clean installation is one that is done in the absence of any interfering elements such as old versions of the
computer program being installed or leftovers from a previous installation. In particular, the clean installation of an
operating system is an installation in which the target disk partition is erased before installation. Since the interfering
elements are absent, a clean installation may succeed where an unclean installation may fail or may take
significantly longer.
Network installation
Network installation, shortened netinstall, is an installation of a program from a shared network resource that may
be done by installing a minimal system before proceeding to download further packages over the network. This may
simply be a copy of the original media but software publishers which offer site licenses for institutional customers
may provide a version intended for installation over a network.
 Review and Summary

Management process
1. Configuration management or version control
2. Builds and staging
3. Release
4. Setup and installation

Let’s see all these stages again by

revisiting our Windows case study:
 WINDOWS BUILDING CASE STUDY:
“ONE OF THE LARGEST SOFTWARE ENGINEERING PROJECTS EVER”

based on the presentation by Dr. Jim Allchin,

Co-president of the Platforms and Services Division,

Microsoft, 2009

(edits and additions by Dr. A. Retik)

 15 unique SKUs in 100+ languages
~ 1000 OEM model families
~2M unique devices
~1.5M devices supported out of the box
Widest array of applications on any platform
… and an installed base of 600M users*
*Source: Worldwide Windows Client Operating Environments 2005-2009 Forecast and Analysis: Steady Growth Expands
Windows COE Market Opportunities, Sep 2005, Doc #34002, IDC

One Code Base

Several thousand software & test engineers

1:1 ratio of testers to developers

Down from 2:1 in Windows 2000

1,600,715 files across 156,593 directories

Client enlistment requires 120 GB disk space

55% of this is test code

Backward compatibility (s/w, h/w)
Interoperability and migration
Industry standards
Accessibility
International character sets, conventions, and geo-political
sensitivities
Government-mandated security standards and practices
Partners: OEM, device, software, retail, consulting, systems
integration…
 How do you scale an
engineering process as the
size of its code and of its test
matrix grows?
Automation
Quality
Get it right the first time by detecting problems earlier
Harness computing power for testing
Agility
Improve efficiency through automation
Reduce unnecessary code dependencies, allowing for
componentization

“For some things, machines are better than humans”

During each phase of the engineering process,
automated tools help identify and correct coding
errors, in numerous cases preventing them from
ever reaching the master copy of the code base
(WINMAIN).
Gather feedback from customers
via instrumentation, online hangs/crashes, security
forums, OEMs, newsgroups, chats, customer meetings
Gather feedback on HW/SW trends
Secure development
Plan key feature set
Write specifications, threat models, etc.
Determine order and timing of feature integration
8 Aggregation Branches VBLs (Virtual Build Labs)
300 Feature Branches, nested up to a depth of 6
Thousands of Developer Desktops
Quality Gates
Architecture, performance, code quality tests
Developers must pass Quality Gates and verify results
before check in to their feature branch
Feature Branches and Aggregation Branches
must also pass Quality Gates to check into the
levels above them
Quality Gates more stringent at higher levels
Scan code for errors, e.g. buffer overruns
Identify and replace calls to banned APIs
Specify and check function interfaces
Enforce managed code guidelines
Enforce architectural layering
Reverse Integration: Moving code up the build tree toward
WINMAIN
Forward Integration: Moving code down the build tree from
WINMAIN
11,000+ files churn (add, change, delete) each day
313,000 lines of code churned in Feature Branches
200,000 lines of code RI’d into Winmain
On average, each Aggregation Branch (VBL) integrates into
WINMAIN once per week
 Nine builds per image*
Retail, debug, and test binaries
x86, ia64, x64 (AMD 64) architectures
20 – 35 language versions assembled each day
Retail binaries + PID key determines SKU

* image (set of binaries) is used to produce different SKUs

 Accept integrations from VBLs into WINMAIN (during day)

Scorch/revert, sync the 9 build machines (7pm)

Compile and link (classic "build")

Binary processing

Code signing

Language-specific build tasks

Packaging an installable image

Setup and BOOT/BVT testing (launches automatically)

SKU/Language Creation

ISO creation and verification (both in VPC and on physical machines)

Propagation to domestic and international release shares (around 3-4pm)

Hardware Requirements
8-way (4-proc dual core) AMD64 machines (HP DL585)
with 16 GB RAM
One Build Verification (BVT) pass consumes ~7 machines
for 4-6 hours
A daily WINMAIN build over multiple types/languages
consumes 100+ machines
Developers can access build resources from a pool of
1000+ machines
Perform global static analysis on entire product
detects buffer overruns; memory access violations; resource
usage; security exploits; deadlocks
Categorize and diagnose Dr. Watson (crash) failures
Fuzz test parsers of common file formats
Use Post-facto analysis of execution traces to detect
memory leaks and race conditions
Automated white box tests run to capture any bugs
that quality gates and verification tests did not catch
WTT: Windows Test Technology
6.8 million automated test cases for Windows Vista that
run on 33,000 test machines
~2.5 million of these tests run each week
150 servers support 100 databases of test cases and
results. Storage: 5.5 petabytes.
Unified Stress Tools run on individual machines
and labs that are not in use.
UST customizes a set of tests to push each machine to
its limit (CPU, memory, IO, graphics processor, etc.).
Run-time verification tests look for:
heap corruption low resource impacts
invalid handles lock problems in
exception handling critical sections
issues privilege problems
Stress: since Windows Vista Beta 1:
171,000 stress test runs have completing, averaging 1,000 machines
per day near each milestone
7.4 million hours of stress tests have run
Stress testing has identified 3,200 bugs that might otherwise have
been missed. 98% have already been fixed.
We have found and fixed 1,500 Windows Vista bugs so far
using run-time tools, which are freely available to third parties.
Scenario Testing
Usability labs, deployment, etc.

Penetration testing

Tech Betas, CTPs, Broad CPP

 After the project becomes “code complete,”
new feature work stops, testing continues, and
the feature teams triage and track bugs until
the code quality reaches the standards for
Release to Manufacturing (RTM)
Accessibility Server Performance
Application Experience Privacy
Compliance Reliability
Deployment Security
Devices Just Work Serviceability
Manageability Single WW Binary
Client Performance Usability
Accessibility Server Performance
Application Experience Privacy
Compliance Reliability
Deployment Security
Devices Just Work Serviceability
Manageability Single WW Binary
Client Performance Usability
 Requirements Analysis

A lot of testing
Design: happening during
Architecture -> Detailed Design the Implementation

To implement design, we Implementation

also need to understand
what our ‘product’ will look Test
like and/or what our
business model is. Next is actually
developing, managing and
building the system so it
could be tested Software Product or Service
Code complete
 Testing Phase: intro
▪ Nature of testing:
“Program testing can be used to show
the presence of bugs, but never to
show their absence” [Dijkstra]

Here’s a photo of what may be the first computer bug

An error was traced to a moth trapped in the computer circuitry

http://en.wikipedia.org/wiki/Software_bugs

Edsger W. Dijkstra (1930- 2002): one of the most influential computer scientist
Software Testing Terms

Software
Failure!

or other software artifact.

Error (bug)
 Software Testing Terms
Defect: Commonly refers to several troubles with the software products, with its external behavior or
with its internal features. Can be:.
• Failure
The incapacity of a system to conduct its required functions within clarified performance
requirements.
• Fault
A false, wrong step, process or data definition in a software product.
• Error
A person act that generates an erroneous result.

All are referred to as ‘bugs’; while ‘faults’ is also used to represent all three. .
 Programming Errors

Syntax errors Logic Errors

Run-time errors Logic Errors
(Grammar) (Semantics) (Semantics)

▪ Compiler will always ▪ Detected when your ▪ When your program

detect syntax error but program is run; it will compiles without error,
not what’s wrong inputs an error you are still not done.
▪ Compiler is not good message ▪ You have to test the
telling where the real ▪ The error messages program to make sure
error in case of may not be easy to it works correctly.
multiple errors understand
 Testing

• Verification & Validation

• Focus what we test and process

• Defect Testing
• Focus on how we test and
techniques

Portions taken and adapted from M. Kochanski, H. Asuncion, Sommerville, I., Software Engineering 10th edition,
Pressman, R. Software Engineering A Practitioner’s Approach
VERIFICATION & VALIDATION (V&V)
Three Stages

I. Development testing
▪ Plan-driven development
▪ Test-driven development
II. Release testing
III.User testing
VERIFICATION & VALIDATION (V&V)
 I. Development testing
Development testing includes all testing activities that are carried out by the team developing the system.

There are three types of development testing:

1. Unit testing, where individual program units or object classes are tested. Unit testing should

focus on testing the functionality of objects or methods.

2. Component (integration) testing, where several individual units are integrated to create

composite components. Component testing should focus on testing component interfaces.

3. System testing, where some or all of the components in a system are integrated and the system

is tested as a whole. System testing should focus on testing component interactions.

 1. Unit testing

▪ Unit testing is the process of testing individual

components in isolation.

▪ It is a defect testing process.

▪ Units may be:

▪ Individual functions or methods within an object

▪ Object classes with several attributes and

methods

▪ Composite components with defined interfaces

used to access their functionality.
Object class testing
▪ Complete test coverage of a class involves

▪ Testing all operations associated with an object

▪ Setting and interrogating all object attributes

▪ Exercising the object in all possible states.

▪ Inheritance makes it more difficult to design object class tests as the

information to be tested is not localised.
Automated testing
▪ Whenever possible, unit testing should be automated so that tests are run and checked
without manual intervention.

▪ In automated unit testing, you make use of a test automation framework (such as JUnit) to
write and run your program tests.

▪ Unit testing frameworks provide generic test classes that you extend to create specific test
cases. They can then run all of the tests that you have implemented and report, often through
some GUI, on the success of otherwise of the tests.
 Choosing unit test cases
▪ The test cases should show that, when used as expected, the component that
you are testing does what it is supposed to do.
▪ If there are defects in the component, these should be revealed by test
cases.
▪ This leads to 2 types of unit test cases:
▪ The first of these should reflect normal operation of a program and
should show that the component works as expected.
▪ The other kind of test case should be based on testing experience of
where common problems arise. It should use abnormal inputs to check
that these are properly processed and do not crash the component.
 Testing strategies

▪ Partition testing, where you identify groups of inputs that have

common characteristics and should be processed in the same way.

▪ You should choose tests from within each of these groups.

▪ Guideline-based testing, where you use testing guidelines to

choose test cases.

▪ These guidelines reflect previous experience of the kinds of

errors that programmers often make when developing

components. i.e. loops; arrays

off by 1
 2. Component testing
▪ Software components are often composite components that are made up of several
interacting objects.

▪ For example, in the weather station system, the reconfiguration component includes
objects that deal with each aspect of the reconfiguration.

▪ You access the functionality of these objects through the defined component interface.

▪ Testing composite components should therefore focus on showing that the component
interface behaves according to its specification.

▪ You can assume that unit tests on the individual objects within the component have
been completed.

STABS
 Interface testing
▪ Objectives are to detect faults due to interface errors or invalid assumptions about
interfaces.

▪ Interface types
▪ Parameter interfaces

▪ Data passed from one method or procedure to another.

▪ Shared memory interfaces

▪ Block of memory is shared between procedures or functions.

▪ Procedural interfaces

▪ Sub-system encapsulates a set of procedures to be called by other sub-systems.

▪ Message passing interfaces

▪ Sub-systems request services from other sub-systems

Interface testing guidelines

▪ Design tests so that parameters to a called procedure are at

the extreme ends of their ranges.

▪ Always test pointer parameters with null pointers.

▪ Design tests which cause the component to fail.

▪ Use stress testing in message passing systems.

▪ In shared memory systems, vary the order in which

components are activated.

3. System testing
▪ System testing during development involves integrating components to

create a version of the system and then testing the integrated system.

▪ The focus in system testing is testing the interactions between components.

▪ System testing checks that components are compatible, interact correctly and

transfer the right data at the right time across their interfaces.

▪ System testing tests the emergent behavior of a system.

Program testing goals

▪ To demonstrate to the developer and the customer that the software meets its requirements.

▪ For custom software, this means that there should be at least one test for every requirement in

the requirements document. validation

▪ For generic software products, it means that there should be tests for all of the system

features, plus combinations of these features, that will be incorporated in the product release.

▪ To discover situations in which the behavior of the software is incorrect, undesirable or does not

conform to its specification.

▪ Defect testing is concerned with rooting out undesirable system behavior such as system
verification
crashes, unwanted interactions with other systems, incorrect computations and data

corruption.
 Requirements Analysis

A lot of testing
Design: happening during
Architecture -> Detailed Design the Implementation

To implement design, we Implementation

also need to understand
what our ‘product’ will
Nextlookis actually Test
like and/or what our
developing, managing and
business model is.
building the system so it TDD
could be tested
Software Product or Service
TEAM PROJECT

HAPPY HALF HOUR:

WORKING TOGETHER
 Activity 5

See canvas for your assignment :

Team A and Team B

CASE STUDY 2 : Code Review and Inspection
based on the Windows Research Kernel source code:

1. Download the source code

2. Read the license

3. Identify the source code files corresponding to your Case Study component

and design

4. Review and Report on your findings (1x4 = 4+1 pages)

 Organization of the WRK sources

The file License.txt contains the license covering use of the WRK.

The public\ directory contains a number of include files shared among system
components. base\ntos\ contains the NTOS sources.

The primary NTOS source components included in the WRK are organized as follows:

cache\ - cache manager

config\ - registry implementation
dbgk\ - user-mode debugger support
From README.TXT ex\ - executive functions (kernel heap, synchronization, time)
fsrtl\ - file system run-time support
io\ - I/O manager
ke\ - scheduler, CPU management, low-level synchronization
lpc\ - local procedure call implementation
mm\ - virtual memory manager
ob\ - kernel object manager
ps\ - process/thread support
se\ - security functions
wmi\ - Windows Management Instrumentation

inc\ - NTOS-only include files

rtl\ - kernel run-time support
init\ - kernel startup
Windows Architecture
Applications

DLLs System Services Logon/GINA

Subsystem
servers Kernel32 Critical services win32

User-mode System library (ntdll) / run-time library

Kernel-mode
NTOS kernel layer

Drivers NTOS executive layer

HAL

Firmware, Hardware
Windows Architecture: more details
 Case study 2

Academic license

README.TXT
Windows Research Kernel Source Code License
In return for the license rights above, you must agree to these obligations:
This license governs use of the accompanying software, and your use of
1. You will not remove any copyright or other notices from the software,
the software constitutes acceptance of this license. Your license rights
nor reverse engineer or decompile binary portions of the software,
below are subject to the restrictions in the license, and are available
unless your laws give you the right to do so despite this restriction.
to you only so long as you remain eligible due to your affiliation with
an accredited educational institution. (For more details on eligibility see
2. You will include a verbatim copy of this license if you distribute the software in any form.
http://www.microsoft.com/resources/sharedsource/Licensing/WindowsAcademic.mspx)
3. If you distribute derivative works of the software in source code form you will do so only under this
You may use and modify this software for any non-commercial purpose within
license, and if you distribute derivative works of the software solely in object form you will do so only
your educational institution, including making a reasonable number of copies.
under a license that complies with this license.
Teaching, academic research, and personal experimentation are examples
of purposes which can be non-commercial. You may post copies
4. If you have modified the software or created derivative works, and distribute such modifications or
on an internal secure server, and it may be installed and used
derivative works, you will cause the modified files to carry prominent notices describing your changes and
on personal machines of eligible users.
the date of the changes, so that recipients know that they are not receiving the original software.
You may distribute snippets of this software in research papers, books or
5. THE SOFTWARE COMES "AS IS", WITH NO WARRANTIES. THIS MEANS NO EXPRESS,
other teaching materials, or publish snippets of the software on websites
IMPLIED OR STATUTORY WARRANTY, INCLUDING WITHOUT LIMITATION, WARRANTIES
or on-line community forums that are intended for teaching and research.
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR ANY WARRANTY
The total amount of source code in each of your snippets should
OF TITLE OR NON-INFRINGEMENT. YOU MUST PASS THIS DISCLAIMER ON WHENEVER
not exceed 50 lines. If you wish to use a larger portion
YOU DISTRIBUTE THE SOFTWARE OR DERIVATIVE WORKS.
of the software, please contact compsci@microsoft.com.
6. MICROSOFT WILL NOT BE LIABLE FOR ANY DAMAGES RELATED TO THE SOFTWARE
You may not use or distribute this software or any derivative works
OR THIS LICENSE, INCLUDING DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL
in any form for commercial purposes. Examples of commercial purposes
OR INCIDENTAL DAMAGES, TO THE MAXIMUM EXTENT THE LAW PERMITS, NO MATTER
would be running business operations, licensing, leasing, or selling
WHAT LEGAL THEORY IT IS BASED ON. YOU MUST PASS THIS LIMITATION OF LIABILITY
the software, or distributing the software for use with commercial products.
ON WHENEVER YOU DISTRIBUTE THE SOFTWARE OR DERIVATIVE WORKS.
If you wish to commercialize your work related to the software or take part
in research with industrial partners, you need to contact iplg@microsoft.com
7. If you sue anyone over patents that you think may apply to the software
to enquire about a commercial license.
or anyone's use of the software, your license to the software ends immediately.
You may distribute the software and modifications to the software for
8. You will not use the software to aid the development of any software
non-commercial purposes, but only to other eligible users of the software
programs that are designed to: (a) harm or intentionally interfere with
(for example, to another university student or professor to support joint
the operation of a computer system including any data or information stored
academic research). You may not grant rights to the software or derivative
on such computer system; and/or (b) surreptitiously gain or maintain high level
works that are broader than those provided by this license. For example,
access to a computer system, self-propagate, and/or execute in a manner that
you may not distribute modifications of the software under terms that would
prevents detection, including but not limited to, so-called "rootkit"
permit commercial use, or under terms that purport to require the software
software programs, viruses, or worms.
or derivative works to be sublicensed to others.
9. Your rights under the license end immediately if you breach it in any way.
You may use any information in intangible form that you remember after
accessing the software. However, this right does not grant you a license
10. Microsoft reserves all rights not expressly granted to you in this license.
to any of Microsoft's copyrights or patents for anything you might create
using such information.
License Version: 12 January 2006.