Older blog entries for cm (starting at number 18)

16 Apr 2003 (updated 16 Apr 2003 at 15:16 UTC) »
Windows Socket Code

sarum asks about the crappy TCP/IP stack in Windows. Years ago, a company named FTP Software had a nifty TCP/IP stack for DOS. They were the lucky owners of the ftp.com domain, now bought by NetManage (along with the rest of the company). FTP Software's stack worked with Crynwr packet drivers, NDIS and ODI drivers. It was an old-school TSR and when HiMEM/EMM and all that fun stuff was around it knew all about tricks to play to reduce its memory footprint. Then Windows 3.0 came out, and they supported that, with VxDs and other painful stuff, and the WinSock API was borne, in part through contributions from engineers at FTP Software. Yes, it was a commercial product, but it was damn good, and the programmers hung out on UseNet if you needed help. They had things like ICMP router discovery, TCP/IP Slow Start, Van Jacobson compression and a slew of other advanced TCP/IP RFCs before MSFT even know how to spell IP. Did I mention one of the founders of the company wrote the SLIP RFC? If you bought the dev kit, you pretty much got full source, assuming you could fathom the hairy C, x86 assembly, and interrupt mess that was the legacy of being DOS-based.

Some time after, Microsoft started shipping Windows 3.1 with a built-in TCP/IP stack. People started asking why they should pay for a stack when Windows shipped with on "for free". Well MSFT's stack was based on the BSD code, and it was a crappy port. With the release of Win95, third-party tcp/ip support was all but dead. The WinDOS implementation is still a crappy port, with bad default settings for MTU, RTT, TCP window size and so on.

In short, MSFT Borgified FTP Software and TCP/IP.

So now, you can't get a decent TCP/IP implementation for Windows. The WinNT/2000/XP isn't much better, but hey, MSFT and their partners get to charge consulting fees to help people configure their stacks to have half-decent performance.

How do I know all this? Do a search on the web for ugopher.

Like nymia, I too struggled with getting my brain around the Mozilla code. There are some tests -- make sure you do not have ac_add_options --disable-tests in your .mozconfig when you build, and you'll see them built in the dist/bin directory. Also, many components have a test directory, and the tests are in XUL, rather than C/C++. Using the xpshell program in the dist/bin directory you can execute arbitrary javascript, and the very simple viewer executable can also run test XUL.

12 Apr 2003 (updated 12 Apr 2003 at 16:36 UTC) »

To amars: IANAD, but your symptoms sound very much like acute migraine with visual components and perhaps transient ischemic attack. See for example http://imigraine.net/migraine/basilarm.html. Have you been under a lot of stress or overworked lately? Probably harmless, but you might want to go see a doctor, if for no other reason than to get some good painkillers in case you get the same kind of headache again. Actually, any time you lose consciousness for any reason other than natural sleep it's probably a good idea to see a doctor.

I've had visual migraines myself, with weird flickering effects in the corners of my vision and lost visual field, but I've never passed out or been nauseous.

Please take care of yourself.

21 Mar 2003 (updated 21 Mar 2003 at 21:47 UTC) »

In like mind with raph, I'd like to express the strongest possible opposition to the violent aggression against Iraq by armed forces of the United States and Great Britain.

My last posting in the Defect Tracking Patterns series is not really another pattern, but instead a discussion of loose ends and other oddities that don't fit elsewhere.

Capture Bugs With Tests

Simple advice: When you have a bug, write a failing test that demonstrates the bug. Write it before trying to fix the bug, and then add it to the test suite permanently. Then write the code that makes the test past. If that bug ever pops up again (that never happens, right?), the test will start failing again, immediately, before the rebugged code gets put into a release.

No Bug Database

From the XP world comes the idea that instead of having a list of the bugs that need fixing, capture the bugs as new or changed requirements, and have the customer prioritize them along with the ongoing development. There's some wisdom in that, because it helps the to remember that nothing is truly bug-free, and that making important features work well has more payback from a business standpoint than fix a lot of minor defects, and the team gets to estimate how long it will take to fix something and add that time to the overall schedule.

Thanks to everyone who commented on these, please do send me your comments, or visit the version on the wiki at DefectTrackingPatterns, and thanks especially to Brad Appleton and Linda Rising for their help with the early revisions.

Apologies to all for the long delay between these. Work has been hectic and off hours I need my rest.

Schedule Reviews Before Big Changes is the next and penultimate of the Defect Tracking Patterns.

Sometimes a bug or group of related bugs will result in a change that affects large sections of the codebase, or significant changes to one component. Best practices would encourage small, incremental changes and ContinuousIntegration, but sometimes, for reasons outside the team's control, a large set of changes must happen all at once.


Before the programmer commits the changes to the team source repository, assign the bug report(s) to a reviewer, typically a team lead, senior programmer, or module owner, for an extra-careful check. The reviewer can examine the proposed fix for compatibility, suitability, and overall conformance with direction of development. Reviewers should be timely in their responses, and reassign the reviewed bug back to the programmer with approval or suggestions for changes. Once reviewed, the programmer can go ahead and integrate the fix.

It's assumed the team is doing normal revies all the time, either formal, informal, or through pair programming. If the only reviews the team does are before big changes, that's an anti-pattern, and also a failure to follow the CoordinateEfforts rule.

In the continuing series of Defect Tracking Patterns, up next is Incidents and Faults.

A single defect in one piece of code can cause different apparent problems to different users. It is also possible that a single reported problem may be traceable of multiple different pieces of code that are similarly faulty.


Several reported failures that arise out of the same fault should be tracked together. Consider splitting a single bug with multiple causes into a bug for each fault, and relate them as above.


The bug tracking software must support the ability to associate bugs as duplicates of and dependent on other bugs. Splitting a single bug or otherwise tracking related bugs without good support from the tool requires too much manual overhead.

Happy Holidays everyone. I hope the new year brings everyone more work and less stress.

Now that I am back from my vacation I will resume my posts on the Defect Tracking Patterns language. We've come a bit over halfway, and I've gotten some good feedback. Thanks to everyone who has commented!

Fixed is not Closed

A simple but often overlooked distinction in tracking bugs in software. After the code to fix a bug is checked in, it still isn't really done until it is verified. In the context of the development team receiving feedback from the customer, programmers who work on bugs need feedback to know if the changes fixed the bug as reported. Those changes need to be verified by a third-party and the work on the bug brought to resolution.

Therefore A fixed bug is not a closed bug. Once the programmer has made code changes and checked in the results, that programmer can mark the bug fixed, but cannot close it. The customer who entered the bug is responsible for verifying and closing the bug if it really is fixed. The resolution of a bug should be different from the status. "Will not fix" or "Unable to reproduce" are among the other resolutions besides fixed that can close a bug. The dispatcher should be especially alert to resolutions other than "fixed", there may be additional information that can change this.

The customer who submitted the bug should close it, or, if there is an dispatcher role, that can be where fixed and closing are coordinated.

The previous pattern, A Bug's Life Cycle, is closely related to this pattern.

I'm on vacation until after the first of the next year, woohoo! I'm leaving today to visit my family in Houston, so I'll probably not post again until after Christmas. This one will have to hold you until then.

A Bug's Life Cycle

The sixth pattern in the Defect Tracking Patterns language.

Identifying and fixing bugs involves several steps to coordinate as the bug changes states and assignees. Any team member with a stake in a bug needs to know what stage the bug is in at any given time. The customer will look to see when it has been fixed, the dispatcher will need to be able to determine when the bug needs re-assigning, and programmers will need to know when a fix is tested and accepted.


Define and follow a life-cycle for bugs.

A bug can only be assigned to one person at a time. That bug may flow back to the reporter with a misdiagnosis or fix that doesn't work. The assignee may assign the bug to another programmer more familiar with the fault or for review. It may go back and forth from reporter to programmer a few times before it is fixed, retested, and resolved.

See also DocumentWork; CoordinateEfforts

An example Bug State Chart

A quick note to bjf, I also recently bought a Nikon FM3A and I love it. I chose it because of it's classic design and reliability, and I'm glad to see not everything is going digital.

The next pattern in Defect Tracking Patterns is the one that has generated the most commentary so far, often because of confusion over the terms.

Differentiate Priority and Severity

The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time.


Define a range for Severity as "how bad does it hurt?" according to project requirements. One example of a range in use is

  • Enhancement: New features
  • Low: Improvement to existing code, e.g. performance enhancement, or problems with an easy workaround
  • Normal: Broken or missing functionality
  • High: Problems causing crashes, loss of data, severe performance problems or excessive resource use.
  • Blocker: Problems that prevent testing or development work

Define Priority according to business value and project timelines. High priority bugs should be first to be fixed.

Importance and Destructiveness are alternate words which may be clearer to some.

An example of the difference and interaction is in bugs that are purely cosmetic problems, misspellings in dialogs, redraw issues, etc. These can be priority 1 fairly often, because they are frequently very annoying to users, and fixing them is generally easy and doesn't destabilize things.

Track priority and severity separately, then triage appropriately. It helps to have input from others on the team on priority. The importance of a bug is a project decision, different from the bug's perception by the Customer. In some cases it makes sense to track Urgency, the customer's point of view, separately.

The Developer, when determining what to work on next, would pick the bugs with the highest priority, regardless of severity. The Dispatcher is responsible for setting these appropriately, especially in the case where the Customer marks everything Very Severe and Highest Priority.

Extreme Programmers may see a resemblance to Story Cards and the Planning Game.

9 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!