|
Be Newsletter
Issue 71, April 30, 1997
Table of Contents
BE EVENTS: Be Developer Conference on May 10 and 11
- MAY 10 AND 11: BE DEVELOPER CONFERENCE
If you're a developer for the Mac, UNIX, Amiga, Windows,
BeOS, or any other platform and want to know more about the
BeOS, please come meet with us at our Be Developer
Conference on May 10 and 11 in Santa Clara/San Jose, CA. For
more information and to register, please visit our Web site:
http://www.be.com/developers/may_dev_conf/index.html.
For more information about forthcoming stops on the Be Demo
Tour, please visit:
http://www.be.com/events/schedule/index.html.
BE ENGINEERING INSIGHTS: Making Life Easier
By Robert Herold
Usually during the course of a day, I encounter something
that is bothersome or just not quite right. The radio in my
car is too close to the cupholder, so whenever I put down my
coffee, the station gets switched from Howard Stern to Rush
Limbaugh. Loading a new bottle into the office water cooler
inevitably spills a few drops on the carpet. The sandwich
guy asks my views of mustard versus mayonnaise despite
having heard the full details just seconds earlier.
Porting operating systems to different hardware
architectures is no different. Every system from the
Rockwell AIM-65 through the Power Computing PowerTower Pro
dual 225 MHz 604e has quirks that must be dealt with.
Perhaps someday we'll design a system that's perfect, fast,
reliable, and easy to write software for. If whoever builds
it needs some unsolicited advice, I have a list...
LOGIC DESIGN
* Put in a software-readable version number. For chips, put
in a read-only register. For circuit boards, dedicate a few
I/O bits somewhere and put in some pull-up/pull-down
resistors to make a unique identification possible. For I/O
devices, put it wherever it's convenient. Whenever a change
is made, even one that doesn't affect the operation of the
software, change the version. Someday you'll be glad you
did, be it for manufacturing test, field service, consumer
recall, hardware debug, user interface, or geek fascination
with frivolous detail.
* Avoid write-only bits in registers -- let software read
back what was written earlier. Avoid bits that mean
different things when read and written -- chew up a little
decode space instead and put them in separate registers.
* Design registers that can have individual bits modified in
a single operation. This really helps when there's more than
one bus master mucking about the system, in that register
updates don't need to be protected with a software semaphore
lock. My favorite example is the 6522 VIA registers -- the
most significant bit controls whether you're setting or
clearing, and the rest of the bits have a one wherever a bit
is to be modified and a zero wherever a bit is to remain
unchanged.
* Document what you design, preferably in a way that someone
besides you can understand. Describe not only what it is,
but also what it's for. Anyone who's taken a tour through a
data book for a modern VGA graphics controller can
appreciate this. Better yet, include some real (that is,
actually compiled, run, and debugged) source code that uses
your design. Keep the documentation available even after you
stop selling the part. Make the documentation easy to get --
and free.
* Avoid timing dependencies. Any synchronous protocol or
continuous input data stream is an exception of course, but
even there you can help by providing a bit of buffering in
your hardware. Putting a 5-million transistor 225 MHz
screamer into an interrupts-disabled spin loop waiting for a
few microseconds to pass before writing to the floppy
controller again due to some empirically observed resistance
to being written faster is not the best use of available
MIPS.
SYSTEM DESIGN
* Make physical RAM contiguous. It's just easier that way.
* For multiprocessor systems, it's nice to be able to direct
I/O interrupts to different processors to distribute the
load. Also, it's nice to be able to turn off all I/O
interrupts to all processors in a single operation and to
turn them back on later, while still allowing interprocessor
interrupts.
* For CPUs, it would be nice to separate I/O interrupts from
interprocessor interrupts; having a different pin, a
different interrupt vector, and a different interrupt enable
is ideal.
* Resources that are duplicated across different parts of
the system should have support for synchronizing their
state. For instance, the PowerPC has a time base register
and a pin for enabling it. Without that pin (or without any
means of actually controlling that pin), it's impossible to
ensure the time base register has the same value on all
processors.
* For debugging, provide a means of doing a nonmaskable
interrupt to all processors, preferably from an optional
switch, and also from a software-accessible register. If
this is a recoverable interrupt in the CPU, all the better.
This will make OS designers everywhere think of you fondly
every time the system locks up and they can push a button
and get to a kernel debugger.
* Noncoherent caches aren't a good idea. A simple OS may be
able to deal with caches that aren't coherent with DMA
accesses, but anything beyond DOS or the maces will have
major conniptions.
* Plan for bugs. Leave a couple of I/O pins around to let
you control a PAL later, so you can do a quick turn on your
design to fix the bug in the new improved gizmo that
replaces the no-longer-manufactured old gizmo.
* Let the OS designer have one bit of visible I/O somewhere.
A place for a two-pin header where an LED can be hooked up
will do. Alternatively, provide a place to hook up a logic
analyzer.
* Expansion buses should be self configuring (for example,
NuBus) or software configurable (for example, PCI). For an
example of how not to do this, see ISA, SCSI, or IDE.
PHYSICAL DESIGN
* Make the case easy to open. See the Mac IIci for an
example.
* Put upgradable stuff where you can get at it. For an
example of how not to do this, try adding RAM to a Power
Macintosh 8500.
* Use the circuit board silk-screen for user documentation.
If you've made the mistake of requiring jumpers, describe
the jumper options right on the board.
* If you must use jumpers, put an extra one or two on unused
pins. Not everyone lives ten minutes from Fry's Electronics.
* Use the circuit board silk-screen to make it easier to
debug or probe. Label the chips with real names instead of
"U24." Then tag every tenth pin with its pin number. This
helps anyone poking around with a scope probe, and besides,
its cool to personalize what that black plastic behemoth is
doing millions of times a second. While you're at it, label
some test points for clocks and interesting logic lines.
* If you must use screws, use the same kind everywhere. If
they must be different lengths, at least make them the same
thread. Make sure your design holds together if any one
given screw is missing, because that screw always falls off
the desk and takes a four-hour vacation somewhere.
* Make it quiet. Otherwise, you can't use it while your
spouse is sleeping.
* Avoid sharp edges. I hate bleeding on my motherboard.
* Connectors should be keyed. If not, they WILL be plugged
in backwards. Lay out pins in connectors so that when
they're plugged in backwards, smoke doesn't appear.
* Why is it that whenever I plug in the little twisted wire
power LED, it's always the wrong polarity? Label the pins,
preferably with the wire color that they're supposed to
take. Alternatively, given the vagaries of wire color
selection by LED vendors, label the pins minus and plus, and
I'll just assume that the black wire goes to minus.
* If it's different, use a different connector. I'm sure
many parallel printers have been plugged into the SCSI ports
on the back of Macintoshes everywhere. And in ancient times,
9-pin monitor cables were plugged into serial ports.
* If it's different, make it obvious that it's different.
Can you tell the difference between a 3.5-volt DIMM and a 5-
volt DIMM? Why aren't they labeled? For that matter, why
aren't SIMMs and DIMMs labeled in the first place? Not
everyone knows how to read DRAM part numbers.
PEOPLE IN GLASS HOUSES SHOULDN'T THROW STONES
Hardware designers who read this article may react
defensively and start writing their own list about operating
system design. They're right to do so -- we're by no means
perfect. If you need to get something off your chest, send
it to herold@be.com.
A FINAL NOTE
A minor update to last week's newsletter -- the DR9
system_time() function will return the number of
microseconds since boot, not the number since January 1,
1970. We decided that it's important to have a monotonically
increasing system_time() value even across changes to the
system's real time clock. You can calculate the number of
microseconds since January 1, 1970, by using the ANSI C
time() function and the boot_time field in the system_info
structure.
BE ENGINEERING INSIGHTS: Doctor Nine
or
Life in a Sokio Tubway
By Baron Arnold
Believe it or don't, I'm actually writing this article under
DR9. Hiroshi's StyledEdit is on my desktop along with cool
DriveSetup, Disks, and Trash icons. "NuBar" hangs at the
top, keeping track of applications and windows, Pavel's
DigitalClock sticks seconds in the recessed right corner.
Over all, Doctor Nine is looking pretty good. (They sure
added a lot of stuff.) The QA Queen has called this the
"Release from Hell." When the QA Queen speaks, she speaks
the Truth. Weeks went by while the file system collapsed
beneath me. I'd step into Dominic's doorway, my figure
reflected in the window in the wall. With a glance and a
toss of his hair, he'd turn to me and inquire, "Spinning
forever?" But hey, what's a file system if you can't start 8
to 10 cp's of tar files, xvf them as they arrive in a new
directory, then gzip the lot and chop it into 1k pieces. Hey
dude, double indirect this. And isn't everyone going to be
running the mvaawhile shell script, renaming said folder to
aa, bb, cc, dd, ee, ff, on to zz and back to aa to start all
over?
Swap space is your friend.
One by one the big bugs got squashed, Dominic and I became
virtual lovers, but then the new file system stabilized, and
we started seeing other people.
See, I'm not happy unless something's breaking.
Robert Chinn, the King of the Underpinnings, spearheaded the
transformation of the top-secret BeLabs II, which now sports
new supports. Baby Macs and Daddy Macs are backed by BeBoxes
with cereal for breakfast, lunch, and dinner. Me? How could
I live without post-its?
It's pretty much round-the-clock here. We know you want it,
our software hardens your hardware and all. We're thinking
ahead. Big files, lots of RAM, cheap hard drives, flaky
video cards, network throughput, partitions. You wanna build
servers, games, interactive cross-pollinational subfactories
for new world estates. You want to Be in charge, you don't
want to wait. We will feed your need.
This is a Revolution, dammit.
We're not building the OK-OS.
Tomorrow morning (Monday) I become the Build King, and with
a keystroke sequence built by Ming (whose name, curiously,
is King with an M). I'll install and test the BeOS on every
family of PowerPC-based machine we support. Then my Queen
will ask for a report. Then I'll get lunch. Then I'll show
Cyril the VM deadlock thing, show Steve and Cyril the
dropping_notification thing, try to find the end of the
benoit_rainbow on this mouse_down thing, and the funny thing
is, they know what I'm talking about and you don't.
:)
As Bob Herold pointed out once, it's a strange and secret
language we speak here at Be, but keep your fingers crossed,
don't settle for less than what you love, raise your hands
and lower your fingers and believe there is a team of
brilliant engineers slaving tonight to bring you what you
need.
The BeOS, a fresh, modern, carbon-fiber Operating System.
We'll talk again halfway to Macworld.
News from the Front
By William Adams
DR9, DR9, DR9!!!
Let's see. How easy or difficult is it going to be to move
to DR9? Any time I mention C++ nasties, I get some sort of
response from someone. Last week was no exception. One
response to my statements about the introduction of const
was that things will be safer, another response was a
developer telling be how annoying const is and that they
finally learned how to cast it away. Also with the virtual
destructor business, on the one hand making virtual
destructors makes things safer, on the other, it bloats
class frameworks. The answer is, get yourself one of those
"Effective C++" books or the "C++ FAQs" book. These books
are invaluable to the beginning and very experienced C++
developer. If you read a snippet every day, you'll find
yourself saying "Oh, that's why that happens." DR9 shows
much improvement in safety and stability. A lot of this has
to do with much tighter C++ coding practices. If you're
coming from DR8, you'll notice new compiler warnings where
your code previously didn't generate any.
BView::KeyDown(const char *bytes, int32 keyCode)
If you overrode this in DR8, you probably had
MyView::KeyDown(long keyCode)
In DR9 this will generate a warning. Something about you
overriding something similar. This isn't strictly an error,
but your KeyDown will not get called! This is one of those
"subtle" differences. After you ignore our release notes for
DR9, and just try to compile your code, you'll come back
here and read these words:
IGNORE COMPILER WARNINGS AT YOUR PERIL
Compiler warnings are your friends and will make for safer
hex. The more you fix, the safer your code will be, and you
won't be staring at a debugger window more than your running
application.
DR9, DR9, DR9...
Ah, a stable release. We've got to have apps, we've got to
have apps! Ah, there's Fred Fish and his GNU efforts. Boy oh
boy, look at all those little command-line tools. Well, at
least we have autoconf and m4. Now it's much easier to
recompile the rest of that world. Dominic is a POSIX fool,
and he did quite a lot to make sure the file system was
quite POSIX looking. There are other additions to the OS
that make it even more POSIX compatible, so it would behoove
you to go out and get the "POSIX Programmer's Guide" if
you're so inclined. This thick purple book from O'Reilly &
Associates should give you all the information you want to
know about POSIX. We aren't a UNIX system, but it sure
doesn't hurt to implement the various POSIX calls so that
it's easier for people to write apps.
I want to compile! I need the IDE! Oh well, I'll use vim for
now. Ahh, the IDE has shown up, and it does Java! Oh boy, Oh
boy.
Let's see, first I'll do Tcl, then I'll do another rev of
the imaging thing:
ftp://ftp.be.com/pub/samples/interface_kit/imaging.zip
This one does fast scaling as well as the bilinear stuff.
And then another rev of the yags library to add the spline
support:
ftp://ftp.be.com/pub/samples/interface_kit/obsolete/yags.zip
And how about that zip and unzip thing. And what about a new
tvtuner? Say, what's that FireWire board doing in here? Oh,
wait a minute, I hear something... Yasmin sounds like she's
waking up... Just one more compile, just one more compile!
OK, OK, we'll go to the store and buy your birthday cake,
sorry I forgot. Here's a sandbox to boot. All right, we'll
give you a party next weekend, now can I port some more?
Oh yeah, sister-in-law's engagement party, relatives
visiting, water the grass, put the pool cover on.
I like this DR9 thing. I want to port that treeview code.
Oh, look, there's a hierarchical view widget included with
DR9? Well, how about some sound code.
ftp://ftp.be.com/pub/samples/media_kit/obsolete/sndutil.tgz
And what about that scrappy little MPEG-1 decoder? Can't you
make it a little bit more encapsulated so that multiple
MPEGs can be played at once? And why don't you throw a real
interface on it while you're at it.
ftp://ftp.be.com/pub/Samples/mpeg_play_dr9.tgz
OK, it's 2:30 am Monday, time to go to bed, you can play
some more tomorrow. With features like a real working fork()
instead of spoon(), and a system() call that returns the
proper values, DR9 is shaping up to be quite the solid
citizen. If you play safe and follow the rules, not only
will your apps be wonderful and wise, but they'll probably
run faster to boot. The Developer Conference is quickly
approaching, and I'm quite beside myself with anticipation.
Between now and then, we have a belated birthday party, some
major application porting, and some demo apps to write. This
is definitely a must-attend event. See you at the front.
More UI
By Jean-Louis Gassée
Windows are passeé, said an Apple scientist about twelve
years ago. The Mac was painfully taking flight right after
the Lisa "Spruce Goose." I thought reports of the demise of
windows were a tad premature. I even thought it was foolish.
I wasn't buying the story that the Mac (or PC) desktop had
to mimic my desk, but I thought windows were a really nice
way to separate contexts and to move them around. Windows, I
thought, fulfilled a durable need and, like the wheel, once
invented were there to stay. I still believe this -- and
more, as we say in my adopted country. What we could call
the classical way of UI evolution seems to have entered the
era of diminishing returns. As I type this, I remember the
original MacWrite with its simple menu bar. I use 1992
vintage Word 5.1a (on a PPC machine running both BeOS and
Mac software); Word 6 is frowned upon at Be, unless used to
demonstrate Virtual Mac performance under stress. On Word
5.1, much more screen area is taken by tool and menu bars
than in the original Mac word processors. It gets worse on
Word 6 and, on Windows Office 97, one can end up with a
debauchery of tool bars and palettes. In fairness, you can
go in and remove enough tool bars to go back to 94-95
levels. In the industry, the joke is, by the year 2000, the
screen area left for the actual meat of the document will be
the size of a first class $1.50 e-mail stamp. Joke or not,
there is an uneasiness about UI paralleling bloatware on the
hard drive.
There is hope. Netscape is demonstrating versions of its
future client, Constellation, parts of which will soon
surface in Netcaster. Sliding panes and tiles smoothly slide
in and out of view, allowing better use of screen and
desktop space and reducing the anxiety and confusion arising
from poorly presented access to huge volumes of local or
remote information. Windows, as units of context, are still
present, but in a streamlined, less obtrusive form. To a
more modest extent, this is the case with Explorer 4 in its
platform preview incarnation. The UI can be set to a
classical Windows 95/NT style, or it can deviate from it in
varying degrees, including going to a one-click Web-style
document opening. On the desktop, "raw" borderless Web
documents can be exposed, live or static. And they can be
dragged around, under the rest of the desktop, without
annoyingly jumping on top. Still at an early stage, parents
strongly cautioned, but really a more promising UI
exploration than Bob.
The more interesting UI developments come from smaller, more
creative players. MetaTools, for instance. In products such
as Goo, Kai Power Tools, and Bryce, they show how windows as
we knew them can vanish, how mouse gliding can cause tools
to appear and disappear, drawers to open and close, how the
use of translucent objects effectively reduces mental
clutter. Their next product, Soap, for cleaning digital or
scanned photos, offers such nice UI innovations for users
who don't need Photoshop. For the musically inclined, Eric
Wenger, the author of Bryce, has also written synthesis
software with similarly innovative and soon-to-be-classical
UI tools.
On this topic, I have two hopes. One is I'll get mail
pointing to all the products I obviously should have looked
at long ago. The other is that our new platform will be seen
as a fertile field for the development of the next
generation of innovative UI elements.
|
