vudevelopers

A programming language is a machine-readable artificial language designed to express computations that can be performed by a machine, particularly a computer. Programming languages can be used to create programs that specify the behavior of a machine, to express algorithms precisely, or as a mode of human communication.

Many programming languages have some form of written specification of their syntax and semantics, since computers require precisely defined instructions. Some (such as C) are defined by a specification document (for example, an ISO Standard), while others (such as Perl) have a dominant implementation.

The earliest programming languages predate the invention of the computer, and were used to direct the behavior of machines such as Jacquard looms and player pianos. Thousands of different programming languages have been created, mainly in the computer field,^[1] with many more being created every year.

Definitions

Traits often considered important for constituting a programming language:

• Function: A programming language is a language used to write computer programs, which involve a computer performing some kind of computation^[2] or algorithm and possibly control external devices such as printers, robots,^[3] and so on.

• Target: Programming languages differ from natural languages in that natural languages are only used for interaction between people, while programming languages also allow humans to communicate instructions to machines. Some programming languages are used by one device to control another. For example PostScript programs are frequently created by another program to control a computer printer or display.

• Constructs: Programming languages may contain constructs for defining and manipulating data structures or controlling the flow of execution.

• Expressive power: The theory of computation classifies languages by the computations they are capable of expressing. All Turing complete languages can implement the same set of algorithms. ANSI/ISO SQL and Charity are examples of languages that are not Turing complete, yet often called programming languages.^[4][5]

Some authors restrict the term "programming language" to those languages that can express all possible algorithms;^[6] sometimes the term "computer language" is used for more limited artificial languages.

Non-computational languages, such as markup languages like HTML or formal grammars like BNF, are usually not considered programming languages. A programming language (which may or may not be Turing complete) may be embedded in these non-computational (host) languages.

Usage

A programming language provides a structured mechanism for defining pieces of data, and the operations or transformations that may be carried out automatically on that data. A programmer uses the abstractions present in the language to represent the concepts involved in a computation. These concepts are represented as a collection of the simplest elements available (called primitives). ^[7]

Programming languages differ from most other forms of human expression in that they require a greater degree of precision and completeness. When using a natural language to communicate with other people, human authors and speakers can be ambiguous and make small errors, and still expect their intent to be understood. However, figuratively speaking, computers "do exactly what they are told to do", and cannot "understand" what code the programmer intended to write. The combination of the language definition, a program, and the program's inputs must fully specify the external behavior that occurs when the program is executed, within the domain of control of that program.

Programs for a computer might be executed in a batch process without human interaction, or a user might type commands in an interactive session of an interpreter. In this case the "commands" are simply programs, whose execution is chained together. When a language is used to give commands to a software application (such as a shell) it is called a scripting language^{[citation needed]}.

Many languages have been designed from scratch, altered to meet new needs, combined with other languages, and eventually fallen into disuse. Although there have been attempts to design one "universal" computer language that serves all purposes, all of them have failed to be generally accepted as filling this role.^[8] The need for diverse computer languages arises from the diversity of contexts in which languages are used:

• Programs range from tiny scripts written by individual hobbyists to huge systems written by hundreds of programmers.
• Programmers range in expertise from novices who need simplicity above all else, to experts who may be comfortable with considerable complexity.
• Programs must balance speed, size, and simplicity on systems ranging from microcontrollers to supercomputers.
• Programs may be written once and not change for generations, or they may undergo nearly constant modification.
• Finally, programmers may simply differ in their tastes: they may be accustomed to discussing problems and expressing them in a particular language.

One common trend in the development of programming languages has been to add more ability to solve problems using a higher level of abstraction. The earliest programming languages were tied very closely to the underlying hardware of the computer. As new programming languages have developed, features have been added that let programmers express ideas that are more remote from simple translation into underlying hardware instructions. Because programmers are less tied to the complexity of the computer, their programs can do more computing with less effort from the programmer. This lets them write more functionality per time unit.^[9]

Natural language processors have been proposed as a way to eliminate the need for a specialized language for programming. However, this goal remains distant and its benefits are open to debate. Edsger Dijkstra took the position that the use of a formal language is essential to prevent the introduction of meaningless constructs, and dismissed natural language programming as "foolish".^[10] Alan Perlis was similarly dismissive of the idea.^[11]

[edit] Elements

All programming languages have some primitive building blocks for the description of data and the processes or transformations applied to them (like the addition of two numbers or the selection of an item from a collection). These primitives are defined by syntactic and semantic rules which describe their structure and meaning respectively.

Syntax

Parse tree of Python code with inset tokenization

Syntax highlighting is often used to aid programmers in recognizing elements of source code. The language above is Python.

A programming language's surface form is known as its syntax. Most programming languages are purely textual; they use sequences of text including words, numbers, and punctuation, much like written natural languages. On the other hand, there are some programming languages which are more graphical in nature, using visual relationships between symbols to specify a program.

The syntax of a language describes the possible combinations of symbols that form a syntactically correct program. The meaning given to a combination of symbols is handled by semantics (either formal or hard-coded in a reference implementation). Since most languages are textual, this article discusses textual syntax.

Programming language syntax is usually defined using a combination of regular expressions (for lexical structure) and Backus-Naur Form (for grammatical structure). Below is a simple grammar, based on Lisp:

 expression ::= atom   | list
atom       ::= number | symbol
number     ::= [+-]?['0'-'9']+
symbol     ::= ['A'-'Z''a'-'z'].*
list       ::= '(' expression* ')'

This grammar specifies the following:

• an expression is either an atom or a list;
• an atom is either a number or a symbol;
• a number is an unbroken sequence of one or more decimal digits, optionally preceded by a plus or minus sign;
• a symbol is a letter followed by zero or more of any characters (excluding whitespace); and
• a list is a matched pair of parentheses, with zero or more expressions inside it.

The following are examples of well-formed token sequences in this grammar: '12345', '()', '(a b c232 (1))'

Not all syntactically correct programs are semantically correct. Many syntactically correct programs are nonetheless ill-formed, per the language's rules; and may (depending on the language specification and the soundness of the implementation) result in an error on translation or execution. In some cases, such programs may exhibit undefined behavior. Even when a program is well-defined within a language, it may still have a meaning that is not intended by the person who wrote it.

Using natural language as an example, it may not be possible to assign a meaning to a grammatically correct sentence or the sentence may be false:

• "Colorless green ideas sleep furiously." is grammatically well-formed but has no generally accepted meaning.
• "John is a married bachelor." is grammatically well-formed but expresses a meaning that cannot be true.

The following C language fragment is syntactically correct, but performs an operation that is not semantically defined (because p is a null pointer, the operations p->real and p->im have no meaning):

complex *p = NULL;
complex abs_p = sqrt (p->real * p->real + p->im * p->im);

The grammar needed to specify a programming language can be classified by its position in the Chomsky hierarchy. The syntax of most programming languages can be specified using a Type-2 grammar, i.e., they are context-free grammars.^[12]

Static semantics

The static semantics defines restrictions on the structure of valid texts that are hard or impossible to express in standard syntactic formalisms.^[13] The most important of these restrictions are covered by type systems.

Type system

A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. This generally includes a description of the data structures that can be constructed in the language. The design and study of type systems using formal mathematics is known as type theory.

[edit] Typed versus untyped languages

A language is typed if the specification of every operation defines types of data to which the operation is applicable, with the implication that it is not applicable to other types.^[14] For example, "this text between the quotes" is a string. In most programming languages, dividing a number by a string has no meaning. Most modern programming languages will therefore reject any program attempting to perform such an operation. In some languages, the meaningless operation will be detected when the program is compiled ("static" type checking), and rejected by the compiler, while in others, it will be detected when the program is run ("dynamic" type checking), resulting in a runtime exception.

A special case of typed languages are the single-type languages. These are often scripting or markup languages, such as Rexx or SGML, and have only one data type—most commonly character strings which are used for both symbolic and numeric data.

In contrast, an untyped language, such as most assembly languages, allows any operation to be performed on any data, which are generally considered to be sequences of bits of various lengths.^[14] High-level languages which are untyped include BCPL and some varieties of Forth.

In practice, while few languages are considered typed from the point of view of type theory (verifying or rejecting all operations), most modern languages offer a degree of typing.^[14] Many production languages provide means to bypass or subvert the type system.

Static versus dynamic typing

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates.^[14]

Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.^[14] As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

Weak and strong typing

Weak typing allows a value of one type to be treated as another, for example treating a string as a number.^[14] This can occasionally be useful, but it can also allow some kinds of program faults to go undetected at compile time and even at runtime.

Strong typing prevents the above. An attempt to perform an operation on the wrong type of value raises an error.^[14] Strongly typed languages are often termed type-safe or safe.

An alternative definition for "weakly typed" refers to languages, such as Perl and JavaScript, which permit a large number of implicit type conversions. In JavaScript, for example, the expression 2 * x implicitly converts x to a number, and this conversion succeeds even if x is null, undefined, an Array, or a string of letters. Such implicit conversions are often useful, but they can mask programming errors.

Strong and static are now generally considered orthogonal concepts, but usage in the literature differs. Some use the term strongly typed to mean strongly, statically typed, or, even more confusingly, to mean simply statically typed. Thus C has been called both strongly typed and weakly, statically typed.^[16][17]

Execution semantics

Once data has been specified, the machine must be instructed to perform operations on the data. The execution semantics of a language defines how and when the various constructs of a language should produce a program behavior.

For example, the semantics may define the strategy by which expressions are evaluated to values, or the manner in which control structures conditionally execute statements.

Core library

Most programming languages have an associated core library (sometimes known as the 'Standard library', especially if it is included as part of the published language standard), which is conventionally made available by all implementations of the language. Core libraries typically include definitions for commonly used algorithms, data structures, and mechanisms for input and output.

A language's core library is often treated as part of the language by its users, although the designers may have treated it as a separate entity. Many language specifications define a core that must be made available in all implementations, and in the case of standardized languages this core library may be required. The line between a language and its core library therefore differs from language to language. Indeed, some languages are designed so that the meanings of certain syntactic constructs cannot even be described without referring to the core library. For example, in Java, a string literal is defined as an instance of the java.lang.String class; similarly, in Smalltalk, an anonymous function expression (a "block") constructs an instance of the library's BlockContext class. Conversely, Scheme contains multiple coherent subsets that suffice to construct the rest of the language as library macros, and so the language designers do not even bother to say which portions of the language must be implemented as language constructs, and which must be implemented as parts of a library.

Practice

A language's designers and users must construct a number of artifacts that govern and enable the practice of programming. The most important of these artifacts are the language specification and implementation.

Specification

The specification of a programming language is intended to provide a definition that the language users and the implementors can use to determine whether the behavior of a program is correct, given its source code.

A programming language specification can take several forms, including the following:

• An explicit definition of the syntax, static semantics, and execution semantics of the language. While syntax is commonly specified using a formal grammar, semantic definitions may be written in natural language (e.g., the C language), or a formal semantics (e.g., the Standard ML^[18] and Scheme^[19] specifications).
• A description of the behavior of a translator for the language (e.g., the C++ and Fortran specifications). The syntax and semantics of the language have to be inferred from this description, which may be written in natural or a formal language.
• A reference or model implementation, sometimes written in the language being specified (e.g., Prolog or ANSI REXX^[20]). The syntax and semantics of the language are explicit in the behavior of the reference implementation.

Implementation

An implementation of a programming language provides a way to execute that program on one or more configurations of hardware and software. There are, broadly, two approaches to programming language implementation: compilation and interpretation. It is generally possible to implement a language using either technique.

The output of a compiler may be executed by hardware or a program called an interpreter. In some implementations that make use of the interpreter approach there is no distinct boundary between compiling and interpreting. For instance, some implementations of the BASIC programming language compile and then execute the source a line at a time.

Programs that are executed directly on the hardware usually run several orders of magnitude faster than those that are interpreted in software.^{[citation needed]}

One technique for improving the performance of interpreted programs is just-in-time compilation. Here the virtual machine, just before execution, translates the blocks of bytecode which are going to be used to machine code, for direct execution on the hardware.

History

A selection of textbooks that teach programming, in languages both popular and obscure. These are only a few of the thousands of programming languages and dialects that have been designed in history.

Early developments

The first programming languages predate the modern computer. The 19th century had "programmable" looms and player piano scrolls which implemented what are today recognized as examples of domain-specific programming languages. By the beginning of the twentieth century, punch cards encoded data and directed mechanical processing. In the 1930s and 1940s, the formalisms of Alonzo Church's lambda calculus and Alan Turing's Turing machines provided mathematical abstractions for expressing algorithms; the lambda calculus remains influential in language design.^[21]

In the 1940s, the first electrically powered digital computers were created. The first high-level programming language to be designed for a computer was Plankalkül, developed for the German Z3 by Konrad Zuse between 1943 and 1945. However, it was not implemented until 1998 and 2000.

Programmers of early 1950s computers, notably UNIVAC I and IBM 701, used machine language programs, that is, the first generation language (1GL). 1GL programming was quickly superseded by similarly machine-specific, but mnemonic, second generation languages (2GL) known as assembly languages or "assembler". Later in the 1950s, assembly language programming, which had evolved to include the use of macro instructions, was followed by the development of "third generation" programming languages (3GL), such as FORTRAN, LISP, and COBOL. 3GLs are more abstract and are "portable", or at least implemented similar on computers that do not support the same native machine code. Updated versions of all of these 3GLs are still in general use, and each has strongly influenced the development of later languages. At the end of the 1950s, the language formalized as Algol 60 was introduced, and most later programming languages are, in many respects, descendants of Algol. The format and use of the early programming languages was heavily influenced by the constraints of the interface.

Refinement

The period from the 1960s to the late 1970s brought the development of the major language paradigms now in use, though many aspects were refinements of ideas in the very first Third-generation programming languages:

• APL introduced array programming and influenced functional programming.^[25]
• PL/I (NPL) was designed in the early 1960s to incorporate the best ideas from FORTRAN and COBOL.
• In the 1960s, Simula was the first language designed to support object-oriented programming; in the mid-1970s, Smalltalk followed with the first "purely" object-oriented language.
• C was developed between 1969 and 1973 as a systems programming language, and remains popular.^[26]
• Prolog, designed in 1972, was the first logic programming language.
• In 1978, ML built a polymorphic type system on top of Lisp, pioneering statically typed functional programming languages.

Each of these languages spawned an entire family of descendants, and most modern languages count at least one of them in their ancestry.

The 1960s and 1970s also saw considerable debate over the merits of structured programming, and whether programming languages should be designed to support it. Edsger Dijkstra, in a famous 1968 letter published in the Communications of the ACM, argued that GOTO statements should be eliminated from all "higher level" programming languages.

The 1960s and 1970s also saw expansion of techniques that reduced the footprint of a program as well as improved productivity of the programmer and user. The card deck for an early 4GL was a lot smaller for the same functionality expressed in a 3GL deck.

Consolidation and growth

The 1980s were years of relative consolidation. C++ combined object-oriented and systems programming. The United States government standardized Ada, a systems programming language derived from Pascal and intended for use by defense contractors. In Japan and elsewhere, vast sums were spent investigating so-called "fifth generation" languages that incorporated logic programming constructs. The functional languages community moved to standardize ML and Lisp. Rather than inventing new paradigms, all of these movements elaborated upon the ideas invented in the previous decade.

One important trend in language design during the 1980s was an increased focus on programming for large-scale systems through the use of modules, or large-scale organizational units of code. Modula-2, Ada, and ML all developed notable module systems in the 1980s, although other languages, such as PL/I, already had extensive support for modular programming. Module systems were often wedded to generic programming constructs.

The rapid growth of the Internet in the mid-1990s created opportunities for new languages. Perl, originally a Unix scripting tool first released in 1987, became common in dynamic Web sites. Java came to be used for server-side programming. These developments were not fundamentally novel, rather they were refinements to existing languages and paradigms, and largely based on the C family of programming languages.

Programming language evolution continues, in both industry and research. Current directions include security and reliability verification, new kinds of modularity (mixins, delegates, aspects), and database integration such as Microsoft's LINQ.

The 4GLs are examples of languages which are domain-specific, such as SQL, which manipulates and returns sets of data rather than the scalar values which are canonical to most programming languages. Perl, for example, with its 'here document' can hold multiple 4GL programs, as well as multiple JavaScript programs, in part of its own perl code and use variable interpolation in the 'here document' to support multi-language programming.

Measuring language usage

It is difficult to determine which programming languages are most widely used, and what usage means varies by context. One language may occupy the greater number of programmer hours, a different one have more lines of code, and a third utilize the most CPU time. Some languages are very popular for particular kinds of applications. For example, COBOL is still strong in the corporate data center, often on large mainframes; FORTRAN in engineering applications; C in embedded applications and operating systems; and other languages are regularly used to write many different kinds of applications.

Various methods of measuring language popularity, each subject to a different bias over what is measured, have been proposed:

• counting the number of job advertisements that mention the language
• the number of books sold that teach or describe the language
• estimates of the number of existing lines of code written in the language—which may underestimate languages not often found in public searches
• counts of language references (i.e., to the name of the language) found using a web search engine.

Combining and averaging information from various internet sites, langpop.com claims that ^[35] in 2008 the 10 most cited programming languages are (in alphabetical order): C, C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby, and SQL.

Taxonomies

There is no overarching classification scheme for programming languages. A given programming language does not usually have a single ancestor language. Languages commonly arise by combining the elements of several predecessor languages with new ideas in circulation at the time. Ideas that originate in one language will diffuse throughout a family of related languages, and then leap suddenly across familial gaps to appear in an entirely different family.

The task is further complicated by the fact that languages can be classified along multiple axes. For example, Java is both an object-oriented language (because it encourages object-oriented organization) and a concurrent language (because it contains built-in constructs for running multiple threads in parallel). Python is an object-oriented scripting language.

In broad strokes, programming languages divide into programming paradigms and a classification by intended domain of use. Paradigms include procedural programming, object-oriented programming, functional programming, and logic programming; some languages are hybrids of paradigms or multi-paradigmatic. An assembly language is not so much a paradigm as a direct model of an underlying machine architecture. By purpose, programming languages might be considered general purpose, system programming languages, scripting languages, domain-specific languages, or concurrent/distributed languages (or a combination of these). Some general purpose languages were designed largely with educational goals.

A programming language may also be classified by factors unrelated to programming paradigm. For instance, most programming languages use English language keywords, while a minority do not. Other languages may be classified as being esoteric or not.

A software port (usually just called a 'port') is a virtual/logical data connection that can be used by programs to exchange data directly, instead of going through a file or other temporary storage location. The most common of these are TCP and UDP ports which are used to exchange data between computers on the Internet.

In Flow-based programming, a 'port' is a (named) point of contact between a process and a connection.

[edit] I/O or machine port mechanism

For Input or Output (I/O) operations, nearly all processor families use memory-mapped I/O -- the same assembly instructions are used for both memory access and hardware I/O. However, Intel microprocessors use port-mapped I/O -- they have a completely separate set of assembly instructions (IN, INS, OUT, and OUTS) that are used specifically for hardware I/O. These instructions figure out which hardware device to communicate with using the concept of an I/O port or machine port. These ports are numbered based on which hardware device they refer to. These hardware I/O ports are in a completely different address space from normal memory.

Intel microprocessors generally allow one octet (8-bit byte or word) to be sent or received during each instruction. The hardware device decides how to interpret data sent to it and what data to send to the processor. For example, a common use is to ask a hardware device which byte (in a data transfer) it will be sending next.

Some I/O ports are connected with "peripheral" devices outside the CPU itself, but inside the computer case. Others I/O ports are connected to "peripheral" external devices outside the computer case using some Computer port (hardware).

For most Windows XP installs, you’ll never need to worry about the validity of the product key assigned to your copy of the OS. However, software does tend to get installed without authorization, even in the most carefully managed shops, and so from time to time you may need to reset the XP product key.

For example, perhaps a user installed a pirated copy of XP but now wants to go legal. Maybe you've been hired by an organization that installed 100 pirated copies of XP but now has a legitimate volume-licensing key (VLK). Perhaps an end user purchased an additional retail license for XP but needs to use his original CD to install the software. When situations like these arise, changing XP's product key is often the most practical—or only—solution.

Determining if you have a valid product ID
Hopefully you already know if you're dealing with a pirated copy of XP. But if you're unsure, a quick way to tell is to install Service Pack 1. Shortly after releasing Windows XP, Microsoft realized that most pirated XP installations were using two specific VLKs, the most popular of which begins with "FCKGW.” These VLKs produce product IDs that match either XXXXX-640-0000356-23XXX or XXXXX-640-2001765-23XXX, where X is any number.

If you try to install SP1 and get the following error message:
 

The Product Key used to install Windows is invalid. Please contact your system administrator or retailer immediately to obtain a valid Product Key…"


You are dealing with a pirated copy of Windows. For more information about obtaining a valid product key, see Microsoft Knowledge Base article 326904.

You can also directly check the OS’sproduct ID by right-clicking on My Computer, clicking Properties, and selecting the General tab. The machine's product ID will be located under the Registered To section. If the ID matches either of the two models commonly associated with VLK fraud, you’ll need to obtain a valid XP product key before proceeding. None of the procedures described below will work without a legitimate product key.

Two methods of changing Windows XP's product key
You can change a Windows XP installation's product key either by editing the registry or by using one of two Windows Management Instrumentation (WMI) scripts. The registry editing method is outlined in Knowledge Base articles 321636 and 328874 and works on Windows XP Home, Windows XP Professional, and Windows XP Corporate Edition. The script method is outlined in article 328874 and is designed to work on Corporate Edition installations that use a VLK and do not require activation. It may work on a Home or Professional installation, but I have not tested this scenario.

The script method is the practical solution for changing the product keys on a large number of machines. Regardless of the method you choose, make sure to backup important data before changing a product ID, since an unexpected problem could render the machine unbootable and necessitate a complete reinstallation of Windows.

Warning :

The following instructions involve editing your system registry. Using the Windows Registry Editor incorrectly can cause serious problems that require the reinstallation of your operating system and possible loss of data. TechRepublic does not support problems that arise from editing your registry. Use the Registry Editor and the following directions at your own risk.

Editing the registry
Begin by opening the Registry Editor and navigating to
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current Version\WPAEvents

In the right pane, right-click the ODBETimer binary value and select Modify. Change at least one character of this value to either a number from 0 to 9 or to a letter from A to F, then click OK and close the Registry Editor. This renders the current product key invalid and deactivates Windows.

Now, it’s time to reactivate Windows using your new product key. Click Start | Run and enter the command:
%systemroot%\system32\oobe\msoobe /a


where %systemroot% is your Windows directory. In many cases, this command will look like:
C:\windows\system32\oobe\msoobe.exe /a

Device driver installation has always been a headache for most of the people. Either one thing or the other is always missing. Once we want to clean install Windows, we have to make sure that we have got all the device drivers for our system. If we miss some of the drivers, nothing works fine. Here are some ways to find unknown device drivers in Windows.

1- Using Unknown Device Identifier

Unknown Device Identifier enables you to identify the yellow question mark labeled Unknown Devices in Device Manager. And reports you a detailed summary for the manufacturer name, OEM name, device type, device model and even the exact name of the unknown devices. With the collected information, you might contact your hardware manufacturer for support or search the Internet for the corresponding driver with a simple click. With this utility, you might immediately convert your unidentified unknown devices into identified known devices and find proper driver on the Internet and contact the hardware device manufacturer or vender. Known devices recognized by Microsoft Windows will also be analyzed independent of the operating system.

Download Unknown Device Identifier from the following location:

Unknown Device Identifier 6 (849.9 KiB)

2- Using Unknown Devices

Unknown Devices helps you find what those unknown devices in Device Manager really are.

By checking Device Manager for unknown devices and extracting information from it, this program attempts to figure out what the device is. You might not have to open your case or look up random numbers off of PCI cards to figure out what they are.

However when I run this software on my Windows Vista machine, it doesn’t detect my operating system. I have updated the vendors database file and packed with this software. The software can be downloaded from the following location:
 
Unknown Devices (462.2 KiB)

3- Manually Identifying The Unknown Devices

To manually identify the devices we have to find out the device instance ID which has two parts, one is the vendor ID and the second is Device ID. Once we have got the vendor ID and identified the device ID, we can easily find the drivers for our device.

To find the device instance ID go to Device Manager –> Right click the unknown device –> Properties –> Details.

Now from the drop down menu select Device Instance Path (Windows Vista)/ Device Instance ID (Windows XP)

It will give you a string value which contains the vendor ID and the Device ID. The string is like this:

HDAUDIO\FUNC_02&VEN_14F1&DEV_5045&SUBSYS_103C30D5&REV_1001\4&2675E3A&0&0002

Where red is the Vendor ID and green is the Device ID. Note down both of them.



Once you have the Vendor ID and the device ID, you can go to the following websites and find out the vendor and device name and search for its drivers.

http://www.pcidatabase.com/

http://www.pcisig.com/membership/vid_search/

http://pciids.sourceforge.net/

You can also download PCI Utilities which displays the Vendors and devices in human readable format instead of the alphanumeric code characters.
More Interesting Articles
Show Hidden Files and Folders not working? (640)
Security Tools: Hijackthis Part 1 (3)
Get Back Missing Search Option In Windows (1)
Download Free Video Training Of Windows 2008 Server (7)

Articles on System Failure:

2001 "Root Cause Analysis" Survey Results This survey of use of Root Cause Analysis techniques by Maintenance professionals was conducted on the Plant Maintenance Resource Center web site in late 2000 
 2003 Blackout (Northeastern US/Ontario) - Research Papers Numerous links to description and analysis of this significant power blackout 
 A Case Study-Failure of Motor Shaft Of Rotary Wagon Tippler -Reasons and Remedy To avoid such type of failure the reason for shaft failure is discussed in this paper. And this paper also suggested necessary precautions to avoid such type of breakdown. - requires free Adobe Acrobat Reader for viewing. 
 A little bit more about troubleshooting centrifugal pumps and mechanical seals One of the U. S. based Japanese automobile manufacturers has a unique method of troubleshooting any type of mechanical failure. The system is called the "Five Whys". 
 A Re-Examination of Failure Analysis and Root Cause Determination Failure analysis is a complex process applied to all different types of materials. Each class of materials requires special skills and experience to effectively unravel the causes of failure. This is the first in a series of papers focusing on these various subsets of materials. The series will include failures in metallurgy, paints and coatings, plastics and electronics, as well as failure caused by corrosion. Each paper in the series will also include an examination the principles of root cause determination within that particular field. This first paper is primarily concerned with the overall approach to failure analysis and with the applications of that approach to metallurgical failures. - requires free Adobe Acrobat Reader for viewing. 
 Analysis: RCM Versus RCA There is a basic but very real misconception concerning the roles of RCM (Reliability Centered Maintenance) and RCA (Root Cause Analysis) in today’s operating facility. This is due primarily to the fact the most people think that the two programs do virtually the same thing - nothing could be further from the truth. 
 Analyzing Semiconductor Failure 
 Become an Equipment Reliability Detective courtesy of Reliability Center, Inc. 
 Chronic Events: Panning For Gold 
 Columbia Accident Investigation Board - Final Report The Columbia Accident Investigation Board's final report on the causes of the Feb. 1, 2003 Space Shuttle accident (caution - this is a BIG file - 11Mb) - requires free Adobe Acrobat Reader for viewing. 
 Creating the Environment For RCA To Succeed The one thing we should always be cognizant of is the fact that no matter what the new initiative is, it will likely be viewed from the end user as the "program-of-the-month." 
 Dynamic Properties of Damaged Materials 
 Eli Lilly Incident Profile - Finding the Root Cause Root Cause Failure Analysis (RCFA) methodology and a relatively new software program PROACT® were used to get to the incident’s root cause. 
 Engine Thrust Bearing Failure 
 Enhance The Ability To Perform Root Cause Analysis with Reliability Physics Over the years root cause analysis has become a word that is now associated with many problems. At one time the National Transportation & Safety Board (NTSB) was unique in its use referencing the conclusion of an airline crash investigation as the root cause analysis of the mishap. Today the word root cause is heard on the news more often and associated with all kinds of events. The events now range from the root cause of 9/11 to the root cause of a factory explosion. This article will help to give a deeper understanding of what Root Cause Analysis is and what it takes to get to the root causes of an event. 
 Failure Analysis of Electronics Assemblies Here's what you need to know before, during and after electronics assembly failure analysis. 
 Failure Analysis of Mechanical Components In more than 90 percent of industrial cases a trained person can use the basic techniques of failure analysis to diagnose the mechanical causes behind a failure, without having to enlist outside sources and expensive analytical tools like electron microscopes. Then, knowing how a failure happened, the investigator can pursue the human roots of why it happened. There are times, however, when 90 percent accuracy is not good enough. When personal injury or a large loss is possible, a professional should guide the analysis. 
 Failure Analysis of Paints and Coatings In this introductory survey failure analysis methodology will be applied to the principal mechanisms by which paints and coatings fail during service. How to conduct a failure analysis, stages of analysis, proper techniques for sample removal, destructive and non-destructive techniques, primary causes and modes of failure, and specific case studies will be discussed. - requires free Adobe Acrobat Reader for viewing. 
 Failure Analysis Study This technical white paper provides an extensive study into the different types of material and component failures observed in industrial enterprises. This white paper also provides solutions to manufacturing problems and advises towards selecting the appropriate materials to improve overall product quality, reduce costs, and enhance customer satisfaction. It also discusses welding problems and offers solutions to improve the weld process. - requires free Adobe Acrobat Reader for viewing. 
 Failure Analysis/Problem Solving Methods courtesy of Reliability Center, Inc. 
 Failure Analysis: Contamination How to diagnose contamination failures in bearings 
 Failure Analysis: Corrosion How to diagnose corrosion failures in bearings 
 Failure Analysis: Electrical Fluting How to diagnose electrical fluting in bearings 
 Failure Analysis: Excessive Load How to diagnose excessive load in bearings 
 Failure Analysis: False Brineling How to diagnose false brineling in bearings 
 Failure Analysis: Installation Damage How to diagnose installation damage in bearings 
 Failure Analysis: Loose Fit How to diagnose loose bearing fit 
 Failure Analysis: Lubrication How to diagnose lubrication failures in bearings 
 Failure Analysis: Misalignment How to diagnose misalignment failures in bearings 
 Failure Analysis: Normal Fatigue Failure How to diagnose normal fatigue failures in bearings 
 Failure Analysis: Overheating How to diagnose overheating in bearings 
 Failure Analysis: Preload Failures How to diagnose bearing preload failure 
 Failure Analysis: Reverse Loading How to diagnose reverse loading in bearings 
 Failure Analysis: True Brinneling Failures How to diagnose true brinelling 
 Failure and Root Cause Analysis in India and the Middle East Failures are costing Indian and Middle-East plants and manufacturing units billions of dollars a year and are draining the productivity potential of the respective nations. TCR presents their methodical approach to determine the mode and root cause of failures. - requires free Adobe Acrobat Reader for viewing. 
 Failure Codes and their use Request this free article from this link 
 Failure Information Survey Results - requires free Adobe Acrobat Reader for viewing. 
 Failure Investigation and Analysis with case study Samples of several failure investigations, with photographs - requires free Adobe Acrobat Reader for viewing. 
 Failure Mechanisms and Effects Laboratory - The Impact of Failure Analysis on Engineering Practice In a taped interview with Dr. John H. Smith of the Metallurgy Division, National Institute of Standards and Technology, Gaithersburg, Maryland, Dr. Smith discusses how failure analysis in the field often impacts Engineering Standards. Using slides Dr. Smith discusses and illustrates two specific cases where this has happened. The first of these cases involved the failure of an oil storage tank that was relocated from Cleveland to Pittsburgh. The other case involved the failure of a compressed natural gas trailer tube in Litchfield, Kentucky. In each of these cases, compliance with existing construction and/or building codes failed to prevent failures that ultimately resulted in serious consequences. 
 Failure Modes & Effects Analysis - A Modified Approach courtesy of Reliability Center, Inc. 
 Fighting Failure It is time to change our paradigm to a culture where failure is the exception and certainly not the rule. This is easy to say but a bit more of a challenge to accomplish. Ken Latino of Meridium, Inc. outlines some steps you can take to generate a more Reliability-focused culture within your plant or facility. - requires free Adobe Acrobat Reader for viewing. 
 Gas Distribution Pipe Explosion An unprotected schedule 40 carbon steel pipe ruptured beneath the surface of an essential roadway. The pipe was visibly corroded on its exterior surface. When cut open, black colored deposits but no underlying corrosion was observed on the inside diameter surface of the pipe. Further mechanical damage and abrasion were exhibited on the pipe exterior, especially at a hole several feet away from the fracture. Noncompliance was suspected and an immediate failure investigation was deemed necessary to assign financial responsibility. - requires free Adobe Acrobat Reader for viewing. 
 General Aviation Maintenance-Related Accidents report This report, issued by the Office of Aerospace Medicine within the Federal Aviation Administration in the USA, analyzes 10 years of National Transportation Safety Board data. Its primary conclusion was that installation errors were the leading cause of maintenance-related general aviation accidents. Are there lessons that can be learnt for general industry? - requires free Adobe Acrobat Reader for viewing. 
 Getting Root Cause Analysis to Work for You This paper from Sandy Dunn provides several tips regarding how to make the most of Root Cause Analysis to progressively eliminate failures. - requires free Adobe Acrobat Reader for viewing. 
 How Can Vendor's PROACT to their Customer's Concerns? courtesy of Reliability Center, Inc. 
 How Has Root Cause Failure Analysis Failed To Meet It's Potential? courtesy of Reliability Center, Inc. 
 How To Select the "Right" Root Cause Failure Analysis (RCFA) Methodology & Vendor courtesy of Reliability Center, Inc. 
 How to sell Root Cause Analysis (RCA) to Management 
 Human Precision: The Human Side of Reliability Reliability in terms of a human being can best be measured by the precision the individual puts into the task being performed. 
 Improve the Downtime Tracking System and Establish an RCFA Process Have you validated the downtime tracking process? Does your system track any and all reason for equipment downtime, reduction in equipment rate, and losses due to poor quality or yield? Does a cross-functional team validate the downtime log? What steps have you taken to ensure that there are no ‘CYA games’ being played by maintenance, operations, or any other functional area in regard to who is responsible for the mitigation of these production losses? - requires free Adobe Acrobat Reader for viewing. 
 Interim Report: Causes of the August 14th, 2003 Blackout in the United States and Canada The official interim report of this event produced by the U.S.-Canada Power System Outage Task Force 
 Investigating Material and Component Failure This white paper provides an extensive study into the different types of material and component failures observed in industrial enterprises. This white paper also provides solutions to manufacturing problems and advises towards selecting the appropriate materials to improve overall product quality, reduce costs, and enhance customer satisfaction. It also discusses welding problems and offers solutions to improve the weld process. - requires free Adobe Acrobat Reader for viewing. 
 Is Analysis An Engineering Function? courtesy of Reliability Center, Inc. 
 Justifying Root Cause Analysis Make the business case with a significant calculated return on investment 
 Justifying Root Cause Analysis Make the business case with a significant calculated return on investment 
 Managing Failure Analysis To be a good failure analyst one must also be a good manager. 
 Microstructrure of the Month Monthly informative articles for today's metallurgists and engineers. Each month, engineers from the Metallography and Failure Analysis division highlight an issue that may help prevent future application or product failures observed in our material testing laboratory in India. 
 O Processo de Análise de Causas Raíz PROACT â Metodologia & Software Através da historia o homem inventou e melhorou numerosos equipamentos e processos baseando-se em suas habilidades para atender uma demanda crescente de produtos e serviços por parte da sociedade. Como resultado desta demanda em crescimento e da otimização de custos, tem-se desenvolvido diversas técnicas Para a análise dos problemas que surgiram nos quipamentos e processos e no rendimento de capacidades, “em um esforço para assegurar a confiabilidade. A Análise por Causa Raiz (ACR) é uma destas armas no arsenal da confiabilidade… 
 Obstacles to Learning from Things that Go Wrong The unique advantage those of us in the Root Cause Analysis (RCA) field have is that everyone has problems that must be solved. No matter what your occupation nor the industry you are in, things do not always go as planned and someone must address “Why?” Sounds simple doesn’t it? Why is it that when we try to formalize such RCA-type efforts, that there is often resistance and lack of commitment? 
 Phoenix Approach Analysis of Ski Lift Strangulation - requires free Adobe Acrobat Reader for viewing. 
 Predictive Technology is the Key to Breaking Error Chains It is virtually impossible for one or even a few human errors to cause a random event (significant failure), no matter how dramatic the event. This small statement has a meaning so powerful that it’s hard to believe that we as humans do not take it to heart. 
 Preventing Space Shuttle Disasters Means Getting to the Root Cause The Space Shuttle Columbia disaster was barely an hour old and already the pundits were speculating about the “cause.” This article argues that no disaster like the Columbia is ever because of one, or even two easy to identify causes, such as the often-mentioned insulation falling and damaged left wing tiles. The root causes always go much deeper. - requires free Adobe Acrobat Reader for viewing. 
 PROACT® for Infrared Thermographers The use of Infrared Thermography puts us all in the position of being “failure analysts”. Our roles sometimes require us to not only to identify thermal anomalies, but also to investigate where the anomaly originates. We will explore how a Root Cause Analysis (RCA) method called PROACT® can help thermographers provide a competitive edge by providing their clients with a Root Cause Analysis in addition to the Infrared Study. The use of PROACT® software will be demonstrated to show how to involve and present the RCA findings to the end client. 
 RCA in Action: The Space Shuttle Columbia Investigation As is typical in our manufacturing organizations, oftentimes it takes high visibility events with catastrophic consequences for a full-blown Root Cause Analysis (RCA) to be conducted. 
 RCFA + RCM = Formula for Successful Maintenance When these two approaches are properly combined, they materially enhance operating performance. 
 RCFA Provides Whirlpool Corporation with Immediate Improvements This RCFA case study comes from the Marion Division, and was performed two weeks after initial RCFA Methods training was completed. 
 RCM Versus RCA Most people think that the two programs do virtually the same thing - nothing could be further from the truth 
 Recurring Causes of Recent Chemical Accidents The US Environmental Protection Agency (EPA) and the Occupational Safety and Health Administration (OSHA) have investigated recent accidents at petroleum refineries, chemical manufacturing facilities, tolling operations, chemical distributors, and other types of facilities. Recurring causes of these accidents include inadequate process hazards analysis, use of inappropriate or poorly-designed equipment, inadequate indications of process condition, and others 
 Reliability Engineering Snapshot - Machine Design "Rules of Thumb" are just that, general guidelines that need to be reviewed on an individual basis. Not to do so, can spell trouble. A case in point for "making the pinion gear harder than the ring gear." How much harder? 
 Reliability Engineering Snapshot - Material Properties Is it a casting crack or is it a brittle failure? Grain growth pattern versus crack path, which came first? 
 Root Cause Analysis - Quality of Process? - Part 2 
 Root Cause Analysis - Quality of Process? - Part 3 When most people conduct their version of a Root Cause Analysis (RCA), where do they usually stop? How do they know when they are done? How do they know that the problem will not recur? 
 Root Cause Analysis: Quality of Process - Part 1 We have all heard the term Root Cause Analysis (RCA) and we likely all interpret its meaning in a different fashion 
 Root Cause Analysis: Will It Find the Weak Link? 
 Root Cause Failure Analysis courtesy of Reliability Center, Inc. 
 Root Cause Failure Analysis - An Integrated Approach This article by Herman Ellis of Qualitech Management Services is a compilation of the work of numerous researchers who have developed various approaches to the science of Problem Solving / Decision Making. It is an attempt to combine and integrate proven techniques into one GENERIC methodology that can be applied to ANY problem. Contrary to other, current, (very good) methodologies, this approach does not require a dedicated team, nor do they have to be experts in the subject matter of the problem. Indeed, it is our experience with hundreds of problem analysis sessions based on this model that the solutions generated during public programs attended by a cross-section of participants from different industries and cultures, significantly outperform those of private in-house courses. - requires free Adobe Acrobat Reader for viewing. 
 Root Cause Failure Analysis - Understanding Mechanical Failures Machines aren’t supposed to break, and mechanical components such as shafts, fasteners, and structures aren’t supposed to fail. But when they do fail, they can tell us exactly why. 
 Root Cause Failure Analysis Saves Inland Steel $1.15 Million courtesy of Reliability Center, Inc. 
 Root Cause Failure Analysis: Interpretation of Fatigue Failures By far, the majority of mechanical failures happen from fatigue. (If someone asks you why something failed, just tell them fatigue. You’ll be right 90% of the time and that’s a great average in any activity.) But saying that fatigue caused a failure is like saying the hill caused a car’s brakes to fail. The value of failure analysis is that you can use it to look at the broken parts, determine the type and magnitude of the forces involved, then do something to prevent their recurrence. 
 Root Cause Failure Analysis: The Case of the Frequent Bearing Failures This is the third in a series of articles on Root Cause Failure Analysis that examines some of the available metallurgical and physical evidence. 
 Root Cause Failure Analysis: Understanding Mechanical Failures Machines aren’t supposed to break, and mechanical components such as shafts, fasteners, and structures aren’t supposed to fail. But when they do fail, they can tell us exactly why. 
 sci.engr FAQ on Failures -- part one 
 Some Failure Analysis Case Histories in Galvanized Steel Products The three case histories presented in this paper concern defects and causes of failure associated with galvanized steel sheet material. Optical metallography and microindentation hardness testing were the principal methods employed in determining the causes of failure but were supplemented as necessary by scanning electron microscopy and energy-dispersive X-ray spectrometry. - requires free Adobe Acrobat Reader for viewing. 
 Supporting Root Cause Analysis: A Manager’s Perspective Supporting Root Cause Analysis: A Manager’s Perspective by Robert J. Latino, EVP, Strategic Development, Reliability Center, Inc. In a world inundated with the perceived “programs-of-the-month”, many legitimate efforts are discounted because of guilt-by-association. While many of these perceptions may be invalid and not based on current reality, nevertheless they are the belief systems of the workforce and therefore what they base their decisions on. So how do managers successfully implement proven methods, practices and techniques into such an environment? This paper will strive to discuss management’s specific role in one reliability method called Root Cause Analysis.
Supporting Root Cause Analysis: A Manager's Perspective 
 Tacoma Narrows Bridge Disaster 
 The "Soft Side" of Root Cause Analysis courtesy of Reliability Center, Inc. 
 The Essentials of Conducting a Successful Root Cause Failure Analysis courtesy of Reliability Center, Inc. 
 The Failure Dilemma How do I move towards Proaction when I work in such a Reactive environment. Courtesy of Reliability Center, Inc. 
 The Failure Dilemma How do I move towards Proaction when I work in such a Reactive environment? 
 The Pontiac that was Allergic to Vanilla Ice Cream For the engineers among us who understand that the obvious is not always the solution, and that the facts, no matter how implausible, are still the facts.. 
 The Power of Failure Analysis to Eliminate Process Interruptions courtesy of Reliability Center, Inc. 
 The Problem with Problem Solving Why do so many problems still exist? The answer becomes readily apparent when we realize that the science of problem solving often takes a back seat to the other more pressing day-to-day issues we face during everyday operations 
 The RCFA Paradox courtesy of Reliability Center, Inc. 
 Understanding the Multiple Roots of Machinery Failures Looking at the newspapers we frequently see statistics on the cause of some group of failure events shown as a pie chart or other chart adding up to 100%. Also, we frequently hear television announcers citing the latest study where they say things like “X percent of all home accidents are caused by poor lighting” or “Y percent of deaths are caused by cigarette smoking”. The idea that an accident occurred or a piece of equipment broke down because of the error of a single person or a simple design error would be nice – but usually it doesn’t hold up to scrutiny in the real world. 
 Utilizing Analytical Ferrography for Root Cause Analysis and Failure Prevention Analytical Ferrography, when performed with other analysis tests, is capable of determining the Root Cause of failure, which can lead to failure prevention. 
 What Is Root Cause Failure Analysis? courtesy of Reliability Center, Inc. 
 What is the difference between Failure Analysis (FA), Root Cause Analysis (RCA) and Root Cause Failure Analysis (RCFA)? 
 What is the Ultimate Goal of Implementing RCA? No matter what Root Cause Analysis (RCA) process that your firm has decided upon, "What is considered a successful RCA effort?" 
 Who Said That???!!! 
 Why Asking "Why?" Doesn't Work 
 Why Engine Thrust Bearings Fail 
 Why Root Cause Analysis Doesn't Always Work When performing true RCA, getting to the causes is the easy part, getting something done to eliminate the causes is a whole different story. Courtesy of Reliability Center, Inc. 
 Why The Power Supply Failed - Part 1 Results of the invesitgation into the Auckland Power Supply failure of 1998 - requires free Adobe Acrobat Reader for viewing. 
 Why The Power Supply Failed - Part 2 Results of the invesitgation into the Auckland Power Supply failure of 1998 - requires free Adobe Acrobat Reader for viewing. 
 Why The Power Supply Failed - Part 3 Results of the invesitgation into the Auckland Power Supply failure of 1998 - requires free Adobe Acrobat Reader for viewing. 
 Why The Power Supply Failed - Part 4 Results of the invesitgation into the Auckland Power Supply failure of 1998 - requires free Adobe Acrobat Reader for viewing.

E-mail safety tips on: 
Chain letters - how to deal with them. 
Hoaxes, rumors and urban legends - how to tell the difference between a hoax and reality. 
Phishing - tips for protecting yourself from deceptive e-mails. 
Scams and fraud - how others will try to trick you. 
Spam - what you can do about junk e-mail. 
Spoofing - when your e-mail isn't your e-mail... 
Viruses - protecting yourself from e-mail viruses and how to spot a fake. 

Basic e-mail safety tips:
Change your password often and keep it in a safe place
Don’t share the password with anyone.
Don’t open any attachments from anyone unless they are run through an anti-virus program.
Log off when done.
Don’t reply to spam, harassing, or offensive e-mail or forward chain e-mail letters. 
Use common sense and keep personal information personal.
Delete all e-mails, unread, from people you don’t know
Don’t be caught by the spammers’ favorite trick, “Remember me?”