PREfast

PREfast is a static analysis tool that identifies defects in C/C++ programs. It uses your existing build structure and works by intercepting your native compiler. Intra-procedural analysis identifies defects in the C/C++ source files.

Users commonly run PREfast over a section of code, view results, make fixes, and then run PREfast again. It is recommended that you divide your build into small (10 MB or less) sections, and run PREfast on each section.

PREfast displays a log of the code defects encountered. Each line entry in the log shows a description of the type of defect, a PREfast warning number, the source location, and function where the defect occurred.

The following defect message indicates that PREfast warning 501 occurred in function main, where PREfast found an HRESULT cast to a BOOL at line 21 of the source program test1.cpp.

Casting HRESULT to BOOL   501   c:\prefast\test\test1.cpp(21)   main

To execute PREfast, use whatever build command you normally use at the command line, prefaced by the word prefast. Follow the build command with command-specific arguments, as shown in the following command:

prefast

PREfast recognizes three standard build commands:

•  cl cl-arguments

Compiles and runs PREfast on an individual file and prints the PREfast results textually.

E.g. prefast cl /c test.c

•  nmake nmake-arguments

Performs an Nmake and runs PREfast on all compiled files and prints the PREfast results textually. Any nmake-arguments are passed as arguments to Nmake.

E.g. prefast nmake /f pfw_build.mak 

•  build build-arguments

Performs an Nmake and runs PREfast on all compiled files and prints the PREfast results textually. Any build-arguments are passed as arguments to build.

E.g. prefast build /cefZ 

You can use one of four PREfast-specific commands to customize PREfast:

HELP	Opens the PREfast user guide.
LIST	Writes the defect log to the console.
RESET	Removes all existing defects from the defect log.
VIEW	Displays the user interface for the PREfast defect log.

PerfMon

PerfMon allows you to open a Performance console configured with settings files from Windows NT 4.0 version of Performance Monitor.

perfmon.exe [file_name] [/HTMLFILE:converted_file settings_file]

Parameters

•  .exe

Specifies the name of the file extension.

•  file_name

Specifies the name of the settings file.

•  /HTMLFILE:converted_file settings_file

Specifies the name of the converted files, and the name of the original Windows NT 4.0 settings file.

This procedure works for the following types of Windows NT 4.0 version of Performance Monitor settings files: chart (.pmc), report (.pmr), alert (.pma), and log (.pml). To display the Windows NT 4.0 settings file in System Monitor, the system temporarily converts the file for use with Windows XP System Monitor, then discards the converted version after the console starts.

If you want to save the settings file for permanent use with System Monitor, type:

Perfmon [file_name] [/HTMLFILE:converted_file settings_file]

Where /HTMLFILE:converted_file is the name given to the converted file and settings_file is the name of the original Windows NT 4.0 settings file.

SOA

Service Oriented Architecture (SOA), at an abstract level, is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.

SOA is a software architecture where functionality is grouped around business processes and packaged as interoperable services. It also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

VSS is Volume Shadow Copy Service

The Volume Shadow Copy Service (VSS) is a set of COM APIs that implements a framework to allow volume backups to be performed while applications on a system continue to write to the volumes. It provides the backup infrastructure as well as a mechanism for creating consistent point-in-time copies of data known as shadow copies. It can produce consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. VSS provides a consistent interface that allows coordination between user applications that update data on disk (writers) and those that back up applications (requesters).

The Volume Shadow Copy Service (VSS) captures and copies stable images for backup on running systems, particularly servers, without unduly degrading the performance and stability of the services they provide. The VSS service starts on demand; therefore, for VSS operations to be successful, this service must be enabled.

Though largely transparent to user and developer, VSS does the following:

•  Coordinates activities of providers, writers, and requesters in the creation and use of shadow copies.
•  Furnishes the default system provider.
•  Implements low-level driver functionality necessary for any provider to work.

There are two methods for creating shadow copies: making either a complete copy (a full copy or clone) or copying only the changes to the volume (a differential copy or copy-on-write). Each method results in two data images - the original volume and the shadow copy volume. The functional difference between the two is that the original volume maintains full read/write capabilities, whereas the shadow copy volume is read-only. This read-only status ensures that the shadow copy volume remains a point-in-time copy until its status is changed by the administrator for a specific purpose.

Keywords of VSS:
Volume Shadow Copy Service	A service that coordinates various components to create consistent shadow copies of one or more volumes.
Requestor	An application that requests that a volume shadow copy be taken. A backup application is an example.
Writer	A component of an application that stores persistent information on one or more volumes that participate in shadow copy synchronization. Typically, this is a database application like SQL Server or Exchange Server, or a system service like Active Directory.
Provider	A component that creates and maintains the shadow copies. Examples are the system provider included with the operating system and the hardware providers included with storage arrays.
Source volume	The volume that contains the data to be shadow copied.
Storage volume	The volume that holds the shadow copy storage files for the system copy-on-write software provider.

Generics - A new feature in CLR and C# version 2.0

The .NET Framework 2.0 introduces generics to allow you to create flexible, reusable code. Language features collectively known as generics act as templates that allow classes, structures, interfaces, methods, and delegates to be declared and defined with unspecified or generic type parameters instead of specific types. Actual types are specified later when the generic is used. The new System.Collections.Generic namespace provides support for strongly typed collections. System.Nullable is a standard representation of optional values.

Use generic types to maximize code reuse, type safety, and performance. The most common use of generics is to create collection classes. You can create your own generic interfaces, classes, methods, events and delegates. Generic classes may be constrained to enable access to methods on particular data types.

E.g.

Stack - Represents a variable size last-in-first-out(LIFO) collection of instances of the same arbitrary type.

Stack numbers = new Stack();

numbers.Push("One");

numbers.Push("Two");

numbers.Push("Three");

numbers.Push("Four");

// A stack can be enumerated without disturbing its contents.

foreach (string number in numbers)

{

      Console.WriteLine(number);

}

Information on the types used in a generic data type may be obtained at run-time by means of reflection.

SAN is Storage Area Network

Storage area network (SAN) is a high-speed sub-network of shared storage devices. It contains nothing but disks for storing data. A SAN's architecture works in a way that makes all storage devices available to all servers on a LAN or WAN. It is an architecture to attach remote computer storage devices such as disk arrays, tape libraries, etc. to servers such that the devices appear as locally attached to the operating system. Because stored data does not reside directly on any of a network's servers, server power is utilized for business applications, and network capacity is released to the end user.

Devices on the SAN are normally connected together through a special kind of switch, called a Fiber Channel switch, which performs basically the same function as a switch on an Ethernet network, in that it acts as a connectivity point for the devices. Because Fiber channel is a switched technology, it is able to provide a dedicated path between the devices in the fabric so that they can utilize the entire bandwidth for the duration of the communication.

Sharing storage usually simplifies storage administration and adds flexibility since cables and storage devices do not have to be physically moved to move storage from one server to another. Other benefits include the ability to allow servers to boot from the SAN itself. This allows for a quick and easy replacement of faulty servers since the SAN can be reconfigured so that a replacement server can use the LUN of the faulty server.

SANs also tend to enable more effective disaster recovery processes. A SAN could span a distant location containing a secondary storage array. This enables storage replication either implemented by disk array controllers, by server software, or by specialized SAN devices.

ClickOnce

ClickOnce is a deployment technology that enables you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment overcomes three major issues in deployment:

•  Difficulties in updating applications

-          With Microsoft Windows Installer deployment, whenever an application is updated, the user must reinstall the whole application.

-          With ClickOnce deployment, you can provide updates automatically. Only those parts of the application that have changed are downloaded, and then the full, updated application is reinstalled from a new side-by-side folder.

•  Impact to the user's computer

-          With Windows Installer deployment, applications often rely on shared components, with the potential for versioning conflicts.

-          With ClickOnce deployment, each application is self-contained and cannot interfere with other applications.

•  Security permissions

-          Windows Installer deployment requires administrative permissions and allows only limited user installation.

-          ClickOnce deployment enables non-administrative users to install and grants only those Code Access Security permissions necessary for the application.

Developers chose Web applications instead of Windows-based applications, sacrificing the rich user interface and responsiveness of Windows Forms for ease of installation. But now, by using applications deployed using ClickOnce, you can have the best of both technologies.

Simple definition of a ClickOnce application is: any Windows Presentation Foundation, Windows Forms, or console application published using ClickOnce technology. Salient features include:

•  You can publish a ClickOnce application in three different ways: from a Web page, from a network file share, or from media such as a CD-ROM. A ClickOnce application can be installed on an end user's computer and run locally even when the computer is offline, or it can be run in an online-only mode without permanently installing anything on the end user's computer.
•  ClickOnce applications can be self-updating; they can check for newer versions as they become available and automatically replace any updated files.
•  Because ClickOnce applications are isolated, installing or running a ClickOnce application cannot break existing applications. ClickOnce applications are self-contained; each ClickOnce application is installed to and run from a secure per-user, per-application cache. By default, ClickOnce applications run in the Internet or Intranet security zones. If necessary, the application can request elevated security permissions.

Purify

Purify is a memory debugger program used by software developers to detect memory access errors in programs, especially those written in C or C++.

Purify allows dynamic verification, a process by which a program discovers errors that occur when the program runs, much like a debugger. Static verification or static code analysis, by contrast, involves detecting errors in the source code without ever compiling or running it, just by discovering logical inconsistencies.

When a program is linked with Purify, corrected verification code is automatically inserted into the executable by parsing and adding to the object code, including libraries. That way, if a memory error occurs, the program will print out the exact location of the error, the memory address involved, and other relevant information. Purify also detects memory leaks. By default, a leak report is generated at program exit but can also be generated by calling the Purify leak-detection API from within an instrumented application.

The errors that Purify discovers include array bounds reads and writes, trying to access unallocated memory, freeing unallocated memory (usually due to freeing the same memory for the second time), as well as memory leaks (allocated memory with no pointer reference). It is essential to note that most of these errors are not fatal (at least not at the site of the error), and often when just running the program there is no way to detect them, except by observing that something is wrong due to incorrect program behavior. Hence Purify helps enormously by detecting these errors and telling the programmer exactly where they occur. Because Purify works by instrumenting all the object code, it detects errors that occur inside of third-party or operating system libraries. These errors are often caused by the programmer passing incorrect arguments to the library calls, or by misunderstandings about the protocols for freeing data structures used by the libraries. These are often the most difficult errors to find and fix.

With Purify's just-in-time (JIT) debugging, you can use your debugger to investigate errors even when you run your application from outside the debugger. You can have Purify automatically attach a debugger to your application when selected types of Purify messages are reported, or have Purify ask you if you want to start a debugger at the time of the error. You can also use JIT debugging to start your debugger when it encounters a watch-point message. Purify stops just before the watch-point.

Ref: http://www-01.ibm.com/software/awdtools/purify/support/doc.html

UNO is Universal Network Objects

UNO is a component model that offers inter-operability between different programming languages, different objects models, different machine architectures, and different processes; either in a LAN or via the Internet. UNO is freely available and currently supports Java, C and C++ (on windows, Linux, and Solaris). A bridge for COM OLE Automation already exists. UNO is developed by the OpenOffice.org community including the Sun Microsystems development labs.

UNO is interface based, as are COM and CORBA. Components implement interfaces compliant to their interface specification. Multiple components communicate only via their interfaces. This allows implementing one component in a different language or to move an implementation to another machine, without modifying the other's components. This gives you huge flexibility and preserves earlier invested efforts.

Each component lives in a Uno Runtime Environment (URE). A URE is identified by the implementation language and the current process. There is no performance overhead for components, that are instantiated within the same URE, e.g., in C++, a call from component A to B is just a virtual call. The calls between components from different UREs are bridged by UNO.

In general, calls are bridged through a single dispatch method. This method is, in general, easy to implement for inter-process bridges or bridges to interpreting languages. There is no generated code for stubs or proxies. All necessary conversions are done by the generic dispatch method. The information about the method signature is retrieved dynamically from a type library. This type library is reused by every bridge, so only the number of entries in the type library grows with a growing number of types. This reduces build time and memory consumption at runtime; nevertheless, bridging is as fast as generated code.

UNO-interfaces are specified in IDL. All UNO-interfaces must be derived from a super interface, that offers acquire, release, and a QueryInterface() method (comparable to COM). The lifetime of UNO-objects is controlled by global reference counting. Exceptions are used for error handling.

UNO guarantees object identity, thread identity, and the sequence of calls.

•  Object Identity - Two interfaces' references can be compared for equality. UNO guarantees, that the result is correct, no matter whether the result is true or false.
•  Thread Identity - In UNO every thread is named by a globally unique thread identifier. A thread leaving the process via an inter-process bridge is identified when entering the process, again, some callstack levels higher. The same thread will execute the new call thus guaranteeing that any thread dependent resources stay the same (such as thread local storage, lock of mutexes, etc.).
•  Sequence of Calls - UNO allows declaring a method one way (or asynchron). Multiple, one way calls are guaranteed to be executed in the same sequence as they were called.

A sequence of one way calls can be transferred and executed extremely fast via an inter-process connection. The UNO inter-process protocol is optimized for low bandwidth connections.

Ref: http://udk.openoffice.org/

M

The Microsoft code name "M" language is a declarative language for working with data and building domain models. It is used by the "Oslo" Modeling platform. M lets users write down how they want to structure and query their data using a textual syntax that is convenient to both author and reader. M does not mandate how data is stored or accessed, nor does it mandate a specific implementation technology. Rather, M is designed to allow users to write down what they want from their data without having to specify how those requirements are met by a specific technology or platform.

The Oslo Modeling Language, M, is a language for modeling domains using text. A key advantage of modeling in text is ease with which both computers and humans can store and process text. The language feature of M enables information to be represented in a textual form that is tuned for both the problem domain and the target audience. The M language provides simple constructs for describing the shape of a textual language - that shape includes the input syntax as well as the structure and contents of the underlying information. To that end, M acts as both a schema language that can validate that textual input conforms to a given language as well as a transformation language that projects textual input into data structures that are amenable to further processing or storage.