Hamilton Laboratories was founded in September, 1987 by Nicole Ashley Hamilton in Wayland, Massachusetts.  We are presently located in Redmond, Washington, a suburb of Seattle.

Our first and, still, our main product, is Hamilton C shell, a tools package that recreates the original UNIX C shell and utilities, offering numerous enhancements.  Most of our customers are professional software developers at virtually every major software development shop world-wide. Within this segment, Hamilton C shell is used both as a personal productivity tool and as a scripting engine, often in the automation of mission-critical activities such as the build or QA of their own products.  Our other major customer segment is within the CAD/CAM industry, where many of our customers use Hamilton C shell for tasks such as reading or writing TAR-format tapes used to exchange part drawing files with a UNIX workstation.

From 1995 through 2001, we also offered on-site training, but that’s been discontinued, along with any consulting services, to focus on the product business.

You must be satisfied.

In forming Hamilton Laboratories, there were two important objectives: first, we wanted to treat our customers the way we’d like to be treated ourselves. You put food on our table and shoes on our kids’ feet.  You are important.  We hope to conduct ourselves in a manner that never leaves that in doubt.

Committed to Excellence.

Second, we are committed to technical excellence and fanatical quality. Within our category of UNIX tools on a PC, there are or have been (a lot of them come and go!) a lot of competitive products based on little more than crude ports from UNIX or public domain sources.  Our Hamilton C shell has been created completely from scratch.  This has allowed us to make significant improvements over the originals on UNIX in areas such as full-screen command line editing, procedures, block-structured local variables, a free-format expression grammar, improved wildcarding, much higher performance and, perhaps most important, in our far better integration with the systems we run on.

Using threads, a concept that hadn’t even been invented when the original UNIX shells were written, we’ve built an architecture that dramatically improves performance and responsiveness both by reducing the cost to spawn an asynchronous activity and by overlapping any blocking events.  Using incremental compilation technology, statements are compiled to an internal form, then optimized before being executed.  The result is a more regular and robust language implementation and far higher performance anywhere iteration is involved.

While certainly, we try to avoid gratuitous differences between Hamilton C shell and the original tools on UNIX, there are some things about Windows that are just plain different than on UNIX.  A trivial example is the slash used to punctuate a filename.  Every competitive product we know of requires that filenames must be typed with forward slashes (/), UNIX-style.  While certainly, Hamilton C shell will accept that form, it does not insist on it.

How we differ.

There are two schools of thought.  One is that what made the tools on UNIX so useful was all the cosmetic details, e.g., that when you listed a directory, you saw rwx bits.  The other, the one we subscribe to, is that what made the UNIX tools so powerful was that they let you reach right in and manipulate the system resources.  When you listed a directory, you saw the bits that were there (which just happened to be rwx bits).  What we’ve attempted to do with Hamilton C shell is ask and answer the questions, “Suppose the original tools designers on UNIX had been working on Windows instead. What would they have done differently?  Also, having seen what worked and what didn’t, if they had it to do over, what would they change?”  For our customers, whose own ability to produce competitive products depends on doing the best possible job of supporting their chosen platforms, this approach just plain works better.

Another difference is our small company feel.  If you call with a question, you’ll likely speak with the author.  If answering your question means someone has to go read the code, well, she wrote it and she can (and certainly will) read it.  If you find a bug, it will get fixed.  If we can reproduce it, we can generally fix it within a few days.  Frankly, when you tell us about a bug, you’re doing us a favor, giving us a chance to fix it before anyone else spots it.  Of course we’ll fix it!  And when we issue a new build, we actually document all the changes.

Our products are not cheap, though we do give discounts for quantity and for educational users in an attempt to make them affordable.  But unlike most vendors who make you feel like you’ve only rented their products when they offer an upgrade, our price includes free updates.  More to the point, most of us have had the experience of buying something and then, much later, realizing that we’ve completely forgotten what we paid but found we’re still acutely aware of whether we got what we wanted.  Our goal is to ensure that when you buy a Hamilton Laboratories product, you will be happy not just the day you buy it, but for years to come.