| Some short programming tips:
The first one is a plea against something I've seen in lots of public
domain software lately, that can only cause problems later on down the
road. That is, when creating a message port (either via CreatePort or
by doing it manually), it's usually not necessary to supply a name for
the port, and in fact doing so can cause additional overhead (albeit,
very small), and can prevent the proper operation of your program if
you're attempting to run multiple copies simultaneously. The reason
for this is that CreatePort will call AddPort to add the message port
to the system's message port list if your call includes a port name.
This is unnecessary if your program is not declaring itself as some
sort of system wide server. In fact, the only utility of AddPorting
your port is if you want to make it public, so that any other task in
the system can find it (via FindPort) and send it messages. If you're
simply creating a message port to communicate with some device driver,
that driver will by definition be able to find your message port,
because you're sending it messages with that port address supplied as
the reply port. In fact, many programs I've seen will supply a
port name to CreatePort (thus, implicitly making the port public),
then assume all messages received from that port are from the device
driver they're communicating with. This is setting yourself up
for disaster. For instance, you want to talk to the serial device,
and you create yourself a port with the name "serial.device", because
that sounds like a good name for the port. While this probably
won't preclude you from talking to your desired recipient, it can
cause trouble in multiple ways (in ascending order of painfulness):
It takes additional memory to store this name string when it isn't
necessary.
Calls to FindPort take longer than they need to.
Someone legitimately wanting to use this port name (or perhaps another
copy of the same program) will have a hard time, because now there
are multiple people with the same port name on the system list.
Some other task may find your port on the system list, and decide
it's a neat port to talk to (because, perhaps, you picked the same
name as some legitimate system resource, or just because the other
task thought it was an interesting looking port name). That task
would then start sending you messages, and if your code doesn't
check the source of all the messages it receives on a port, things
can go downhill pretty fast. For instance, if the code just assumed
that all messages received on that port were replies to something
that code sent, it would not only act improperly on the data received
(assuming contents that aren't there), but it would also fail to
reply to the original sender, possibly resulting in lost memory,
multiply allocated memory, etc.
Moral: Unless you're declaring your task as some sort of "public
utility" to the rest of the system, don't give it a name and AddPort
it (which CreatePort does for anything with a name).
The second tip is just something of a warning: A while back, I
was playing with a beta copy of 1.2, and in particular, the interlaced
workbench windows. It was pretty nice to get a 50 line screen,
so I recompiled a couple of programs to open CON:0/0/639/399/Foo
to make full use of the screen. That much worked ok, but a couple
of weeks later, I'd forgotten about the whole thing, and tried to
run those same programs under 1.1, which of course, doesn't support
such a large workbench window. The way it told me about it was
a system hang. Took me a lot of headscratching before I remembered
what was going on. Moral: Openning CON: windows that are bigger
than possible can fail in mysterious ways.
|