software

software

Computer instructions or data. Anything that can be stored electronically is software. The storage devices and display devices are hardware.

The terms software and hardware are used as both nouns and adjectives. For example, you can say: "The problem lies in the software," meaning that there is a problem with the program or data, not with the computer itself. You can also say: "It's a software problem."

The distinction between software and hardware is sometimes confusing because they are so integrally linked. Clearly, when you purchase a program, you are buying software. But to buy the software, you need to buy the disk (hardware) on which the software is recorded.

Software is often divided into two categories:

systems software : Includes the operating system and all the utilities that enable the computer to function.

applications software : Includes programs that do real work for users. For example, word processors, spreadsheets, and database management systems fall under the category of applications software.

How to design a computer program

This tutorial assumes you're designing a standalone computer program that runs with a conventional GUI or command-line interface, but many of the techniques can also apply to programs that will become part of a bigger system. It's the next in a series after "So you've just been given your first programming assignment" and expands on what goes on during Step 7 of that tutorial: Sketching a plan of attack. It'll introduce you to the most important principles of program design and gloss over some illustrative examples and specifics.

A standalone program is one that is justified all by itself, like a word processor or a game, but even if it was a cog in a bigger system it'd still have the same qualities: it would focus on one job, it would take some kind of input that the system produces and transform it into some kind of output that the user or system consumes. Some examples of good standalone programs are:


Address book

Spreadsheet

Calculator

Trip planner

Picture editorWhereas a program designed to be part of a larger system can be something like:



A program that imports purchase orders and saves them to a database

A program that prints packing slips for orders stored in a database

A web browser

An email client

An MP3 player



The first set of programs are all useful on their own, but the second set all need something else to complete them such as a web server or email server. Even the MP3 player needs a program that can create new MP3 files for it to play. The impact to you is that the second set of programs have to cooperate with some kind of protocol or file format that you didn't design yourself, and so they become part of your spec. In this tutorial I'm going to ignore that aspect so I can concentrate on the basics.



What is the difference between designing and coding?



There is no difference between designing a program on paper and coding it, but code tends to be harder to understand and change. So the goal of the paper planning phase is to invent a pattern that helps you understand the code and isolate it from changes made in other parts of the program. In fact, most of your time will be spent creating ways to isolate code from changes made to other code, and most of this tutorial will be about how you can do this one thing.



A popular metaphor for design versus coding is the architect who gives blueprints to the builder, and the builder represents the programmer. But it's an imperfect metaphor because it forgets the compiler, which does the same thing as the builder in the architect metaphor. If we revised the metaphor then the architect would have to go through three phases to design a bridge: come up with a way to organize the blueprints, then come up with a way to prevent changes in the design of the bolts or girders from forcing a redesign of the entire bridge, and then design the bridge.



In real life construction projects the builders also co-design the bridge along with the architect because they discover problems that the architect missed, even offering solutions for them based on their expertise as builders. Not just problems with the measurements and materials either, but problems with the landscape, weather and budget. With programming the compiler will be a co-designer because it'll also tell you about problems you missed. Not just problems with the syntax, but problems with the way you use types. Many modern compilers will go as far as to suggest ways to fix those problems based on the expertise of the programmers who made it.



What makes a language "expressive"?



The more work you can imply with a single symbol or keyword, and the more open a symbol is to modification by other symbols, then the more expressive the language is.



For example, the loop. First we had to define loops by initializing a counter, then establishing a label for the beginning of the loop, and then increment the counter, test for a condition, and GOTO the beginning of the loop again:





10 DIM i = 1



20 PRINT i



30 i = i + 1



40 IF i < 10 GOTO 20



Then languages got to be a little bit more expressive, and it took less work to say the same thing:



for (int i = 0; i < 10; i++)



print(i);



The new language added symbols and syntax that encapsulated more meaning, not just making it easier to see that it was a loop, but even the syntax for incrementing the counter got shorter.



These were symbols that implied a lot of meaning, but there's also the ability to modify the meaning of symbols:



Tomorrow = Now + "24 hours"



Not only was the plus operator overloaded to perform the appropriate arithmetic on dates, but implicit conversion was invoked to convert the string literal into a timespan value.



This is why the choice of language has a big impact on how much design work you'll do on paper before you begin coding. The more type checking and static analysis the compiler does and the more expressive the language is then the easier it is to organize and isolate code. Imagine that languages could be placed on a graph like the one below. Here we see that assembly languages require the most planning in advance of coding, but DSLs (Domain Specific Languages) can be so specialized for their task that you can jump into coding almost right away.



The numbers on this graph have been exaggerated to illustrate the idea, but the gist is that every language aims to sit somewhere between intense planning and carefree coding. And even though it seems like it would be nice to operate at the bottom-right corner all the time, it isn't necessarily an advantage; one of the trade-offs of expressibility in any language--human or computer languages--is applicability. Every abstraction comes at a price that makes the language less appropriate for some other task.







Even if your problem lives at the bullseye of a language's target there will still never be a language so expressive that you'll never need any kind of paper-planning. There will only ever be languages that make it safer to move into coding earlier.



How to think about the design of a program

All programs transform input into output, even if that input was hard-coded into the source at design-time. It's obvious enough to be forgotten and programmers can get so lost in the fuss of implementing features that they forget what the real purpose of the program was. Proper design can help you and your team mates avoid losing sight of the real goal.

The code that does the conversion is called the business logic. The business logic will act on data structures called the model. Your program will need to convert (or "deserialize") its input into the model, transform it, and then serialize the model into output. The model will be whatever makes it easiest to perform the transformation and does not need to resemble what the user thinks of the data as. For example, a calculator converts decimal numbers into binary, performs arithmetic on them there, and then converts the binary back into decimal. The binary representation of the decimal numbers is the calculator's model.

Everything else is called overhead, and that will be code that implements the user interface, sanitizes the input, creates connections to services, allocates and disposes of memory, implements higher-level data structures like trees and lists and so-on. One of your goals will be to separate the overhead from the business logic so that you can make changes to one without having to modify the other.



Some mistakes to avoid at this stage:



Don't create a class or module called "BusinessLogic" or similar. It shouldn't be a black-box. Later I'll discuss how to structure this code



Don't put business logic in a library1. You'll want the ability to change it more often than the overhead, and libraries tend to get linked to other programs--multiplying the consequences of changing it



Don't put business logic or overhead into the model unless it's only enforcing constraints. The code that defines the model should expose some interfaces that let you attach what you need. More on that later



Some of the things that you can include in the model is code that enforces meaningful relationships. So if your genology program has a "Person" class with an "Offspring" collection then you should include code in the model that prevents a person from being their own grandparent. But the function to discover cousin relationships in a family tree is business logic and doesn't belong in the model. Although it might make sense that you can't be your own cousin, and that this rule could be enforced in the model, you also need to draw a line between what enforcement is necessary to prevent common bugs and what's going to create complex bugs through mazes of logic that are difficult to follow.



1 - "Anything Is Appropriate As Long As You Know What You're Doing." One man's business logic is another man's overhead, and your project might be packaged as a library to be consumed by a bigger system. This rule is meant to apply to the point you're at in the food chain.



Top-Down versus Bottom-Up



Top-Down programming is about writing the business logic first in pseudocode or non-compiling code and then working down to the specifics, and it's the first program design technique taught in schools. Lets say that you're designing a coin-counting program, and you write what you want the perfect main() to look like:



void main()

{

CoinHopper hopper = new CoinHopper(Config.CoinHopperHardwarePort);

decimal deposit = 0;

while (hopper.count > 0)

{

CoinType coin = hopper.next();

deposit += coin.value;

}

decimal processingFee = deposit * 0.08;

Output.Write("Total deposit: ${0}, processing fee: ${1}, net deposit: ${2}",

deposit,

processingFee,

deposit - processingFee);

}



The program doesn't compile yet, but you've now defined the essence of the program in one place. With top-down programming you start like this and then you focus on defining what's going on in the CoinHopper class and what abstraction is going on in the Output class.



Bottom-up programming is the natural opposite, where the programmer intuits that he'll need a way to control the coin counting hardware and begins writing the code for that before writing the code for main(). One of the reasons for doing it this way is to discover non-obvious requirements that have a major impact on the high-level design of the program. Lets say that when we dig into the nitty-gritty of the API for the hardware we discover that it doesn't tell us what type of coin is there, it just gives us sensory readings like the diameter and weight. Now we need to change the design of the program to include a module that identifies coins by their measurements.



What usually happens in the real-world is that all of the top-down design is done on paper and the actual coding goes bottom-up. Then when the coding effort falsifies an assumption made on paper the high-level design is easier to change.



"A further disadvantage of the top-down method is that, if an understanding of a fault is obtained, a simple fix, such as a new shape for the turbine housing, may be impossible to implement without a redesign of the entire engine." - from Richard Feynman's report of the Space Shuttle Challenger Disaster

High-level design patterns



"Design patterns" might have come into the programmer's lexicon around the time a book by the same name was published, but the concept has existed since the dawn of man. Given a problem, there are certain traditional ways of solving it. Having windows on two adjacent walls in a room is a design pattern for houses that ensures adequate light at any time of day. Or putting the courthouse on one side of a square park and shops around the other sides is another kind of design pattern that focuses a town's community. The culture of computer programming has developed hundreds of its own design patterns: high level patterns that affect the architecture of the whole program--forcing you to chose them in advance--and low-level patterns that can be chosen later in development.



High-level patterns are baked into certain types of frameworks. The Model-View-Controller (MVC) pattern is ubiquitous for GUIs and web applications and nearly impossible to escape in frameworks like Cocoa, Ruby-on-Rails, and .Net, but that doesn't mean you have to use it for every program; some programs don't have to support random user interaction and wouldn't benefit from MVC.



MVC is well described elsewhere, so here are some of the other high-level patterns and what they're good for.



The 1-2-3



This is the first pattern you learned in programming class: the program starts, asks the user for input, does something with it, prints it out and halts. One-two-three. "Hello world" is a 1-2-3. It's the simplest pattern and still useful and appropriate in many situations. It's good for utilities, housekeeping tasks and one-off programs.



One of the biggest mistakes made by programmers is to get too ambitious. They start designing an MVC program, take weeks or months to code and debug it, but then it dwarfs the magnitude of the problem. If someone wants a program that doesn't need to take its inputs randomly and interactively, then produces a straightforward output, then it's a candidate for 1-2-3.



The Read-Execute-Print Loop (REPL)



REPL is the 1-2-3 kicked up a notch. Here the program doesn't halt after printing its output, it just goes back and asks for more input. Command-line interfaces are REPLs, and most interpreted programming languages come with a REPL wrapped around the interpreter. But if you give the REPL the ability to maintain state between each command then you have a powerful base to build simple software that can do complex things. You don't even need to implement a full programming language, just a simple "KEYWORD {PARAMETER}" syntax can still be effective for a lot of applications.



The design of a REPL program should keep the session's state separate from the code that interprets commands, and the interpreter should be agnostic to the fact that it's embedded in a REPL so that you can reuse it in other patterns. If you're using OOP then you should also create an Interface to abstract the output classes with, so that you aren't writing to STDOUT directly but to something like myDevice.Write(results). This is so you can easily adapt the program to work on terminals, GUIs, web interfaces and so-on.



The Pipeline



Input is transformed one stage at a time in a pipeline that runs continuously. It's good for problems that transform large amounts of data with little or no user interaction, such as consolidating records from multiple sources into a uniform store or producing filtered lists according to frequently changing rules. A news aggregator that reads multiple feed standards (like RSS and Atom), filters out dupes and previously read articles, categorizes and then distributes the articles into folders is a good candidate for the Pipeline pattern, especially if the user is expected to reconfigure or change the order of the stages.



You write your program as a series of classes or modules that share the same model and have a loop at their core. The business logic goes inside the loop and treats each chunk of data atomically--that is, independent of any other chunk. If you're writing your program on Unix then you can take advantage of the pipelineing system already present and write your program as a single module that reads from stdin and writes to stdout.



Some language features that are useful for the Pipeline pattern are coroutines (created with the "yield return" statement) and immutable data types that are safe to stream.



The Workflow



This is similar to the Pipeline pattern but performs each stage through to completion before moving onto the next. It's good for when the underlying data type doesn't support streaming, when the chunks of data can't be processed independently of the others, when a high degree of user interaction is expected on each stage, or if the flow of data ever needs to go in reverse. The Workflow pattern is ideal for things like processing purchase orders, responding to trouble tickets, scheduling events, "Wizards", filing taxes, etc..



You'd wrap your model in a "Session" that gets passed from module to module. A useful language feature to have is an easy way to serialize and deserialize the contents of the session to-and-from a file on disk, like to an XML file.



The Batch Job

The user prepares the steps and parameters for a task and submits it. The task runs asynchronously and the user receives a notification when the task is done. It's good for tasks that take more than a few seconds to run, and especially good for jobs that run forever until cancelled. Google Alerts is a good example; it's like a search query that never stops searching and sends you an email whenever their news spider discovers something that matches your query. Yet even something as humble as printing a letter is also a batch job because the user will want to work on another document while your program is working on queuing it up.



Your model is a representation of the user's command and any parameters, how it should respond when the task has produced results, and what the results are. You need to encapsulate all of it into a self-contained data structure (like "PrintJobCriteria" and "PrintJobResults" classes that share nothing with any other object) and make sure your business logic has thread-safe access to any resources so it can run safely in the background.



When returning results to the user you must make sure you avoid any thread entanglement issues. Framework classes like BackgroundWorker are ideal for marshaling the results back onto the GUI.



Combining architectural patterns



You can combine high-level patterns into the same program, but you will need to have a very good idea of what the user's problem is because one model will always be more dominant than the others. If the wrong model is dominant then it'll spoil the user's interaction with the program.



For example, it wouldn't be a good idea to make the Pipeline dominant and implement 1-2-3 in one of its modules because you'll force the user to interact excessively for each chunk of data that goes through the pipeline. This is exactly the problem with the way file management is done in Windows: you start a pipeline by copying a folder full of files, but an intermediate module wants user confirmation for each file that has a conflict. It's better to make 1-2-3 dominant and let the user define in advance what should happen to exceptions in the pipeline.



User Interface patterns



A complete discussion of UI patterns would be beyond the scope of this tutorial, but there are two meta-patterns that are common between all of them: modal and modeless. Modal means the user is expected to do one thing at a time, while modeless means the user can do anything at any time. A word processor is modeless, but a "Wizard" is modal. Regardless of what the underlying architectural pattern is, the UI needs to pick one of these patterns and stick to it.



Some programs can mix the two effectively if the task lends itself, like tax-filing software because it lets you jump to points randomly in the data entry stage, but doesn't let you move onto proofing and filing until the previous stage is complete.

Almost all major desktop software is modeless and users tend to expect it. To support this kind of UI there are two mechanisms supported by most toolchains; event-driven and data binding.



Event driven



Sometimes called "call-backs", but when they're called "Events" it's usually because they've been wrapped in a better abstraction. You attach a piece of code to a GUI control, and when the user does something to the control (click it, focus it, type in it, mouse-over it, etc) your code is invoked by the control. The call-back code is called a handler and is passed a reference to the control and some details about the event.



Event-driven designs require a lot of code to examine the circumstances of the event and update the UI. The GUI is dumb, knows nothing about the data, needs to be spoon-fed the data, and passes the buck to your code whenever the user does something. This can be desirable when the data for the model is expensive to fetch, like when it's across the network or there's more than can fit in RAM.



Events are an important concept in business logic, overhead and models, too. The "PropertyChanged" event is very powerful when added to model classes, for example, because it fits so well with the next major UI mechanism below:



Data Binding



Instead of attaching code to a control you attach the model to the control and let a smart GUI read and manipulate the data directly. You can also attach PropertyChanged and CollectionChanged events to the model so that changes to the underlying data are reflected in the GUI automatically, and manipulation on the model performed by the GUI can trigger business logic to run. This technique is the most desirable if your model's data can be retrieved quickly or fit entirely in RAM.



Data binding is complemented with conventional event-driven style; like say your address-book controls are bound directly to the underlying Address object, but the "Save" button invokes a classic Event handler that actually persists the data.



Data binding is extremely powerful and has been taken to new levels by technologies like Windows Presentation Foundation (WPF). A substantial portion of your program's behavior can be declared in data bindings alone. For example: if you have a list-box that is bound to a collection of Customer objects then you can bind the detail view directly to the list-box's SelectedItem property and make the detail view change whenever the selection in the list-box does, no other code required. A perfectly usable viewer program can be built by doing nothing more than filling the model from the database and then passing the whole show over to the GUI. Or like MVC without the C.



What it'll mean for the design of your program is greater emphasis on the model. You'll either design a model that fits the organization of the GUI, or build adaptors that transform your model into what's easiest for the GUI to consume. The style is part of a broader concept known as Reactive Programming.



Designing models



Remember that your data model should fit the solution, not the problem. Don't look at the definition of the problem and start creating classes for every noun that you see, and nor should you necessarily create classes that model the input or output--those may be easily convertible without mapping them to anything more sophisticated than strings.



Some of the best candidates for modelling first are actions and imaginary things, like transactions, requests, tasks and commands. A program that counts coins probably doesn't need an abstract Coin class with Penny, Nickel, Dime and Quarter dutifully subclassing it, but it should have a Session class with properties to record the start time, end time, total coin count and total value. It might also contain a Dictionary property to keep separate counts for each type of coin, and the data type representing the coin type may just end up being an Enum or string if that's all it really needs.



Once you've modeled the actions you can step forward with your business logic a little until you begin to see which nouns should be modeled with classes. For example, if you don't need to know anything about a customer except their name, then don't create a Customer class, just store their name as a string property of an Order or Transaction class2.



2 - There can be a benefit to creating "wrappers" for scalar values for the sake of strong-typing them. In this case Customer would just store a name, but the fact that it's an instance of Customer means the value can't be accidentally assigned to a PhoneNumber property. But I wouldn't use this technique unless your language supports Generics (more below).



Organizing business logic



Earlier I said that it's bad form to create a class called BusinessLogic and cram it all in there because it makes it look like a black box. Let's say our coin-counter's business logic can be expressed as "Count all US-issue coins, discard foreign coinage and subtract an 8% processing fee." Our design has evolved since our first attempt and now we have two classes: Tabulator and CoinIdentifier.



CoinIdentifier has a public static method that takes input from the coin sensors in the machinery and spits out a value that identifies what kind of coin it is. It's probably going to need changes once a year or less as new coins are issued, so we have a good reason to isolate it from the rest of the code.

Tabulator handles a CoinInserted event raised by the hardware and passes the sensor data--contained within the event's arguments--to CoinIdentifier. Tabulator keeps track of the counts for all coin types regardless of whether they're US-issue or not. The essence of this code is the least likely to change, so we make sure it doesn't have to know how to identify coins or judge what ought to be done with them.



Tabulator raises a CoinCounted event instead, and we put its handler in the main module of the program to decide whether to keep the coin or eject it into the returns tray. The code which is the most likely to change frequently--like which coins to reject and how much to keep as a processing fee--stays in the main module, with constants like the processing fee read from a configuration file.



Organizing business logic means grouping it by purpose, avoiding bundles of unrelated functions, and creating Interfaces that let us connect the modules while insulating them from changes in each other. Another benefit is that well isolated code is easier to test in isolation, and that makes it safer to change other code without forcing a re-test of everything that uses it.



Keeping models, overhead and business logic separate



The last topic I'll discuss in this tutorial is also the most important, because it gives you more flexibility to change the higher-level design. The future maintainability of your code depends on it, but in large projects even the initial coding will succeed or fail on this principle.



This is what most of the book Design Patterns is about. If you buy it then be aware that some of its patterns may be obsolete in your language because they've been absorbed into language features. The "Iterator" pattern, for example, is now hidden in a language feature called list comprehensions. The pattern is still there, but now it's automatic and the language just became more expressive.



New patterns are being invented all the time, but these are the basic principles they all strive for:



Overhead code needs to be as program-agnostic as possible



Assume that every line of business logic and every property of the model will change and that the overhead code should expect it. You can do this by pushing that overhead code into its own classes and using Interfaces on models and business logic to define the very least of what the overhead needs to know about an object. You can also now find languages like Java, C# and Visual Basic that support Generics, which extend the type-checking power of the compiler (and by extension, the IDE). Here's how to make them work for you:



Use Interfaces to abstract an object's capabilities



If your overhead code needs to do something to an object then put an Interface on that object's class that exposes whatever is needed. For example, your overhead code has to route a message based on its destination, so the message class would implement an interface you'd call IDeliverable that defines a Destination property



Use Generics to abstract an algorithm's capabilities



When an algorithm doesn't care what kind of object its manipulating then it should use generics to make the algorithm transparent to the type-checking power of the compiler



Defer specifics until runtime



Near the beginning I said that every program transforms input into output, and that input will include more than just what the user types or clicks after the program starts. It's also going to include configuration files and, for the sake of clarity, you can even consider your program's main() module to be like a compiled and linked configuration file; its job is to assemble the abstracted pieces at the last minute and give them the kiss of life.



You can defer specifics with a design principle called Inversion of Control (IoC). The simplest expression is when you pass objects that know their own specifics into methods that don't, such as when a Sort() algorithm takes collections of objects that all implement IComparable. Sort() doesn't need to know how to compare two objects, it just churns through them calling object1.Compare(object2). The code for Sort() concerns only what Sort() does, not what's peculiar about the things it's sorting.



Blocking events



Events can be used to invert control and pass the buck up the chain, too, and when the child code waits for the event to be handled--rather than continuing on asynchronously--we say it's a blocking event. Event names that begin with Resolve often want the parent code to look for something it needs. An XML parser, for example, might use a ResolveNamespace event rather than force the programmer to pass all possible namespaces or a namespace resolving object at the beginning. The handler has the job of finding the resource and it passes it back by setting a property in the event's arguments.



Dependency Injection



A more complex expression of IoC is called Dependency Injection (DI). This is when you identify a need--such as writing to different kinds of databases or output devices--and pass implementations of them into an object that uses them. Our Tabulator class from earlier, for example, could be passed an instance of the exact breed of CoinIdentifier in its constructor. We have one that works on US coins and another that works on Canadian, and a configuration file tells the main() which one to create.



The second method of DI is to call a static method from within the class that needs the resource. This is popular for logging frameworks: say your class has a member called _logger and in your constructor you set it by calling the static method LogManager.GetLogger(). GetLogger() in turn implements the Factory design pattern to pick and instantiate the appropriate kind of logger at runtime. With a tweak to a config file you can go from writing to text files to sending log events over the network or storing them in a database.



To chose between the two I like to consider how critical the dependency is to the purpose of the module. When the dependency is critical I pass it as a parameter to the constructor so that it's clear and explicit what's going on in your code. When it's for a side-concern like logging I hide them with calls to static methods because I want to avoid ruining the readability of the business logic.



A third method is to use a dependency injection framework like Ninject or Unity. These support more sophisticated methods for both explicit and implicit injection of the dependency, but they're only worth if if your design uses DI extensively. Manual DI has a sweet spot of around 1-to-3 injections per object while frameworks start at about 4 or more. One of the problems they bring is more configuration and prep time before they're usable, and overdosing on them can hide too much.



Parting shots



Don't O.D. on third-party structural libraries



There's you, the language's vendor, and Bob who has this wicked awesome Dependency Injection framework and Monad library. One... maybe two Bob's Frameworks are okay, but don't overdose on them or even you won't know how your program works



Brevity is the soul of an Interface



When you design interfaces for your classes to abstract their capabilities, remember to keep them short. It's normal for an Interface to specify only one or two methods and for classes to implement 5 or 6 Interfaces



Explain your program through its structure



See if you can group your functions into classes and name those classes so that when you look at the project tree you can sense what the program does before you even look at the code



Embrace messiness... and refactoring

During development (and deadlines) it's normal to smudge overhead code and business logic into places they don't belong before you can figure out what patterns will separate them again nicely. It's okay to be messy, but it's important to clean up afterwards with some refactoring

How to Use Windows Remote Desktop

In this tutorial, we'll go step-by-step to show you how to connect to a remote computer. We'll discover the different addresses we can enter into the client program, to establish the remote connection. In addition, we'll figure out how to bring up the remote connection via a Web browser.


Connecting to Your PC with the Traditional Client

Now you're all ready to remotely connect to your PC either from another computer on your network or from any computer on the Internet. First, we'll connect using the traditional client program (called Remote Desktop Connection) that's installed by default on most Windows versions.

Start>All Programs>Accessories>Remote Desktop Connection

Once the program loads, you can enter the path to your Remote Desktop PC into the Computer field and hit the Connect button. It's that simple. You have, though, a few different items you can use as a path, which include:

Computer Name: This is the Computer Name value of the computer that Windows uses to help you identify computers on a local network. You can use this only when you are on the same network as the Remote Desktop computer, not if you are connecting from a computer outside your home or office. You can find this value on a computer by right-clicking the My Computer or Computer icon on your desktop or the Start menu, clicking Properties, and if in Windows XP, you need to click the Computer Name tab. Windows Remote Desktop.

Local IP Address: This number (such as 192.168.1.103) also helps identify computers on a local network, and it is used by the network components when sending and receiving data. Like with the Computer Name; you can use this only when you are on the same network. You can find a computer's IP address by looking through the network connection status details in Windows.

Internet IP Address: This number is the IP address of your Internet connection or modem, assigned by your Internet service provider (ISP), used to identify computers or networks on the Web. This is the number you want to use when connecting to your Remote Desktop PC when away from the home or office. You can find your Internet IP address on your router's status pages, under the WAN or Internet section, or you can Google it to be detected by a Web site service. A word of caution: Your Internet IP changes, anywhere from daily to monthly, if you have a dynamic IP address. This type of address is typical on most residential, and even small business, Internet connections. You can call your ISP to see if you have a dynamic IP address or a static address.

Domain or Host Name: If you have a dynamic IP address (or you don't want to remember a static address), it's best to use a domain or host name to connect to your Remote Desktop PC. This requires signing up for a service (a few free ones are DynDNS, FreeDNS.afraid.org, and No-IP) and configuring your router with your account details so your host name stays updated when your IP address changes.

Connecting to Your Windows XP PC via Web Browser

If you followed the directions to set up Web access of your Remote Desktop PC, you should now be able to bring up your computer with a Web browser. Open a Web browser, enter the URL, and hit the Enter key. The URL consists of http://YourIPAddress:PortYouChoose/tsweb/.

You only have to type colon and the port number if you changed the default port 80 to something else. If you are connecting to the Remote Desktop from a computer on the local network, you can use the PC's local IP address rather than the Internet IP address. However, if you are connecting from elsewhere, you must use your Internet IP address. Reference the bullets in the previous section for more on these addresses as well as info on domain or host names that you could use in place of an IP address when connecting via the browser.

If you're prompted to install the Remote Desktop ActiveX control, click Yes. On the Remote Desktop Web Connection page click Connect. You don't need to fill in the Server field. If you leave the default Size set to Full-screen, it will try to use the traditional client program if it's installed. Otherwise you'll see the Remote Desktop screen in your browser at the size you specify.

Wrapping It Up

Now you should be able to remote into your PC from the next room or from around the globe. If you run into problems and can't connect using the client program or the Web access page doesn't load, double check your firewall and router settings.

We'll leave you with a few tips to commit to memory:

Remember your PC must be plugged in and turned on to remotely connect to it. Remember to disable any automatic sleep, hibernation, or stand-by features on your PC.

Keep Windows up-to-date with critical and recommended updates to make sure you're protected from the latest known security holes.

Make sure Windows Firewall, or another third-party solution, is always on and protecting against hackers.

Even when connecting to a PC via the Web browser, the host computer must also have the traditional Remote Desktop feature enabled.

Research Server Options

Research Server Options

Bring It All Together: Once you have a good idea what you are looking for in a server, a reseller or consultant can help you translate your needs into server specifications. Today’s server technology allows many small businesses to buy a single heavy-duty server that packs a punch. As your organization grows, so will the number of servers you require the time and skills needed to manage them. Keeping a single server running efficiently is a very different matter to managing a large number of servers.

A good rule of thumb when buying a small business server is to look for a small business section on the vendor websites to see what processing power, memory and storage space is offered at different price points.

Congratulations! Now you understand how to determine if your small business needs more than one server.

Server Checklist

Server Checklist

To determine the type and number of servers you need, the first step is to determine how the server will be used and who it will be used by. The following checklist will help you determine how much server processing power your business will need:

What problems are you trying to solve by using a server?

How many employees will access and use the server?

What software will the server need to run?

How fast do you need the server to process data?

What type of server do you need?

How much memory and disk space will you require?

Do you plan to upgrade in the future?

Choosing a Server

Choosing a Server

Choosing the Right Server

Choosing the Right Server: At a certain point, it makes sense to relieve the burden of an individual user's computer by having a dedicated server that is capable of providing file storage and print services – or any other services that may be required – to all the users in the organization. Before investing in a server and choosing the right server hardware, you need to consider many things, including the applications you will run, storage, processor, form factor, and more.

Processing Power

Processing Power

Server Processing Power Explained

To ensure your server meets your business needs you must first understand server processing power and know exactly how you want to use your server. The role of a server is to manage network resources. There are many different types of servers, such as a file, print or database server. These are the most common types of servers a small business will need to invest in.

Do I Need More Than One Server?

Do I Need More Than One Server?

Server Memory and Storage Needs

When using a server for your small business, one benefit you'll realize is that a server can be customized and configured to meet your specific needs and budget. Many file and print servers (the most common type of server for small business needs) will not cost much more than a high-end desktop (see How is a Server Different from a Desktop?). Proper planning will ensure you purchase a server with enough power. The number of servers required depends on how much server processing power you need to support your number of users and applications you run.
Continue reading to better understand server processing power.

Server Cost Summary

Server Cost Summary

Server Cost Summary

Adding a dedicated server to your business is no simple matter. The hardware, software and administration costs can quickly get out of hand if you don't have a solid plan in place and a budget that accurately accounts for each of these areas. This is one reason many businesses that can't get past the initial "sticker shock" of a dedicated server look at virtual servers as an alternative.

Virtual servers are servers that are hosted online and managed by a hosting company. The ongoing costs associated with hosted servers are not exactly inexpensive either, but that's a topic for another time.

Congratulations! You now understand how much a server costs and what’s involved in budgeting for a new server.

Cost to Administer a Server

Cost to Administer a Server

Server Memory and Storage Needs

In most cases, a server's hardware and software costs represent only a small part of the total cost of ownership for a server. In fact, the hardware and software costs typically account for only 15 to 25 percent of the overall costs associated with installing, maintaining, upgrading and supporting a dedicated server.

For many businesses, the server becomes the lifeline to its success and any downtime can be disastrous, making it critically important to invest in your server's ongoing operation. As a result, when budgeting for a server, it's necessary to create a solid plan for the costs associated with configuring and administering your server – costs that include initial configuration and ongoing support fees, workforce costs for day-to-day administration, reserve funds for replacing hardware as warranties expire, software update fees and more. A reseller or IT consultant can provide specific guidance in this area to ensure that you're allocating the resources necessary to ensure that once your server is up and running, it stays that way.

Windows Messenger vs. MSN Messenger

Windows Messenger vs. MSN Messenger

Both Windows Messenger and MSN Messenger are Instant Messaging (IM) client applications. Although there are some distinct differences between the two applications:

Windows Messenger is an IM client designed for use in a business environment. This client is designed to communicate with Microsoft's Office Live Communications Server 2005 server, as well as communicating with MSN Messenger. Windows Messenger communications is also encrypted.

MSN Messenger is designed for use as a consumer IM client application, that can only communicate with the MSN Messenger Service. Communications with this client is not encrypted, as they are with Windows Messenger.

Cost of Server OS and Apps

Cost of Server OS and Apps

Server Map

The server you purchase may or may not include a server operating system. When it comes to selecting your own server operating system, high-end server OSes like Windows Server 2008 R2 start at about $1,000 for up to five users (five client access licenses, or CALs) and $4,000 for the Enterprise edition, which includes 25 CALs. If you’re looking for a less expensive alternative you have plenty of options as well, including Mac OS X Server ($499 with unlimited client licenses), Microsoft Small Business Server (approximately $550 with support for up to 25 users) and a variety of enterprise Linux server distributions that range from free to $1,000 or more for an annual support subscription.

You'll also need to budget for the software applications your server will need in order to perform its tasks. The dollar amounts can add up quite quickly in this area – for example, to handle e-mail services you'll need an application like Microsoft Exchange Server, which starts at $699 for the Standard edition and $3,999 for the Enterprise edition; for database services an app like Microsoft SQL Server will cost nearly $900; and for file sharing and online collaboration, options like Microsoft's Sharepoint Server or Citrix Presentation Server can cost anywhere from $400 to $3,000 or more.

Cost of Server Hardware

Cost of Server Hardware

Cost of Hardware

The tasks your business will need your server to perform as well as the number of users it's expected to serve will largely determine your server's hardware costs. While servers are almost always more expensive than their desktop counterparts, those on a tight budget can find low-cost server options that handle many if not all of the tasks your business will likely need from a server.

If your server will primarily be used for tasks like print serving and office document file sharing among fewer than 25 users, a server with a low-end processor, as little as 1GB to 2GB of RAM, and 500GB to 1TB of RAID storage will most likely suffice, and should cost your business as little as $400. SmallBusinessComputing.com has a helpful server buyer's guide that lists several small business server options that range from $499 to a little over $1,000.

On the other end of the scale are high-end servers for tasks like data-intensive Web and database serving, video storage and sharing and enterprise-grade messaging and conferencing. These servers will typically include multiple processors, 16GB or more of RAM, expansive storage with multiple redundancies, and a high-end server operating system, and they can cost in the thousands or tens of thousands of dollars. High-end servers may also be deployed in multiple server configurations known as clustering

How Much Will a Server Cost?

How Much Will a Server Cost?

How Much Will a Server Cost?Once you've determined that your business needs a server, one of the first questions you're likely to have involves how much the new server will cost. While the server and its hardware costs are the numbers you're most likely to see quoted, in most cases these represent only a small part of the total cost of ownership for a new server. The three main components to a server's overall costs are:

- Cost of hardware

- Cost of server operating system and applications

- Cost to administer

Remote Desktop vs Remote Assistance

Remote Desktop vs Remote Assistance


When you first learn about 'Remote Desktop' and 'Remote Assistance', you might wonder the difference between the two services. Both applications allow you to remotely control a PC from any where on your local or corporate network, and even over the Internet. Although there are some important differences between these two services.

The Remote Desktop service is only available as part of Windows XP Professional Edition. This service allows you to take control of the remote computer without first requesting access. To do this you have to have administrator rights on the local machine. Once logged in you will have complete control of the local computer.

The Remote Assistance is part of Windows XP Professional and Home Editions. To use this service the PC user has to make a request to you to be able to connect to the remote computer. Once you respond to the request, you will see the remote users desktop. This service requires you have Windows Messenger or MSN Messenger installed on your computer to receive the remote assistance request.

To enable the Remote Desktop or Remote Assistance services:

Open the Control Panel.
Double-click the System control panel.
Click on the Remote tab.
Check the Remote Desktop and/or Remote Assistance checkboxes.
Press the OK button when done.

Advantages of a Server

Advantages of a Server

The Server Role

While it may seem at first glance to be easier and more cost-effective to utilize a high-end desktop computer as a server rather than purchasing one, a dedicated server offers several key advantages that make it the better choice in most all cases. These advantages include increased reliability and performance, scalability, security, reduced administration and lower total cost of ownership.

And while a higher initial cost may be an inevitability with a server, there's a greater chance that over time your business will see reduced costs and increased user productivity with a dedicated server versus a stand-in high-end PC.

Congratulations! You now have a better understanding of the differences between a server and a high-end desktop computer as well as the benefits that a server can bring to your business!

Reduced Administration

Reduced Administration

Server Memory and Storage Needs

Reduced administration and long-term cost: While you can certainly expect a higher up-front cost when investing in a server as opposed to utilizing an existing high-end desktop, over the long run you're likely to see a lower total cost of ownership with a server for several reasons. First, with your server serving as a central resource controller there will be fewer components to have to support in terms of administration and maintenance. Additionally, with servers being designed to allow many users to share applications and connections to the Internet and wide area networks (WANs), a high-end server can reduce the need for duplication of hardware as well as additional computers in many cases.

Choose The Right Server

Choosing the Right Server -- Servers are the unsung heroes of the corporate computing environment, working behind the scenes to help get the maximum benefit from the personal computers that people use every day. Before investing in server hardware, you need to consider applications, storage, processor, form factor, and more.

Scalability and Security

Scalability and Security

The Difference between a Server and a Desktop Computer

Server Scalability: Servers are designed with scalability in mind, so as your business grows your server will have little trouble supporting increases of data, users and network traffic. While a high-end personal computer may meet the existing needs of a smaller business, there's a high probability that it won't be able to keep up as the company expands and its network needs increase.

 

Server Security: Security can be implemented more efficiently and effectively with servers, since critical business data resides on one central server computer as opposed to being spread out over a large number of computers and storage devices like flash drives. Backing up that data and preventing data loss in the case of a disaster are also much easier tasks when dealing with a central resource and data controller like a server.

Reliability and Performance

Reliability and Performance

Reliability and Performance

One of the most important differences between servers and high-end desktop computers is the use of higher quality hardware in servers that has built-in failproof protection in the form of redundancy. If a desktop component fails, it typically impacts only one user, whereas if a server component fails it can impact a large number of users or even an entire business.

Redundancy is particularly important for storage, where RAID (redundant array of inexpensive disks) is typically utilized to keep a server up and running even if a hard drive crashes, as well as for power, where backup power sources are utilized to keep a server operational even if the main power supply goes down. These components and other hardware in a server can typically be replaced with minimal or no disruption to users.

 
Servers also typically utilize hardware specifically tailored to the needs of businesses, including multiple processors and plenty of RAM to prevent performance degradation when supporting a large number of users.

Server vs. High-End PC

Server vs. High-End PC

High End Servers

Once you've determined that your business needs a server, one of the first questions you should ask is whether or not you can use a high-end desktops instead of having to invest in a new server. This is a common question, especially during these times of limited resources and tight budgetary constraints.

While a high-end PC can often work and function as a server in a pinch, especially for certain roles such as file serving, there are several reasons a dedicated server makes a better long-term investment. Some of a dedicated server's key advantages over a high-end PC include:

Reliability and Performance
Scalability
Security

Long-term Cost Savings

Server Replacement Options Summary

Server Replacement Options Summary

The Difference between a Server and a Desktop Computer

If you can gain performance benefits and/or cost efficiency by purchasing a new server, of if the likelihood of failure and risk of downtime becomes too great, you'll know it's time to replace your server. While hardware parts can fail at any time, with the higher-quality components used in servers as well as the built-in redundancy for failproof operation, in most cases you can expect your new server to last much longer than six months.

Choosing the Right ServerBefore investing in a new server, you need to consider its applications, storage, processor, and form factor, as well as the server's life expectancy and ROI.

Cost-to-Performance Ratio

Cost-to-Performance Ratio

The costs associated with your server's ongoing maintenance as well as employee productivity need to be weighed against the server's ability to perform its tasks efficiently and effectively.

Once you start to see performance degradation in your server or when components start to show signs of wearing down, you can expect increased costs to your business resulting from employees accomplishing less work or taking more time to get their work done as well as additional repair and maintenance expenses related to the ongoing operation of the server. As a result, a significant increase in the server’s cost-to-performance ratio is often a key

When Should I Replace My Server?

When Should I Replace My Server?

How will you know when it's time to replace your server? Ideally, you'll replace your server before it ever has a chance to break down, as most business can ill afford the downtime that comes from having a mission-critical server fail. For this reason, servers are typically replaced when the server service contract expires or when the cost-to-performance ratio gets too high.

Server service contract expiration

The purchase of a server typically includes a limited-period service contract through either the server vendor or a third-party service. Once this service contract is up it typically becomes very expensive to extend or add a new service contract – it’s not uncommon for a 1-year contract extension in year 5 or 6 of the server's life to cost close to half what a new server would cost. As a result, when a company's vendor service contract expires, most businesses either replace the server or transition it to handle tasks that aren't as critical to the ongoing operation of the business.

Server Life Expectancy

Server Life Expectancy

How Long Will My Server Last?

As with many purchases, in general you get what you pay for when buying a server. While a server purchased or acquired on a tight budget may only meet the needs of your business for a limited time or may become obsolete quicker than expected, the good news is that since servers are typically configured with built-in redundancy and high-quality, enterprise-grade components, in most cases you can expect your server to last much longer than six months.

Some servers can keep running smoothly up to a decade or longer, especially if they're used in less-demanding roles or if they support only a limited number of users. However, the more realistic timeframe for the life expectancy of a server is between three and five years. There are several key reasons to consider either replacing your server or transitioning it to handle less mission-critical tasks as it gets closer to four or five years of age

Will I Have to Replace My Server in Six Months

Will I Have to Replace My Server in Six Months

Server Life Expectancy

Once you've determined that your business needs a server and you've started researching how much it will all cost, you may find yourself concerned with the prospect of having to replace your new server in six months or so.

Before investing in a new server, you need to consider its applications, storage, processor, and form factor, as well as the server's life expectancy and ROI. Download this Internet.com eBook to help make sure you get off to the right start.

Tips And Tricks For New Computer Users

10 Basic Computer Tips And Tricks For New Computer Users


One of the worst things that can happen when you first start using computers is to have some kid sit down next to you and do everything you’re doing in half as much time, so we’ve put together 10 basic computer tips and tricks for new computer users that will improve your productivity and let you show up that kid.


Computer tips and tricks

We have loads of computer tips on this website and if you enjoy this article you must also see more top 10 computer tips.


Computer Tips #1: Find Text Quick With Ctrl-F

This is one of those important computer tips that you will use all the time. One of the things I find myself doing most frequently is trying to find one specific word or sentence within a much longer document or webpage. Happily, if you know what you’re looking for, Windows makes it easy to find it.

In almost every application, you can type Ctrl-F (F for Find) to find a word or series of characters. Ctrl-F works in Microsoft Word and Excel, all major Web browsers, Notepad, and many other applications. Go ahead and give it a try right now in your Web browser—search for the word “shortcut” in the next section.


Computer Tips #2: Put Programs On Your Desktop

You’ve probably already figured out that you can put documents, pictures, and other things you frequently use on your desktop, but you may not realize that you can also put your most often used programs on your desktop too. This is one of those computer tips that is often neglected.

Getting the program there is a little tricky, but it’s certainly a lot quicker than scrolling through your giant Start menu to find the program each time.

First, find the program in your Start menu, then place the mouse over the program and click the right-side mouse button once. Chose the option that says Create Shortcut On Desktop. The program icon should immediately appear on your desktop—now you can start it any time you want with a simple double-click. When you get to pro status you can re-size your desktop icons.


Computer Tips #3: Get Help Now

Confused? Need help but don’t know who to ask? Try checking the program’s built-in manual—almost every program has one, even if you don’t see a Help menu. Just press the F1 key on the top row of your keyboard.

Note: some smaller laptops and netbooks don’t have a F1 key. On these smaller keyboards, look for a key (often the number 1 key) with F1 written in small print (usually blue). Then look for a key labeled FN (for function). Press FN plus the F1 key to get the help manual.


Computer Tips #4: Use Keyboard Navigation

Probably the invention that made computers most accessible to the general pubic was the mouse. The mouse saves you from having to memorize a whole bunch of weird keyboard commands. But the mouse also has a downside—it’s kinda slow. (It’s also not easy to use if your hands shake.) Here is a guide to using a computer mouse.

You can give yourself a performance boost by using keyboard navigation. Look closely at the menus in a program like Microsoft Word and you’ll see many words have an underlined letter. To open the menu or activate the function with an underlined letter, press the Alt key plus that letter.

For example, to open the File menu in Microsoft Word, press Alt-F.

After a menu is open, you can activate specific options within it by pressing just the underlined letter—no Alt key is necessary. For example, to Save within the File menu, press s.


Computer Tips #5: Right-Click For Context Options

Wouldn’t it be nice if the computer knew what you wanted to do next? Well, it kind of does. Most programs have what’s called the “context menu”, where the computer guesses what you’d want to do in each part of the program and gives you a menu to do those things.

You can access the context menu by clicking the right mouse button. Try it right now in your Web browser. Depending on which Web browser you use and where you click on this page, you might see options like “view page source” or “open link in new window”.

To get these same options without the context menu, you’d either have to do a lot of clicking through menus or you’d have to memorize keyboard shortcuts. The context menu here saves you a lot of time.


Computer Tips #6: Pro Multi-tasking

Here is one of my favorite computer tips and probably the easiest. Do you switch programs a lot? I do. I’m often trying to read my research notes and write an article at the same time, forcing me to switch between two windows a lot.

But switching between two windows takes a long time with the mouse. You need to take one hand off the keyboard, grab the mouse, scroll over to the next window, click, and put your hand back on the keyboard. Wouldn’t it be nice if you could switch windows without taking your hand off the keyboard? You can.

To switch windows, press Alt-Tab. The windows are lined up in the order of which you last used them, so pressing Alt-Tab will take you to the last window you used. Pressing Alt-Tab-Tab (two tabs) will take you to the window you used before that.

If you master Alt-Tab, you’ll be a master multi-tasker.


Computer Tips #7: Remove Unused Programs

Old programs can slow down your computer by wasting your computer’s limited resources. Also, many programs today install desktop icons and taskbar applets that clutter up your computer, making it difficult for you to use it effectively.

Luckily, removing most programs is easy on Windows. Go to the control panel, open the Add/Remove Programs application, click on a program you don’t use any more, and click the Remove button. The program will be removed within a few seconds—although you may need to reboot your computer for the program’s icon to disappear from your taskbar.


Computer Tips #8: Close Windows Quick

You’ve been surfing the Internet at work, but the boss just appeared around the corner—quick, what do you do?

You can close down any program quickly by pressing Alt-F4. But Alt-F4 isn’t just great for emergency situations, it’s also useful for closing all those other little applications you use, like the calculator.


Computer Tips #9: The Hidden Diagnostic Panel

ou probably already know about the Control Panel where Windows lets you change most of its settings, but did you know that there’s also a hidden diagnostic panel that tells you what’s going on with your computer right now?

It’s only accessible to those who know the special key combination: hold down Ctrl and Alt and then quickly press and release Delete. Go ahead, try it right now. CTRL, ALT, DEL.

This task manager includes all sorts of information about what programs are running, how much computer processing they’re using, how much network traffic your computer is running. You can use the buttons to force programs to quit and perform other important operations.

The most useful thing you can do with the task manager is find programs that are using too much computer processing (CPU) and force them to quit (if you don’t need them). For example, sometimes Web browsers or the Adobe Flash player will break and try to use all of your CPU—if that’s the case, simply find the program, highlight it, and click Force Quit.

You can also restart explorer.exe when all your desktop icons and task bar disappear.


Computer Tips #10: Never Shutdown Your Computer Again

Shutting down your computer saves power and prevents computer parts from wearing down too soon, but closing all of your programs every night just to re-open them again the next morning can become quite annoying.

The programmers at Microsoft have the same problem, so they designed a feature called “hibernate.” When you hibernate your computer, all of your programs are saved just they way they are and then your computer is shut off. When you start the computer again, all of your computer programs are restored. It has all the benefits of leaving your computer on overnight without any of the drawbacks.

There’s just one catch: hibernate doesn’t work on all computers. It works really well on most laptops, but it may not work on older desktops. If it doesn’t work, you’ll lose any unsaved changes to your documents, so the first time you try it, make sure you save everything that’s important to you.

To hibernate, open the Start menu and click the Shutdown button. On the menu that appears, choose the Hibernate option—not the shutdown option. It will take a little longer to hibernate than it does to shutdown while your computer saves everything, but when the hibernating is finished, your computer should shut down like normal.

Computer tips for hibernating: To resume from hibernating, turn your computer back on like your normally would. Again, turning back on might take a little longer (although it usually goes quicker), but you should see all of your programs running just like they were before you pressed Hibernate. You can even try it right now–save any important files, hibernate, turn your computer back on, and you’ll should still be reading this article about computer tips.

MAGIC :3

MAGIC :3

An Indian discovered that nobody can create a folder, anywhere on the Computer which can be named as "CON". This is something pretty cool...and unbelievable.... At Microsoft the whole Team, couldn't answer why this happened!

- Try nyo po magcreate ng folder, name it CON and see what happens