[Home]
[Edit this page]
[Recent Changes]
[Special Pages]
[Help]
Intro-EDP » CSharpHelloWorld » API » talk:CCplusplus » MySQL » VL-Bus » CppVclPreventFreezing » gwbasic » eMacs » OS » Diagnostic programs
Diagonistic Programs
How big and complicated should a diagnostic be? Software designers continue to debate this question. Some programmers use the "less-is-more" approach, which usually results in a large number of small, simple DOS diagnostics—each performing a specific function (or set of functions). Conversely, other programmers use the "all-or-nothing" philosophy, which tries to create an all-inclusive, sophisticated program that can test everything (this is most prevalent in commercial diagnostics).
Ultimately, the choice of diagnostic will depend on just how closely the particular program suits your needs. If you perform a lot of basic testing on various areas of a PC, a general purpose diagnostic might fill your need. If you find yourself dealing mostly with a few specific problem areas, you might get more results from specific diagnostics.
When selecting a diagnostic, consider some important factors:
1: How usable is the program?
This is perhaps the truest measure of a program’s worth. If you find yourself reaching the program disk regularly, it’s probably something you need. On the other hand, a program that you only turn to occasionally is probably not worth a lot to you.
2: How accurate is the program?
The great diversity of hardware (and its rapid development) means that some programs will not read your hardware accurately—this is as true for commercial software as it is for shareware. Incorrect CPU and clock-speed identification are two typical examples of this problem. A program that does not provide accurate information will probably sit unused.
3:How often is the program updated?
This also relates to a program’s accuracy. Regular updates and program patches usually suggest current, reliable software. Because major new generations of computer hardware are appearing every 18 to 24 months, it is reasonable to expect a major diagnostic revision to appear around that same time frame. In actuality, most technicians use a mix of general-purpose and task-specific diagnostics. For example, you might "standardize" on one or two general system diagnostic, and supplement that with a series of drive, or memory, or sound board, or SCSI diagnostics— depending on what gives you the most trouble.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
Intro-EDP » CSharpHelloWorld » API » talk:CCplusplus » MySQL » VL-Bus » CppVclPreventFreezing » gwbasic » eMacs » OS » Diagnostic programs
Diagonistic Programs
How big and complicated should a diagnostic be? Software designers continue to debate this question. Some programmers use the "less-is-more" approach, which usually results in a large number of small, simple DOS diagnostics—each performing a specific function (or set of functions). Conversely, other programmers use the "all-or-nothing" philosophy, which tries to create an all-inclusive, sophisticated program that can test everything (this is most prevalent in commercial diagnostics).
Ultimately, the choice of diagnostic will depend on just how closely the particular program suits your needs. If you perform a lot of basic testing on various areas of a PC, a general purpose diagnostic might fill your need. If you find yourself dealing mostly with a few specific problem areas, you might get more results from specific diagnostics.
When selecting a diagnostic, consider some important factors:
1: How usable is the program?
This is perhaps the truest measure of a program’s worth. If you find yourself reaching the program disk regularly, it’s probably something you need. On the other hand, a program that you only turn to occasionally is probably not worth a lot to you.
2: How accurate is the program?
The great diversity of hardware (and its rapid development) means that some programs will not read your hardware accurately—this is as true for commercial software as it is for shareware. Incorrect CPU and clock-speed identification are two typical examples of this problem. A program that does not provide accurate information will probably sit unused.
3:How often is the program updated?
This also relates to a program’s accuracy. Regular updates and program patches usually suggest current, reliable software. Because major new generations of computer hardware are appearing every 18 to 24 months, it is reasonable to expect a major diagnostic revision to appear around that same time frame. In actuality, most technicians use a mix of general-purpose and task-specific diagnostics. For example, you might "standardize" on one or two general system diagnostic, and supplement that with a series of drive, or memory, or sound board, or SCSI diagnostics— depending on what gives you the most trouble.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
