|
Be Newsletter
Issue 60, February 12, 1997
Table of Contents
BE ENGINEERING INSIGHTS: Porting the BeOS to your Toaster Oven
By Robert Herold
Life used to be easy. There was one machine to support, and
the guy who designed it worked down the hall. There was
hardware with logic analyzer cables draped everywhere,
revealing the most intimate details of how the missing bits
were being dumped on the floor.
Be's foray into the Macintosh market has complicated life
considerably. The Apple Developer CD has block diagrams for
what boil down to seven different PowerPC-based machine
architectures. Clone vendors have added their own riffs on
the theme -- multiprocessing hardware from DayStar, graphics
controllers from ATI and IMS, PCI-PCI bridges, ATAPI CD-ROM
drives, and the list goes on.
Many people have asked why the BeOS doesn't run on THEIR
Macs. Given sufficient time, effort, and money, the BeOS
could run on anything. In the end it boils down to a
business decision -- how hard will the port be, how much
time do we have, how many machines are there, and will there
be and what are the technical and marketing benefits.
With your indulgence of one paragraph of whining, I'll offer
the following. We're a small team of engineers -- sixteen
software, four Q/A, three documentation, one build guy, and
one-who-must-be-obeyed project manager. We're constantly
trading off between supporting more machines with our
current software and moving the BeOS architectural stake
forward. (To say nothing of distractions like the van that
just burst into flames in front of our office -- comments
that there may have been a PowerBook on the front seat are
completely uncalled for.) We want the BeOS to run
everywhere, but we still have to finish the !@#$ thing.
Developers need a stable API to write to, yet they require a
sufficiently rich feature set to add their magic touches to.
Venture capitalists are eager for some return on their
investment, and Be's checking account balance only seems to
shift right (fortunately the sign bit isn't set).
In the upcoming DR9 release we're laying the foundation to
support a wider variety of platforms. The new extensible
file system architecture is the first evidence of this
effort. On the low-level front, our intent is to distill the
experience of porting the BeOS from Hobbit to BeBox(TM) to
Macintosh into the specification of a hardware abstraction
layer (HAL). Ideally it will be possible for a company to
slap together a new computer, write a little firmware, and
poof! a new BeOS machine is born.
The HAL isn't designed yet, so I'll do it here. It should
address the following:
- Firmware-kernel interface: How and where the firmware
loads the kernel and passes information to the kernel
- Processors: How other processors are started, and how the
processors interrupt each other
- I/O: Which processor(s) handle I/O interrupts, and how
they're dispatched
- Physical address map: Where the memory, I/O, busses, and
ROM are, and how they're mapped into the BeOS logical
address space
- Configuration: What I/O devices are present
- Power: Controlling power consumption, and restarting or
shutting down the hardware
Shameless imitation is an option as well. Our friends in
Redmond have solved this problem, as have other operating
system vendors. No point reinventing the wheel...
With the decision to stop making the BeBox, Be has committed
to the path of supporting Other Peoples' Hardware. This road
isn't without peril -- there's an incredible variety of
hardware out there, all developed to work with some other
operating system. We face a formidable challenge in
propagating the BeOS across as much of this hardware as
possible, while still improving the BeOS architecture. Time
to get back to writing code.
News from the Front
By William Adams
So I was over at Nanny Jan's this morning trying to figure
out the appropriate Georgism to introduce this week's
article. As I was dropping off Yasmin, I found this toy on
the table. It was some super destructor battle cart thingy
that had a winch with string that was all tangled around it.
Being the father that I am, I proceeded to try to unravel
the string and restore the toy to its original place in the
hierarchy of devices of mass destruction.
I struggled for a while, pulled here and there, managed to
get quite a long way. Then I found that if I used a needle,
it was a lot easier. Then it seemed I had come to an
impasse. The work was too intricate and too tight, and I
couldn't really see what I was doing. So Nanny Jan, in her
infinite wisdom, asks me, "Should I turn on the light?"
One of the most fun things about being a pioneer on the
bleeding edge is that you get to blaze new trails, creating
a path for others to follow. The most successful pioneers
didn't necessarily invent completely new wagons and horses
in order to blaze the trail, but they used the tools at hand
and improved upon them. As a programmer, I'm a scrounge.
I've long since found that if someone has already created an
algorithm or data structure that suits your needs, it's
probably better to start from there rather than from
scratch.
I'm continually amazed at the neat things that programmers
do, and it's particularly amazing when someone explains a
new algorithm or routine to you in such a way that the light
turns on in your head and you think, "it's so obvious, I
knew it all along." Well this week I choose to delve into my
sordid Objective-C past and pull out what I've found to be
quite a useful tool.
Way back in the days of Mission Critical Custom Apps we
created two of the most important objects known to
programmer: DataSet and TableField. Between these two
objects, no typical MCCA stood a chance of evasion from our
skills. Combined they form the basis of a nice RDBMS local
cache with write-through persistence sort of thing. The
basic idea is that you have a bunch of data that can be
categorized into a bunch of 'records,' standard row/column
stuff. You want to add records, delete them, find them, and
all that.
It's similar to the BMessage object, but different in
purpose. A BMessage can hold a bunch of opaque data, and
it's primarily meant for messaging, not as the basis of a
record manager. On the other hand, DataSet is the basis for
in-memory relational set operations, among other things. We
discovered that these objects have much greater use beyond
that of their initial database design. So this week I
present a shadow of its former self, the DataSet library:
ftp://ftp.be.com/pub/Samples/dataset.tgz
If nothing else, you'll find a bunch of funky C++ code
straight from the heart of darkness.
Geoffrey Woodcock has been at it again. His multi-user
scratchpad tutorial is coming along. It makes for an
excellent tutorial on our developer web pages. You'll learn
about networking in our multithreaded environment and some
other funky threading issues.
But this guy just can't stop. No sooner does he finish his
tutorial than he starts on our developer support system.
Under promise, over deliver, that's our motto. When it's
done, you'll be happy with the results. It's quite
impressive stuff, and it makes me happy to know that he's on
our side. This will be the basis for allowing our developers
to be in closer contact with us and have a better handle on
the pitfalls that might be known in the system.
Since we introduced the MacTech PowerPC version of the BeOS,
there's been quite a flood of activity for technical
support. Well now has come the time to differentiate
"developer" support from "customer" support. Not all people
currently using the BeOS are developers. Questions like "how
do I partition my Mac hard disk" and "will the BeOS work on
my PowerBook" are not really software developer questions.
As DR9 approaches, I'm sure we'll get a rash more of these
questions. So now you have a new place to e-mail to for
answers.
custsupport@be.com
Our web page reflects this change, and you can use this
address whenever you have a configuration type of question.
The simple test is, if you have a programming question, then
fill out the Developer Support form in the Registered Developer Area. This is also
the case for questions related to developer IDs, conference
registrations, and general introductions to the rich and
powerful. If you have any other questions, such as what
Power Macs are supported or why you can't configure your
particular machine to run the BeOS, send them to the
custsupport@be.com address. What you'll find right now is
that all of the questions will be answered, no matter which
way you send them, but it helps us to categorize them. In
addition, we want to encourage you to use our web page for
as much information as you can. It's extremely helpful if
you read the FAQ in our support area for typical questions
regarding installation.
Well the year's starting out smoothly, DR9 chugs along, and
GCC has been ported to the BeOS.
See you next week.
Heidi Roizen
By Jean-Louis Gassée
Yesterday Heidi Roizen announced that she was leaving Apple
by February 19. She's been VP of Developer Relations since
January of last year. Her stated reason for leaving is her
desire to spend more time with her two young children.
There's enough press dissection of the circumstances
surrounding her decision for me to leave it at that.
I'd rather pay tribute to Heidi. She came in and helped
Apple through difficult times when developers, unsure of the
future of the MacOS, needed someone to be their liaison with
Apple's management, their visible, believable champion.
Heidi is a former Mac developer herself: She headed T/Maker,
sold in 1995 to DeLuxe. She had both the experience, the
skills, and the charisma to be the standard-bearer for the
Mac community. Words such as "irreplaceable" can sound
excessive, but it will be hard to find someone to replace
Heidi, someone who will enjoy as much trust and respect in
the Mac development community as she does.
Closer to home, Heidi has been instrumental in helping us
port the BeOS to Power Macs and clones built by Power
Computing, Motorola, UMAX, and DayStar. She felt the PowerPC
family needed more players, more momentum, more excitement
in order to reverse the market share slide, and she thought
we could help a little. When red tape or organizational flux
got in the way, she got things back on track. As a result,
we were able to show a first version of the BeOS running on
Power Computing hardware in August 1996, at Macworld Boston.
Without her support we wouldn't be where we are today. Her
influence helped open a larger hardware playing field for
the BeOS and, as a result, for our developers. Moving to the
Mac hardware family and finding several attractive
multiprocessor systems allows us to focus solely on the area
where we add the most value, software.
We now have a simple goal: To become the OS of choice for
creative digital media applications. And we're in Heidi's
debt for her role in simplifying our business.
I don't know what Heidi will do now. Certainly she'll want
to take a break after a tumultuous year at Apple and spend
time with her family. Still, I can't imagine her not
wielding her considerable skills and influence on the
Silicon Valley scene. I imagine venture capitalists calling
her, and I can see quite a few start-ups wanting to enlist
her leadership skills. It will be fun to watch.
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- -----WEEK 3---------------------------
Subject: GUI (in)consistency
AKA: Issues for PC makers (GUI & plug+play)
AKA: More GUI questions
Religious question of the week: Is anything intuitive on a
computer? Does the user bring inborn (or culturally
developed) preferences for the placement of menus, their
stickiness, "moused-ness," and so on?
Practical issues and sound bites:
- Main Menu Placement
"[H]aving a *defined* place for a main control menu is a
good [idea]... It's a lot quicker... than [digging] through
a mess of windows."
--Pete Goodeve
"For a [new] user... the placement of the main menu is
probably not very easy to figure out. [But] once it's
[found] I find it hard to understand anyone saying that it's
hard to remember... I think the main problem with it is that
it's awkwardly placed. It takes a lot of mouse movement...
to access it."
-- Brian Stern
"...in Windows you get a default menu by clicking on the
left-hand-side application button (used to be the kill
box)... I don't necessarily want BeOS to look anything like
Windows, but the advantage of this extra menu is that it's
logically part of the window it applies to. There's no need
to mouse up to the top of the screen."
--Dave Haynie
- Window Clutter
"I (almost) always hold down the 'control' when opening
windows, because I *know* where I want to go... Another cool
thing to do would be able to open the *directory* a file was
in with "open parent," in case you killed all the windows on
the way to the file."
--Evan Knop
- Modal Dialogs
Maarten L. Hekkelman asked "when should a dialog be modal
and when non modal?"
"I would take the position that a dialog should be modeless
unless the interaction HAS to be executed before it is
meaningful for other activities to continue."
--Andy Philpotts
"Almost all algorithms can be structured such that the
program doesn't NEED the information to go back and 'do
nothing' until the information arrives. It's just a little
more work for the programmer, but it gives a MUCH better
user experience."
--Jon Watte
- General UI Look
Jon Ragnarrson has posted his opinions in the form of a Web
page: http://www.vortex.is/Islenska/Notendur/jonr/Be/BeGui.html
- -----WEEK 2---------------------------
Subject: Be's hardware plans
AKA: Problems with BeOS only on powermacs
A cleansing facial mask of eulogy and malediction for the
late Blue Box punctuated by colorful slurs against the
corporate persona.
Listeners expressed interest in the specifics of the PIOS
box; some suggested that PIOS resurrect the BeBox design.
- -----WEEK 2---------------------------
Subject: lets talk about cursors
A particular cursor designation suggestion from last week --
each window (or area within a window) could register (with
the Application Server) a custom cursor image -- was
debated. The primary advantage of the system is that
changing the cursor wouldn't require a lot of data to be
passed between the client and the server. The primary
objection from last week -- context-sensitive cursors would
be difficult in this scheme -- was considered to be either a
price worth paying or a feature that could be worked into
the general plan.
- -----NEW---------------------------
Subject: Mail transfer
Can you tell the mail_daemon to retrieve mail messages
without deleting them from the server, such that you can
read your mail from different machines without having to
explicitly transfer the messages between computers?
A listener suggested that the easiest solution is an IMAP
server (Internet Message Access Protocol; see
www.imap.org/whatisIMAP.html).
Objections:
- IMAP doesn't fit well with Be's philosophy of a-message-
is-a-database-record.
- If you don't delete your messages occasionally, you start
to use up (possibly costly) server space.
- IMAP security isn't strict enough.
As an alternative, a listener suggested POP3, which (it was
claimed) has a feature set that's similar to IMAP -- in
particular, it can support multiple remote readers.
- -----NEW---------------------------
Subject: Database-only items in DR9
In DR9, every database record will be stored in its own
file, and the notion of a table as a predefined template of
attributes for a record disappears. The implications of
these decisions were discussed:
- File-based records mean there's no hidden data. Some folks
fear that this could lead to hierarchy clutter; others think
that the approach is a desecration of database principles --
they *want* hidden data.
- The lack of tables means that while you'll no longer be
able to make assumptions about the structure of a specific
file, you'll be able to query over a larger domain. A number
of listeners wrote in to support the idea that optional
table-like functionality be added to the new file system.
Most folks are pleased with the record-is-a-file business.
As Ficus Kirkpatrick put it:
"'Hiding' things in the database is sort of a security-
through-obscurity type of attitude. I've written a database
editor that I can browse tables and modify records with
easily. It's just something that you won't have to get a
separate app to do anymore."
Nonetheless, the database-only crowd was persistent. David
Evans:
"What we seem to have... is a filesystem with some added
database 'gizmos'... It basically removes the 'Record'
abstraction and makes database items an extra to files.
Other issues:
- What happens to pre-DR9 tables? How are they converted?
- Do the files that hold psuedo-records need to be named?
Can the system generate noncolliding "anonymous" names
automatically?
- What about security? Geoffrey Clements says he's working
on DCE (http://www.osf.org/dce) for the BeOS.
- -----NEW---------------------------
Subject: Highlighting ICONs
Icon highlighting questions: How do you highlight an icon?
When should it be highlighted/unhighlighted? When will icon
animation be allowed?
|
