Slashdot Mirror

← Back to Domains

Domain: numega.com

Stories and comments across the archive that link to numega.com.

Comments · 8

  1. Re:Coding practice by Dionysus · · Score: 2 · on Where Should You Apply Various C++ Coding Practices?

    NuMega's BoundsChecker is a program that can discover memory leaks in your program. I think it's only for NT.

  2. My own efforts to help other programmers by goingware · · Score: 5 · on Making Software Suck Less, Pt. II
    First, my effort to improve the quality of free software can be found at the Linux Quality Database. While the database hasn't started being written yet, I have started writing articles on the top of quality assurance and writing better free software. The first such article actually to be posted is Using Test Suites to Validate the Linux Kernel.

    For quite some time before that I have been writing GoingWare's Bag of Programming Tricks, a collection of articles on the business and practice of programming. Of most interest in learning how to program well would be:

    I worked on an article on C++ programming style that is not done yet, and has some errors in it. But I'll post the URL here with the understanding that you're to take is as a preview and not gospel truth:

    Finally, if you program in C or C++, you need to be using one of the following tools, appropriate to your development system and platform:

    If you use Java, you don't have to worry about dangling pointers, but you do have to worry about memory leaks (quiz: why do you in a garbage collected language?), deadlocks and so on. For that we have:

    Don't let another day pass without availing yourself of one of these tools. I know most aren't Free Software and some are very expensive. I want to tell you that the money I spent on Spotlight is some of the best money I have spent on anything in my life. I wouldn't dream of shipping a Mac application to my clients unless it tested completely cleanly under Spotlight; on the other hand, the first time I'm given a client's code to work on, Spotlight usually reveals a multitude of sins.


    Mike

  3. There go some major products... by bored · · Score: 1 · on U.S. And EU Ready International Cybercrime Treaty

    Like for instance Communications test sets, Oscilloscopes , Debuggers, Protocol analysers, Logic Analyzers, and Engineering Books

  4. Fixing Someone Else's Broken Code; Resources by goingware · · Score: 4 · on Notes From the Cathedral
    I've been working as a programmer for 13 years now, and for most of my career, the way I described it is this:

    I've spent most of my career fixing somebody else's broken code.

    This is not to say that my own has always been of the very highest quality, but in fact I decided early on to try to come to a fundamental understanding of what was wrong with software development, to get very good at debugging (I say that debugging is a specialty on my homepage) and to learn to write better code.

    In my early years I was initially very shocked at what I'd discover in production use at companies. Over the years I just learned that that's standard practice, in commercial software, in-house software, and even in scientific software (where I have become convinced, because of my experiences with high-energy physics data analysis, that many scientific papers are published with erroneous measurements because of software bugs).

    Early on I read that something like 90% of software development is spent doing maintenance programming. Some of this is doing legitimate upgrading, but a lot of it is just spent fixing bugs, and even a lot of time spent doing upgrades would be more productive if the code were of better quality.

    After reading this figure and having so many experiences with software bugs, both other people's and my own, I decided very early on to get very good at debugging.

    One of the first things I did was adopt the regular use of "lint" for checking my C code. I would integrate lint targets into my makefiles and after editing a source file I would type "make lint" before compiling to objects and lint would check all the files that were out of date with the object modules. Pretty quickly I got to where I could write code that was nearly always lint-clean - but the existing code I worked on would make lint scream with hundreds if not thousands of complaints, often serious things like variables being used before they are initialized.

    One of the first solid clues I got about software quality came from Robert Ward's book "Debugging C" - now out of print, it predated the common use of source code debuggers and talked about how to write your own stack crawls and other tools.

    Ward emphasized the use of the Scientific Method in debugging, and because I was trained in physics, this came very naturally to me; before that I'd mostly floundered and used printf a lot.

    I've gotten very good at debugging and have even worked full-time as a debugger at Apple Computer where I was a "Debug Meister" and my business card gave my title as "Cybernetic Entomologist".

    I can easily get highly paid consulting work doing debugging for companies desperate to ship a product (and have in the past) but I don't really like to do it for various reasons, some of the same reasons I quit my debugging job at Apple.

    One is that if I only do debugging I don't have something to point to at the end of the day and say "I wrote that". I could say "that works because of me", but sadly there's usually lots of bugs left that I didn't have the time to find so I don't really feel proud of the result. The other problem is that the bugs are usually not there because of something interesting, it's not like the code is mostly good but there's some subtle flaws, rather the code is a heap of dung and I can go in with a pitchfork and do debugging wholesale until I get tired of it and the client or manager decides the rate new bugs are being found is low enough they can feel OK about shipping it.

    I don't feel good about contributing to such shoddiness. If a company is not good enough to support quality in their corporate culture I don't want to come in and put on a band-aid for them. It would be an entirely different thing if a company hired me to restructure their development process so that quality was a goal that was achieved through direct application of process but gee whiz no one has ever asked me to do that for them.

    I do have to say though that the best thing that ever happened to me is that I became a "technology prostitute" as the author of the original article puts it. One benefit of this is that the process is entirely of my own creation, and almost all of the work I've been given has been to write entirely new products from scratch, so I can engineer in quality from the beginning.

    Here's a few recommendations I have. Get good tools. Besides a compiler, editor and debugger, you need a static code checker and you also need dynamic testers. The ones I know about are (I haven't used them all yet):

    • PC-Lint static code checking for C and C++. It runs on Windows but Flexe-Lint comes as shrouded source code and is highly portable.
    • Spotlight dynamic tester for Mac PowerPC - I use this every day and recommend it highly
    • BoundsChecker dynamic tester for Windows
    • Purify dynamic tester for Unix (but apparently not Linux) and Windows NT
    • Optimizeit dynamic tester for Java - do you know many Java programs have memory leaks? Can you understand why? Not just Java but any garbage collected program.
    There's also memprof and electric fence, which I think run on Linux. It would be possible to modify gcc so that you program when built with debugging flags and linked with a special library would have all memory references boundschecked before allowing the access. This could work with both read and write access and would catch overruns by as little as one byte - Spotlight does this by patching the executable powerpc code and rewriting the debugging symbol table.

    Finally, to really come to understand the software quality problem in the industry and what you can do about it, read The Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks. The book The Software Conspiracy exposes the complete disregard the commercial software industry has for serving the consumer by providing quality products - I haven't read it yet but it looks interesting.

    A very interesting methodology that emphasizes personal responsibility and puts the fun back into programming as well as maintaining quality from the very start is Extreme Programming. I'm starting to adopt extreme programming (the the extent a one man operation can - I can't work in pairs :-/ ) and find it a tremendous benefit.

  5. Risks, the Software Conspiracy and Good Tools by goingware · · Score: 3 · on The Code War-- Software By Other Means
    Two valuable and pertinent links:

    The Forum on Risks to the Public in Computers and Related Systems

    The Software Conspiracy

    While there will always be quality problems in software, current practice in many companies is to not even try to do the basic things that tend towards improving software quality. Until the public wakes up and realizes they're being ripped off, and their safety and corporate information being put at risk, we will always have this problem.

    One solution is to get every programmer in a company a copy of some good quality tools, static analysis tools like PC-Lint and dynamic (runtime) analysis tools like Spotlight (for the MacOS) or BoundsChecker (for Windows) or Purify for Unix (but apparently not Linux) and NT.

    As a Spotlight user and a long-time reader of the Risks forum, I wouldn't dream of shipping a Mac product unless it tested absolutely cleanly under Spotlight and had zero memory leaks.

    But it is amazing to try Spotlight on a mature commercial product for the first time. Think you're program's free of bugs? Guess again. I proposed using Spotlight to my manager, on our program which had been shipping for several years and cost $600 retail. It was a serious product for high-end users. My manager said it would be a waste of time because "Our program has so many bugs, Spotlight would keep finding them and progress would be very slow." And you know, he was right. I persisted anyway, and spent three months ferreting bugs out of that program with Spotlight.

    There's a lot of tools out there (and there's tools like these for Java too, like OptimizeIt - do you know many Java programs have memory leaks?). You don't have to pick the tools I recommend, but look out for what's available there and make sure you have something for every developer seat in the house.

    It will be the best investment you make. The $199 for Spotlight will be paid for in the day it's first used.

    And free software writers, I suggest writing free software versions of these. It would be possible in principle to write a special version of gcc, or an command-like option to it, that when your program is linked to a special library all your memory accesses are boundschecked. Note that Spotlight can validate memory reads as well as memory writes.

  6. My take... by eddy · · Score: 2 · on Reverse Engineering?

    > How DO you reverse engineer software?

    Using disassembly/decompilation, debugging and/or probing (as in "black-box"). Have a look at this essay I've written. It's about my analysis of the program "Net Nanny", but the techniques used are fairly typical.

    >Anyway, am I in over my head even contemplating it?

    No. But it depends on why you want to do it. This is not a good way to pick up on new graphics algorithms, unless there is something very specific that you are after. However, you should give it a try if you think you might enjoy this kind of low-level puzzle (for me, it's a puzzle).

    > I have a feeling that by the time [...]

    Possibly, but I really think you would have the sense to give up before spending that much time :-)

    I might aswell tell you what tools I use:

    The most powerful tool is NuMegas SoftIce. It's a systemlevel debugger for the Win32 platform (would love a linux version).

    After SoftIce comes IDA. IDA is a very competent disassembler. It runs under Win32, but it supports many different processors and file-formats (MZ/NE/PE/ELF/DLL/etc).

    Of course, you also need a good hex-editor. I use HIEW.

    I primarily use reverse-engineering techniques to discover backdoors and extract encryption algorithms in commercial software (Me and a friend reversed the censorware CyberSitter earlier, which lead to the downfall of the Scientologists "ScienoSitter").

    I also use the techniques to explore unknown file formats, see for example the project to reverse the fileformat used in the game Baldur's Gate. When doing this it is much less "debugging/disassembling" then it is hanging around the hexeditor.

    If you want to learn, check Fravia's Pages of Reverse Engineering. While there's lot's of crap there, there's also some nuggets of good information. You can also use his messageboard to interact with competent reversers, but beware, you will have to show that you are working on your side too. Don't ask for ready solutions.

    Hope this was of help, be in touch if you have any questions.

  7. Re:Tools by Anonymous Coward · · Score: 2 · on Reverse Engineering?



    Some of the best Reverse Engineering Tools

    IDA Pro From Data Rescue


    www.datarescue.com

    Soft-Ice From Numega


    www.numega.com

  8. disassemblers by Trepidity · · Score: 1 · on Update to The Magic Cauldron

    WinIce is fairly popular among crackers (those who crack the copy protection on software, not the misusage of the word to refer to system intruders).