Aug 95 Dialog Box
|Column Tag:||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 Engsts 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 isnt 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 theyve been paid, just like used car salesmen.
To get around the service provider roadblock, Ive 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 BSed by the Provider. So Jon Wiederspans article couldnt 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 Wiederspans article wont 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
[You asked for it - you got it. In this issue and in the last issue (July), you have a two part series on CGIs. Jon will continue to give us coverage of Internet related topics and how they relate to the Macintosh development community. Let us know what you think and what more youd like to see! Ed. - nst]
There is a reason!
In the July issue of MacTech, Guy Nicholas asks, and Neil Ticktin echoes, the question: If they care, why doesnt Symantec use .SYM debugging information, since its 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 MPWs performance (or comparative lack thereof, Steve Jasiks 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 its not practical to use a debug-table model thats 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 its 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 youre constrained by the amount of information thats 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 cant 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 doesnt.
The point of all this, I guess, is that a companys 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.