|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|Classic Computer Books|
|C++||C++ Gotchas||How Not to Program in C++||Debugging C++||Practical Debugging in C++|
|Debugging Windows Programs||Debugging Applications for Microsoft .NET||Softpanorama Debugging Recommendations||History||C++ Humor||Etc|
This page was created for my students to help them in their programming assignments. To use OS/languages effectively, it's not enough to know the syntax and features of the particular language and API of the operating system. You must develop an set of skills called debugging skills. Good books might help because they provide you some framework and a bit of the view on the problem. Among simple things not often mentioned in the books I would suggest the following:
- No matter what problem you fighting with, remain calm. Do not debug until you are fully exhausted. Switch activity. Take breaks.
- Panic paralyzes your ability to think through the problem and find a solution. Slow down and calm down.
- Understand that errors are inevitable and this is a fact of life to be lived with , not a problem to be solved.
- Get a night's sleep and try tomorrow (cannot be done if your deadline is tonight ;-)
- Take a pause and try it again
- Avoid typing errors, use fully debugged prototype as a template whenever possible. Many times I see that problems arise when students try to type too quickly or type in an example what can be simply copies from the file. Most textbooks provide an archive with the examples that should be used instead of typing them in (that does not mean that those examples are always correct ;-). Get a better keyboard: full side keyboard with a nice keys feel and a key-click (like IBM keyboards) helps to typing errors; copy constructs is you are unsure about syntax and then modify them. Remember that in programming languages typo is not always demonstrate itself in an obvious way. it much to do you bet to avoid them than to debug the program after you made one or several of them.
- Use the best editor you can get and get a list of typical language errors. Get a nice editor with syntax highlighting and language help. If the editor is integrated with the debugger (IDE environment) that's even better.
- Use GUI environment. If possible do not debug programs using telnet. Telnet is too primitive and you should avoid it if you can. SSH is better and gives possibility to transfer files without opening additional FTP session. Use X windows, VNC or terminal server. You will have a better support for your keyboard and your monitor. With the regular terminal emulator the backspace and delete keys sometimes do not work correctly and need to be remapped. also unless you use screen (and you should) you cannot open more then terminal in regular emulator (without reconnecting again).
- Seek clarity. Use style books to simplify your programs and to create your own programming style. Simplify your program Avoid debugging everything at once. Remove non-essential modules if you face really complex problem. you can always add them later. Simplification helps you focus on a new task or way of approaching a problem.
- Don't flirt with deadlines. If you start your work close to the deadline, you may run into trouble that you might not be able to resolve in time. In the real world, real deadlines mean either money lost or money gained. In the university world you can lower your score considerably but postponing the assignment till the last day. If you do something in a hurry the quality suffers and you might experience more debugging problem then if you have some space to breath. If you miss a deadline, you may lose some or all points for the assignment.
- Do not strive for perfection. Understand that any OS and any language was written for humans and by humans and thus is a language, full of ambiguity, inconsistencies, history, and culture.
The same is true about textbooks and teachers ;-).
The combination of hardware, networks, operating systems, and software gives rise to a high level of complexity. When problems arise, I have found it is best to try some troubleshooting techniques, then try something else, rather than trying to figure out exactly what went wrong (however, I do read error messages and look for any clues on the screen).
- Try to get as much help from your previous mistakes as possible. People tend to repeat the same errors again and again. If you do not keep the log you can spend a lot of type bugling you head against the same wall, when the door is nearby. Each time you have found a non-trivial error in your program, write down the program fragment, the error messages and the solution. Next time it might save you a lot of time.
Realize that there are many paths to getting things done.
There are usually many ways to accomplish a task. Don't get too dogmatic about finding the one and only one way to do it, nor get too over-involved in figuring out every way to do something.
- Make maximum use of Internet and your environment.
Use GUI environment is you can and have several windows opened at the same time. You can also use a second computer for reference if it is available.
- Have language help always opened.
- Convert example from the textbook into a webpages if you can and have this site always opened too.
Keep all of these windows up while working until you get your task done. Don't be afraid to bring up another Web browser, and keep the Web browser showing task information or reference information up. I've seen many students go through the trouble of bringing up a Web browser, following links to the assignment description, looking up a requirement for the assignment, then closing that Web browser, only to have to repeat the entire process when they need to look at the assignment description or reference information again. Don't be afraid to have as many windows open at the same time showing different information to get your work done.
September 2008, 280 ppTable of Contents
Chapter 1: Some Preliminaries, for Beginners and Pros
Chapter 2: Stopping to Take a Look Around
Chapter 3: Inspecting and Setting Variables
Chapter 4: When a Program Crashes
Chapter 5: Debugging in a Multiple-Activities Context
Chapter 6: Special Topics
Chapter 7: Other Tools
Chapter 8: Using GDB/DDD for Other Languages
View the detailed Table of Contents (PDF)
View the Index (PDF)
A P R E S S . C O M
Chapter 7: Final Words of Advice
"Lore of Programming" - from preface, November 4, 2000
engineersoftware (see more about me) from San Gabriel, CA United StatesPublished in 1978. Each chapter contains a well-conceived set of programming maxims and a thorough set of exercises. Excellent discussing of commenting techniques and program style. "Comments should provide something extra - not just paraphrase the code." Example code fragments are presented in COBOL, FORTRAN, ALGOL, and PL/I. The program design chapter covers simplicity, problem definition, algorithm selection, generality, modest goals, and structured programming. Discussion of issues related to programs stored on punch cards and executed by machine room operators provides a humorous historical context.
"Large monolithic programs are like a plate of spaghetti: pull it here and something moves on the other side." Spaghetti code issues still appear in the object-oriented programs of the 1990's. --This text refers to an out of print or unavailable edition of this title
by Richard M. Stallman, Cygnus Solutions
- Unknown Binding: 148 pages
- Publisher: Prentice-Hall; (1971)
- ASIN: 0131973193
- Textbook Binding
- Publisher: Elsevier Science; (June 1973)
- ASIN: 0444195653
|C++ Gotchas||How Not to Program in C++||Debugging C++||Debugging Windows Programs||Debugging Applications for Microsoft .NET||Practical Debugging in C++|
Really not bad., April 14, 2003
Reviewer: A reader from Erlangen, Germany
There are dozens books about C++ on the market and this one is clearly under the top ten. It's a wonderful book for beginners and programmers at an intermediate level. For the pros it's fun to read it, because: I made all this mistakes a few years ago. The perhaps only flaw ( I found in the whole book only one real mistake, or my compiler (gcc) is wrong , and I know it's not) of this book: it's too short. If you are making your first steps in C++, then buy this book.
A must read, February 18, 2003
Reviewer: alefinus (see more about me) from El Dorado Hills, CA United States
This is a wonderful book. Not a usual list of trivial advices and recipes, but a collection of serious considerations on how to write code that will survive years of maintenance.
I haven't come to this conclusion right away. At first, I was a bit irritated by what I had thought were the author's biases and self-confidence, but as I kept reading, I began appreciating and even enjoying his candid and confident style that communicated strong experience of dealing with the issues. Not since the time when the ARM ("The Annotated C++ Reference Manual" by Margaret A. Ellis and Bjarne Stroustrup) and Stroustrup's "The C++ Programming Language" were published years ago have I read a C++ book that impressed me as much! If Stroustrup's books focus on the description of C++ facilities, this book concentrates on its programming practice. The author's knowledge of the C++ standard and the compiler mechanics makes his arguments very compelling.
Although anybody familiar with C++ will benefit from this book since it covers a wide range of C++ features, as well as programming and support issues, the book should appeal most of all to the mature audience: one has to be mature to understand the value in developing a program that will sustain years of maintenance by others rather than the one that will only run most of the time without crashing.
Ignore the reviewer from Sweden, January 31, 2003
Reviewer: A reader from Palo Alto, CA
Having been in software development for many years, the last twelve using C++, I can say from experience that the author has assembled an accurate collection of problems I encounter over and over again. I have worked with legacy source code from Microsoft, Adobe Systems and other lesser known software companies that have some of the problems described in this book. These instances are not an indication of incompetence on the part of the original programmers, but rather a reflection of the realities of the business: deadlines need to be met and rarely do we have the time fiddle with code to make it into picture perfect C++. And if it works properly as it is, then don't fix something that is not broken.
Beginning C++ programmers will get a lot out of this book. This is especially true if you are migrating from C and need to break a few bad habits. Experienced C++ developers will not get that much out of it, but the author has many interesting points that are worth checking out.
The reviewer from Sweden is either an academic pinhead who has never participated in a large commercial software development effort that someone would actually want to pay money for, or he / she / it stopped reading the book after the first three or four sections.
To sum this book up: If you DON'T need to ask yourself the questions the author addresses in this book, then you are not doing any serious C++ software development!
Only for extreme novice C++ programmers, April 4, 2003
Reviewer: A reader from an undisclosed location
The concept of this book is good, but the execution is seriously lacking.
The "bugs" in Mr.Oualline's programs are the kinds of errors only the most unskilled novices would make: a missing space character in a format statement; accessing a 5-element array with index values of 1 thru 5; a class whose constructor allocates storage but whose destructor doesn't release the memory. Trivial, easy-to-spot errors that don't really expand anyone's grasp of C++.
To add insult to injury, large portions of the book are filled with Mr.Oualline's tiresome war stories and aphorisms.
A much better source of knowledge is "C++ Gotchas", any of Scott Meyers' books, or the "C++ FAQ".
Just Plain Fun!!!, March 31, 2003
Reviewer: Brad (see more about me) from Fishers, IN United States
Okay, maybe I should say, just plain fun in a geeky kind of way. This book is relatively inexpensive, thus making it well worth the price. If you program in C++ (or even in C, C#, or Java), then you will most likely enjoy this book.
Unlike most computer books, this is not a book you read in order to learn how to to something. Rather, this is a book you read (1) to see if you already know how to do something, (2) if you like solving puzzles, (3) if you want to learn about a number of typical 'gotchas'.
This book presents listings (about 111+). Each seems to have something specifically wrong with it. You try to figure out the issue with a hint. You are can then get additional hints using a jump table. You are also given the answer as to what the gotcha is.
The book also contains a large number of trivia type information. This is folklore, funny stories, and more.
This is a book that I find myself picking up over and over to read just a little farther. It is fun. It is interesting. I'm even learning a thing or two. I've enjoyed it so much, I'll be writing a review on it for CodeGuru.com!
Congratulations to Steve Oualline on putting together one of the few fun-to-read computers books.
- Paperback: 592 pages ; Dimensions (in inches): 1.09 x 9.24 x 7.40
- Publisher: Addison-Wesley Pub Co; 1st edition (January 15, 2000)
- ISBN: 020170238X
- Average Customer Review: Based on 10 reviews. Write a review.
- Amazon.com Sales Rank: 54,188
"must have" for general debugging, April 8, 2002
Reviewer: developer from England
In my experience, programmers fall into two categories: general (majority) and advanced (few); advanced ones understanding register and stack dumps etc, general ones being lost. This book covers the more general programmer, Robbins book the advanced. Comparing the two, you could write your own debugger and your own "core" dumps (which you can then examine) from Robbins book; with this one you can't, but it covers useful stuff missing from Robbins book (eg. PE format, address space partitioning). As such they have some overlap but supplement each other. Both books are essential to serious developers. I have one gripe with this and Robbins book: neither suggests outputting the mixed source/assembly/machine_code (.COD files); these are essential (without a .PDB) if a crash occurs so that the offending instruction etc. can be found, as many instructions usually follow a line of source; secondly, function locals only show in .CODs (as offsets from EBP) so making them easy to locate on a stack trace.
No Mercy Debugging, July 26, 2001
Reviewer: dev1zero (see more about me) from Bellevue, WA United States
C++ bugs can be very difficult to find and can bring tears to the eyes of a programmer easily.(You know the bug is there but you just cant find it to save your life!)
After reading the first few chapters of this book, I knew it was a winner. This book shows ways to find bugs in different kinds of C++ programs MFC,COM etc.
The most important however is the chapter on memory bugs (a real pain)
If you need to hunt down bugs, get this book and your monitor is less likely to end up smashed from your frustrations.
This book also points the reader to a lot of other books which should make a better programmer of anyone who bothers to buy them.
Hands down best book on Windows/VC++ debugging, September 7, 2001
Reviewer: dwstark (see more about me) from Santa Rosa, CA United States
If you write sofware for Windows using VC++, you cannot afford to not have this book. End of story. Everything that I'd scoured MSDN, MSJ, and news groups for the last 5 years to figure out about how Windows works from a user mode program mechanics point of view (PE format, DLL rebasing, symbols, etc) and debugging techniques is in this book (plus more stuff that I'd not yet found out about). It is well written and understandable. It works as a good overview of the topics and as a reference for dealing with a partiular problem, like post-mortem debugging, debugging memory or multi-threading problems, etc. Pick one up, you won't regret it.
- Hardcover: 832 pages ; Dimensions (in inches): 2.34 x 9.42 x 7.63
- Publisher: Microsoft Press; Book and CD-ROM edition (March 12, 2003)
- ISBN: 0735615365
- Average Customer Review: Based on 3 reviews. Write a review.
- Amazon.com Sales Rank: 22,763
Below the belt..., September 23, 2003
Reviewer: Paul Selormey (see more about me) from Toyohashi, Aichi Japan
I bought this book to get a complete knowledge of the .NET framework debugging and got nothing. May be the .NET in the title applies to the fact that the author is using the VS.NET. If you have got the author's previous book on debugging then there is no need to waste money on this one.
It discusses mainly C/C++ debugging in a typical MFC style (ASSERT/VERIFY etc).
Here is the content at a glance:
1. Bugs: Where they come From and How you Solve Them
2. Getting Started Debugging
3. Debugging During Coding
4. Operating System Debugging Support and How Win32 Debuggers Work
5. Advanced Debugger Usage with Visual Studio .NET
6. Advanced .NET Debugging with Visual Studio .NET
7. Advanced Native Code Techniques with Visual Studio .NET
8. Advanced Native Code Techniques with WinDGB
9. Extending the Visual Studio .NET IDE
10. Managed Exception Monitoring
11. Flow Tracing
12. Finding Source and Line Information with Just a Crash Address
13. Crash Handlers
14. Debugging Windows Services and DLLs That Load into Services
15. Multithreaded Deadlocks
16. Automated Testing
17. The Debug C Run-Time Library and Memory Management
18. FastTrace: A High-Performance Tracing Tool for Server Applications
19. Smoothing the Working Set
As you can tell, there is hardly a .NET stuff to pay for, so for those of us owing the author's previous debugging book, this is just a second edition with .NET appended to confuse buyers!
- Paperback: $21.80, 112 pages ; Dimensions (in inches): 0.25 x 9.00 x 6.00
- Publisher: Prentice Hall; 1st edition (January 15, 2002)
- ISBN: 0130653942
- Average Customer Review: Based on 1 review. Write a review.
- Amazon.com Sales Rank: 378,445
- Paperback: 523 pages ; Dimensions (in inches): 1.25 x 9.25 x 7.50
- Publisher: McGraw-Hill Osborne Media; (April 21, 2000)
- ASIN: 0072125195 | All Editions
- Average Customer Review: Based on 10 reviews. Write a review.
- Amazon.com Sales Rank: 351,186
Decent for beginner Windows programmers, September 10, 2001
Reviewer: A reader from Vero Beach, FL United States
I was pretty excited when I first got this book, but was pretty disappointed after reading it.
First off, the title is misleading, focusing on Windows rather than C++. Since I am mainly a Windows programmer, though, this didn't phase me too much. However, the book often seemed to be a manual for the Visual C++ debugger rather than an insightful narrative on the debugging process. Although I realize examples have to be short and to the point, I was often insulted by the ridiculously simple errors the authors presented. The section on inline assembly debugging is almost useless. A much better approach would be examining the assembly language that the Visual C++ compile generates, rather than creating simple ASM programs with obvious mistakes.
I would have much rather seen a book about preventing bugs, and techniques that can be used to accomplish this goal. While this is certainly not that book, it would be useful for something just getting started with Visual C++, though anyone beyond a novice would probably be as disappointed as I was.
Buy John Robbins 'Debugging Applications' instead., March 4, 2002
Reviewer: A reader from Hobart, TAS, Australia
Like I said, the above sums up my advice. I'd suggest only absolute beginners would write a good review for this book, because they don't know any better. One section alleges that a programmer who teaches themself C++ will get fired, because they would use the line
i = i + 1;
not realising they SHOULD use
This is funny on SO many levels.
1. Who would fire someone for this ?
2. Why can't people find this syntax for themselves ?
3. He crows about increased efficiency, but i++ creates a tempory, he wants ++i for this claim
4. He was talking specifically about people teaching themselves in migration from C, which, as you know, supports i++.
He goes on to list the STL containers, misses half of them and goes on to explain why STL containers are better than containers based on templates ( which is the bedrock of STL ).
His understanding is obviously lacking, but this does not stop him from writing about a topic if he thinks it will help sell his book.
John Robbins book, on the other hand, is indispensable. If you don't own it, you need to. It is everything this book could have been and more. John is the author of MSDN's 'Bugslayer' column, and he knows what he is talking about.
Used & new from $2.10 A tutorial needs to tutor!!!, February 10, 1999
Reviewer: firstname.lastname@example.org from Burlington, MA USA
The book could have been named: "Debugging Visual C++ for Dummies". It's contents in certain chapters are not detailed enough to actually teach you how to use to the various debugging tools to full potential. Chapters 4(The Visual C++ Debugger) and 5(Additional Debugging Tools) fit the above description. The author does provide some good suggestions to bolster your debugging process, but to be a true tutorial for the "intermediate" programmer, more code examples and actual use of the debugging features is required. Hopefully the next edition will go from an IDG "...Dummies" clone to a "Visual C++ Debugging Bible".
Not very useful., January 25, 1999
Reviewer: A readerDebugging tips for intermediate-level Visual C++ developers., August 26, 1998
While this book did offer a few pieces of good information, I was very disappointed overall. Even though the book calls itself "A Tutorial-Based Desktop Reference", very little, if any of the book was in the form of a tutorial.
The first part, which deals with Windows memory issues, did at least have some code samples, but no tutorials. Once he started talking about the Visual C++ debugger and other tools, he just gave brief descriptions without saying why or when you would want to use them.
The information in the book is about the same quantity and quality you can find in Visual C++ help. In fact, after reading one topic, I looked it up in the help and was surprised to find that it said almost exactly the same thing, word-for-word. The author added one or two sentences of his own that didn't give me any useful information.
I was looking forward to the section on third party tools, but I found that it was basically a listing of features with nothing to tell me whether the tools would be worth buying, much less instructions on how to actually use them.
There is some useful information, such as a description of how memory is managed in 32-bit Windows. But the same thing can be found in other books. And most of the rest of the book can probably be found in the Microsoft help files or on the outside of the third party tool packages. The best thing I can say about this book is that it puts all of this together.
Reviewer: email@example.com from Oak Ridge, TN, USA
This book was written with the intermediate developer in mind. I discuss basic issues impacting the debugging phase of software development with Visual C++ ranging from design to testing. Topics include the ASSERT macros, the TRY-CATCH macros, using the debugger, stack probes and stack unwinding, etc. I also provide an overview of third party development tools that aid the debugging process
C++ and C Debugging, Testing, and Reliability: The Prevention, Detection, and Correction of Program Errors/Book and Disk by David A. Spuler
Out of Print--Limited Availability
Debugging Windows Programs: Strategies, Tools, and Techniques for Visual C++ Programmers
by Everett N. McKay (Author), et al (Paperback)
Avg. Customer Rating:
Usually ships in 24 hours
List Price: $44.95
Buy new: $35.84 Used & new from $16.90 6.
Defensive Programming in C++: Program Planning, Diagnosis, and Debugging by Scott Robert Ladd
Out of Print--Limited Availability
Debugging COM+ Components written in Visual C++
by Chris Schmidt (Author) (Digital)
Available for download now List Price: $8.00
Buy new: $8.00
C++ Programmer's Companion: Designing, Testing, and Debugging
by Stephen Randy Davis (Paperback - December 1992)
Unix System V: Understanding Elf Object Files and Debugging Tools (Prentice Hall Open Systems Library)
Turbo C: The Art of Advanced Program Design, Optimization, and Debugging/Book & Disk
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017