free-softwares.org

No computer program works 100 percent correctly, which explains why computers crash, lose airline reservations, or just act erratically at times. Mathematically, writing a program that works 100 percent correctly every time is impossible because testing a program for all possible types of computers, hardware, and additional software that may interfere with the way your program runs is impossible.

If you try running a program written in Visual Basic, it won’t run unless it finds a copy of its run-time file on your computer, which usually has an odd name like VBRUN300.DLL or MSVBVM60.DLL. With the latest version of Visual Basic, Microsoft has replaced the Visual Basic run-time file with a whole bunch of files that make up something called the .NET framework.

Unlike the old Visual Basic run-time files that could run only Visual Basic programs, the .NET framework is designed to run any programs that have been compiled to p-code for the .NET framework. So instead of requiring a separate run-time file for a Visual Basic program and second run-time file for a Visual C# program, computers now just need a single copy of the .NET framework.

By porting the .NET framework to other operating systems, such as Linux or the Macintosh, it’s (theoretically) possible to run Visual Basic and Visual C# programs on other types of computers. Until this happens though, Visual Basic and Visual C# programs run only on computers that can install the .NET framework, which currently limits Visual Basic and Visual C# programs to any computer that uses Windows.

A problem that keeps a program from working correctly is known as a bug.

Technical Stuff In the early days, computers used mechanical relays and vacuum tubes rather than circuit boards and microprocessors. One day, the computer failed to work correctly. The scientists examined their program; it should have worked. So they next examined the computer itself and found that a moth had gotten smashed in a mechanical relay, preventing it from closing and thus keeping the computer from working correctly. From that point on, problems in computers have been called bugs. So it’s a good thing that a dog never got trapped in a mechanical relay because then computer problems might be called Chihuahuas.

Because writing a program that works 100 percent correctly all the time is impossible, operating systems (such as Windows XP) unavoidably contain bugs that keep them from working correctly. When you convert your source code into machine language, you must use a compiler or interpreter, which also contain bugs. Finally, your program may contain bugs of its own. With so many places for bugs to creep in, you shouldn’t be surprised that bugs infest computer programs the way cockroaches infest cheap apartment complexes.

Although you can do little about bugs in other people’s programs (except not buy their programs), you can reduce (but not completely eliminate) bugs in your own program by using a debugger. A debugger is a special program (which may also contain bugs) that can help you track down and wipe out bugs in programs that you write.

A debugger provides several ways to track down bugs in your program:

•  Stepping: The debugger runs your program, line by line, so that you can see exactly which line may contain the bug. This process is like rereading written instructions to get to another person’s house if you’re lost. By going over these instructions, one by one, you can find out where you made a wrong turn.

•  Breakpoints: Rather than force you to step through an entire program, line by line, breakpoints enable you to specify where you want to start examining your program line by line. So if you were lost, instead of rereading the instructions to get to another person’s house from start to finish, you skip those instructions that you know you followed correctly and examine only the remaining instructions that you aren’t sure that you followed correctly. Similarly, by using breakpoints, you can selectively examine only parts of your program, line by line, and skip over the parts that you know already work.

•  Watching: Watching enables you to see your program storing data in memory and to determine what that data may be. If your program stores incorrect data (such as saving a name instead of a telephone number), you know exactly where in your program the bug is occurring.
  Each time you examine a line in your program, the debugger shows you how that particular line affects the value you’re watching. As soon as you see the value change, the debugger shows you exactly which line in your program caused that change. This process is like having someone tell you to drive ten miles south down a certain road after turning right. The moment that you exceed ten miles, a watch-point alerts you so that you know exactly where you almost made a mistake and got lost.

Remember A debugger essentially shows you exactly how a computer is going to interpret the instructions in your program. That way you can see where you need to modify your instructions so that the bug doesn’t occur anymore. Of course, if you fix one bug, you may introduce several new ones. That’s why writing bug-free programs is impossible.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.