Dialog Box

By Neil Ticktin, Editor-in-Chief/Publisher

Internet Coverage Keep it coming

I am very pleased with the May ‘95 issue, in particular with the article by Jon Wiederspan, “Your Very Own Web Server - MacHTTP”. When I got back into programming after doing other things for several years, I balked at learning the Symantec C environment (give me a quick and dirty batch file for compile and link any day) and the 5,000,000 system calls for the Mac OS.

Besides, what I really wanted to do was play on this Internet thing I kept hearing about. So I ramped up on serial communications, plowed through Adam Engst’s Internet Starter Kit for Macintosh, surfed for HTML tutorials, got enlightened with Netscape, and then slammed head-on into the roadblock of UNIX and the Local Internet Provider.

Based on my experience with my soon-to-be-ex provider, the biggest problem with newbies getting on the Net isn’t with the technology learning curve, but with the local access provider, that promises high speed and reliable lines, full Net access, and the ability to publish Web pages. Those promises turn to dust, however, as soon as they’ve been paid, just like used car salesmen.

To get around the service provider “roadblock,” I’ve begun to learn UNIX, and have considered setting up my own HTTP server, so that I would have a better understanding of how the Web works, which would allow me to avoid being BS’ed by the Provider. So Jon Wiederspan’s article couldn’t have come at a better time.

Please continue to publish articles on the behind-the-scenes mechanics of the Web and other Net server/clients. Integrating the HTTP server with a database would be a good topic, especially if the ’base contained different media. For instance, The California Museum of Photography web site, at the University of California, Riverside, runs off of a MacHTTP server and serves pictures.(see http://cmp1.ucr.edu/)

I hope that Jon Wiederspan’s article won’t be the last one on Mac based HTTP servers, and that there will be more about the other behind-the-scenes mechanics of the Internet. These server-side articles would be invaluable to the Net community, as well as to the Internet consumer.

- Stephen McManus

There is a reason!

In the July issue of MacTech, Guy Nicholas asks, and Neil Ticktin echoes, the question: “If they care, why doesn’t Symantec use .SYM debugging information, since it’s a standard?”

There are a couple of technological reasons: First, the .SYM format is not well suited for incremental-linking environments like Symantec C++. The .SYM format is designed around the older operating model which entails doing a complete build of the application, including the link step, and then running the resulting program with a separate debugger. This works well with MPW, but many of us are familiar with MPW’s performance (or comparative lack thereof, Steve Jasik’s IBS notwithstanding). As a counter-example, Metrowerks CodeWarrior also uses the .SYM format, and it works well with CodeWarrior, because CodeWarrior performs a complete link and build of the application (and it does so very quickly), and runs the program under test with a standalone debugger.

THINK C/Symantec C++ has always linked incrementally, and so it’s not practical to use a debug-table model that’s built around a full link step. (Imagine having to do a “Build Application” whenever you wanted to debug your program.) Symantec C++ 8.0 does take a different approach to linking, and so it’s conceivable that the debugger could understand the .SYM format. But this brings us to the next significant technological issue:

The .SYM format is limited. If your debugger is .SYM-driven, then you’re constrained by the amount of information that’s recorded in the SYM file. One of the greatest strengths of the old THINK C debugging environment (which is carried through in Symantec C++) is that the debugger has access to (for all intents and purposes) the same symbolic information that the compiler has access to, for a given context. In some instances the debugger calls upon the compiler to evaluate expressions. This means that, for example, you can use macro names and function calls in an expression in the Data window, which is something you can’t do in any .SYM-format debugger today. Of course, the .SYM format may someday be extended to support this kind of debugging, but right now, it doesn’t.

The point of all this, I guess, is that a company’s choice of technological paths is rarely, if ever, driven by whether or not (or how much) the company “cares”. The choice and implementation of technology is instead driven by the character of the problem that needs to be solved, and by the design constraints extant at the time.

- Rich Siegel
Founder, President, & CEO
Bare Bones Software, Inc.