Aug 95 Dialog Box
- Jan 95 Dialog Box
- Feb 95 Dialog Box
- Mar 95 Dialog Box
- Apr 95 Dialog Box
- May 95 Dialog Box
- Jun 95 Dialog Box
- Jul 95 Dialog Box
- Sep 95 Dialog Box
- Nov 95 Dialog Box
Volume Number: 11
Issue Number: 8
Column Tag: Dialog Box
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
[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 you’d 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 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.
Referenced by (2):