|
Be Newsletter
Issue 31, July 10, 1996
Table of Contents
BE DEMO TOUR IN TEXAS: See You
There Next Week!
- JULY 16
University of Texas at Austin
WHAT: Austin BUG Meeting Demo
WHEN: 6:30 pm, Tuesday, July 16
WHERE: Taylor Hall 2.106 (2nd floor, room 106),
University of Texas at Austin (Taylor Hall is on the
corner of Speedway and 24th)
MEETING NAME (for registration): UT-Austin Tuesday
- JULY 17
University of Texas at Austin
WHAT: Austin BUG Meeting Demo
WHEN: 6:00 pm, Wednesday, July 17
WHERE: Goldsmith Hall 3.120 (3rd floor, room 120),
University of Texas at Austin (Goldsmith Hall is on the
corner of Guadalupe and 22nd)
MEETING NAME (for registration): UT-Austin Wednesday
FOR MORE INFORMATION: The Austin BUG has provided maps
to aid your search for Taylor and Goldsmith Halls. See
http://www.be.com/user_groups/events/austin.html on the
Be web site.
- JULY 18
University of Houston at Clear Lake
WHAT: Be Demo at the Institute of Electrical and
Electronics Engineers (IEEE), Galveston Bay Section
meeting
WHEN: 6:45 pm, Thursday, July 18
WHERE: Bayou Building, Forrest Room (next to cafeteria),
University of Houston at Clear Lake
NOTE: This demo is being held during the IEEE Galveston
Bay Section meeting, with an optional social and dinner
beforehand. The social begins at 5:30 pm with dinner at
6:00. If you're interested in attending the social &
dinner, please contact Charlotte Garner at (713)
333-6131. Attendance at either event is not required in
order to attend the BeBox Demo at 6:45.
MEETING NAME (for registration): IEEE Meeting
- JULY 20
Dallas, Texas
WHAT: Be Demo at the Apple Corps (Macintosh) Meeting
WHEN: 8:30 am, Saturday, July 20
WHERE: Informart, Room 7001, 1950 Stammons Freeway,
Dallas, Texas
MEETING NAME (for registration): Apple Meeting
WHAT: Be Demo at the SCOPE Meeting (Commodore and
Amiga)
WHEN: 1:30 pm, Saturday, July 20
WHERE: Informart, Room 3008, 1950 Stammons Freeway,
Dallas, Texas
MEETING NAME (for registration): SCOPE Meeting
REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail
bedemotour@be.com to
register for either event. Please tell us your name, the
names of the people coming with you, and the meeting name
(UT-Austin, Tuesday or Wednesday; IEEE Meeting; Apple
Meeting; or SCOPE Meeting). Admission for unregistered
guests will be on a first-come, first-served basis.
BE ENGINEERING INSIGHTS: DR8
Sneak Preview: Semaphore & Port Changes
By Dominic Giampaolo
One of the first things most developers do when given a
new operating system is to peruse the APIs to get a feel for
what's there, what isn't, and what should be. Most of our
developers have done exactly that and voiced their opinions
on a number of issues. In looking at the Be OS kernel API,
the first thing that strikes any classic OS weenie is the
lack of nonblocking versions of
read/write_port() and
acquire_sem(). We've been chastised for this,
so we implemented additional functions for DR8 that offer
solutions to these problems. Let's start at the bottom:
Semaphores. In reviewing the semaphore API we noticed that
the function names were getting a little out of hand. For
example, there were four versions of the
semaphore-acquisition function:
acquire_sem(sem)
acquire_sem_count(sem, count)
acquire_sem_timeout(sem, timeout)
acquire_sem_count_timeout(sem, count, timeout)
The kernel had several more versions of these functions
with even longer names. Clearly this was not an API that
could grow. For DR8 there are now only two semaphore
routines:
acquire_sem(sem)
acquire_sem_etc(sem, count, flags, timeout)
The new routine, acquire_sem_etc(), allows
for a bit more flexibility in specifying how you want to
acquire a semaphore. The 'sem' and
'count' arguments are of course the same as
before. The new 'flags' argument lets you set
certain attributes when acquiring the semaphore; in
particular, you can set the semaphore's "apply timeout"
flag, B_TIMEOUT. By applying the timeout and
passing a timeout value of 0, you tell the acquisition
function that you don't want to block. (In DR7, a timeout of
0 meant "wait forever").
Given the presence of a nonblocking semaphore, it becomes
trivial to implement nonblocking read_port()
and write_port() functions (in fact it took
less than five minutes!). The implementation mirrors that of
acquire_sem; the following functions are new
for DR8:
read_port_etc(port, code, buf, size, flags, timeout)
write_port_etc(port, code, buf, size, flags, timeout)
port_buffer_size_etc(port, flags, timeout)
The 'flags' and 'timeout'
arguments to these routines follow the same conventions as
the acquire_sem_etc() routine. So by combining
the B_TIMEOUT flag with a timeout of zero you
can do nonblocking port operations. Of course you can
specify longer timeouts if you desire.
The use of small or zero timeouts does raise some issues
though: One fear we have regarding the nonblocking functions
is their potential for abuse. The functions make it easy to
write a program that constantly polls a port or semaphore
and simply burns CPU cycles while not accomplishing any
useful work. Doing that is what some people refer to as "A
Bad Thing"; something we'd like to avoid. And so let us
state up front that using a zero or very small timeout to
constantly poll a port or semaphore is not acceptable.
How do you use these routines in a well-behaved manner
then? One example is our Browser, which has a thread that
periodically does some work and needs to know when to exit
so it can cleanly free data structures, and so on. A way to
accomplish this is to have the thread do a nonblocking
acquire of a semaphore before it does its work, and then
release the semaphore when it's done. When the Browser wants
the thread to exit it simply grabs the semaphore and does a
wait_for_thread(). When the work thread
attempts to acquire the semaphore in a nonblocking manner,
it will get an error code (because the main Browser thread
acquired the semaphore). When the work thread fails to
acquire the semaphore it knows it's time to exit. This is a
very simple mechanism that requires very little extra code
in either thread while producing clean, consistent results.
As another example, consider a program where a background
computation thread (rendering, FFTs, and so on) works on
data while a front end allows a user to manipulate a GUI.
Suppose that while the computation thread is running the
user adjusts some parameter that affects the computation.
Instead of waiting for the computation thread to finish
before being able to inform it of the changes, the GUI
thread can send the computation thread a message to tell it
to restart. The computation thread can periodically poll for
these messages by doing a nonblocking read of a message
port. This is of course much cheaper and easier to do than
creating and killing threads on the fly. It also falls
outside our admonition about burning CPU cycles needlessly,
because the computation is performing useful work.
Of course nonblocking port operations aren't the only use
for the timeout parameter. The use of longer timeouts is
very handy when you want to avoid hanging on a client or
server that fails to respond within some specified time. By
using timeouts you can improve the robustness of your
applications and make them impervious to misbehaving clients
or servers (also known as"A Good Thing").
These are just a few of the avenues you can explore with
nonblocking and timeout-based semaphore and port operations.
We hope that this functionality will allow you, our
developers, to more easily create applications that wow,
excite, and titillate the public (OK, maybe not titillate,
but at least excite and wow).
BE DEVELOPER TALK: Technical
Magic
By Gary JP Hewett
E-mail:
techmag@ibm.net
I've always been an entrepreneur, writing database and
production automation software for large catalog and mail
order companies. The technology in this field has a long way
to go, but I'm excited about being a part of the process.
There's a certain satisfaction in getting clients -- who
aren't necessarily technically literate -- involved in the
process of designing the tools that they'll be using. Even
the smallest indoctrination can prevent the horror of the
ill-informed client who asks for miracles and then merely
shrugs when we deliver them.
There are four of us at Technical Magic. We've been
spoiled for years working with NeXT software, but the
integrated database on the BeBox was an ultimately
compelling feature. More than anything else, we need a
machine that has good database tools, reliable performance,
and network scalability. I've only had my BeBox for about an
hour so far, but things look exciting. It seems that there
may be some nasty font issues, and Orb has crashed the
machine a couple of times, but I'm impressed with the dual
processors and graphics appear real snappy. I've got more
than a few things yet to find in there I'm sure!
In the short term we hope to evaluate platform
development tools, and then build baseline business
software. (Time and Contact Managers, Financial Products,
and so on -- I figure all those prosperous Be developers
would like to count their coins on a BeBox, right?) Recovery
software might also be an area I'll explore. I'd also like
to develop hardware that attaches to the GeekPort(TM) --
break-out boxes and other attachments.
This is, of course, a young machine that will create a
new market. One of the exciting things about the BeBox is
that because of its newness, I can influence the markets
that are created. We'll see.
"Are You Crazy?"
By Jean-Louis Gassée
We've said it many times: Harness a new platform (ours)
to the Internet, and you create a great opportunity for
small, unenfranchised software developers. On older
platforms, a few dominant players, mostly US-based, can use
their muscle to prevent fledgling new entrants from reaching
critical mass. And without the affordable promotion and
electronic distribution made possible by the Internet, young
companies are killed by the expense of marketing.
As a result of what I've said and left unsaid, several
readers of this newsletter have questioned our apparent bias
in favor of smaller software developers. Your messages were
invariably tactful -- but the subtext was clear:
"Are you crazy?"
"Aren't you better off courting the established players,
getting them to port their most successful applications to
the BeBox, rather than looking for the next John Warnock or
the next Mitch Kapor amongst the Diaspora of unwashed
geeks?"
You've got a point.
One could make a nice list of industry-trusted, media- or
communications-intensive applications that would look great
and run even better if ported to the BeBox. Name your
domain, from image processing to video editing, from
multimedia authoring to digital audio, web services and
software development for other platforms... Each time, a
handful of titles comes to mind. Isn't this the best way,
the only way perhaps, to find the "tractor application" the
BeBox must get, or die?
The argument is seductively simple and intuitively
obvious. But a couple of observations play against it. The
first observation comes from past history. If memory serves,
no new platform took off as a result of a port from an older
one. For instance, none of the DOS or Apple ][ applications
that were ported to the Macintosh actually helped the Mac.
On the other hand, the home-grown PageMaker did (and, later,
also became successful on Windows).
The second observation, or factor, is short-term
economics. The primary business of any large company that's
already successful on Windows or the Mac is fighting the
competition and supporting existing customers. The
short-term return on an investment in a new platform with a
small installed base doesn't look good on Wall Street.
Still, let's assume that there exists a Be champion
inside one of the fast-moving, successful software
companies. She or he convinces management of the long-term
benefits of betting on the Be platform, gathers political
support inside the organization, and gets the human and
financial resources needed for the port. What's required to
complete a product that works and sells?
- Stable management support is a must. Without it, the
best people on the team will be pulled away to put out
other fires in the product line.
- A combination of political and technical astuteness
is also required. This gets a little touchy. A straight
port might be the easiest political sell inside. But
technically, and in the eye of the paying customer as
well, it might not make the most sense. For the "port" to
make technical and commercial sense, a substantial amount
of redesign might be required.
- Finally, the project needs a dancer's light tread to
balance what must be said and what must be done in order
to reach successful completion. Arabesque.
In the end, working with a large, established player
means working against the conservative forces generated by
its very success while using its momentum to help our
platform take off. By now (I hope) I'll have confused our
esteemed readers enough to convince them that working with
the leading software companies isn't "do or die" -- it's not
a slam dunk. For example, we'd be flattered to see a
"straight" port of Photoshop work on the BeBox, but we'd
rather convince Adobe to do on the BeBox what we did
ourselves: Maximize the benefits of innovation by shedding
the baggage from the past. We don't know yet if they or
their colleagues will do it, or if a small company will, but
we'll do our best to find out.
BeDevTalk Summary
BeDevTalk is an unmonitored discussion group in which
technical information is shared by Be developers and
interested parties. In this column, we summarize some of the
active threads. To subscribe to BeDevTalk, visit the mailing
list page on our web site:
http://www.be.com/about_be/mailinglists.html.
- ---WEEK
3----------------------------------
Subject: Suggestions for a Help system?
A/K/A: HTML Help Files
More HTML talk: It was suggested that a proposed
"super-HTML" be used to encode entire interface layouts.
- ----WEEK
2----------------------------------
Subject: OpenDoc
A/K/A: Live update OLE? NO!
A/K/A: OLE, OpenDoc
The OpenDoc debate flared up when it was suggested
that OLE might be a welcome addition to the Be OS. Many
listeners wrote in to object, citing authorities and
their own experiences. It was suggested that the cogent
questions are not about the quality of OpenDoc, but 1)
should Be use OpenDoc simply because it's an available
standard, 2) is OpenDoc so widely accepted that it would
be dumb not to support it, and 3) if it's actually
accepted now (or soon) how long will this acceptance
last?
- ----NEW-------------------------------------
Subject: Memory usage
Some confusion over RAM, VM, the disk cache, and other
memory matters: Does VM exist? Can it be configured? Why
does the BeBox immediately eat up nearly all available
RAM?
THE BE LINE: Yes, VM does exist and, no, it can't be
"configured." The latter is a feature, not a bug. (You
can lock data into RAM by using "areas" -- see the Kernel
Kit -- but beyond that, the OS does the driving.)
Furthermore, the VM system has been improved in DR8 for
more efficient paging.
Regarding the "where'd all my RAM go?" business: The
phrase "available RAM" (as used by Pulse, for example) is
a misnomer in a VM system, particularly as it connotes
evaporating resources. Rejoice when your machine is using
nearly all its RAM; that's what it's there for.
- ----NEW-------------------------------------
Subject: BeBox slower to boot lately?
Why does rebooting a heavily file-laden BeBox take a
disproportionate amount of time?
THE BE LINE: There are some boot-time database
integrity checks that will be removed once we're sure the
database is unimpeachably stable. This series of checks,
whose duration is related to the number and size of the
files on your disk, is the primary cause of the boot
delay. The checks will probably remain in place until the
file system rewrite (post DR8). We apologize for the
inconvenience.
- ----NEW-------------------------------------
Subject: OS Suggestions
Be should provide a way to programmatically retrieve
and set the colors that are used to draw GUI widgets (the
encapsulation of such was termed a "pen"). When it was
pointed out that a single widget is often a blend of many
colors, the proposition became: The programmer should be
able to declare a window's title bar to be blue (for
example), and the system should provide all the
appropriate shading within the bar.
On other subjects, developers are yearning for UI
guidelines and for the scoop on "App Modeler," the
GUI-building tool.
THE BE LINE: The UI guidelines and App Modeler will be
part of DR8.
- ----NEW-------------------------------------
Subject: View/ListView and font info
An initial query about how to retrieve font info
turned into a discussion of whether it would be more
intuitive/easier/elegant to express coordinates as a
device-independent measure (as compared to the status quo
where points == pixels).
THE BE LINE: Monitor-dependent point measurement
greatly enhances drawing speed and app server efficiency.
We don't expect this to change.
- ----NEW-------------------------------------
Subject: /proc needed?
The necessity and desirability of the traditional UNIX
/proc and /dev directories was debated.
- ----NEW-------------------------------------
Subject: BASH and PS1 expansion
How do you set the shell prompt to display the current
working directory? A number of solutions were offered.
The cleanest was this (type this in a shell to test it;
add it to your .profile when you're happy):
PS1="`pwd`> "
- ----NEW-------------------------------------
Subject: Better keyboard shortcuts for Edit, etc.
Some folks are frustrated by the keyboard bindings
used by Be's text editors. The Home and End keys, in
particular, are less than ideal: They put you at the
beginning and end of an entire document; some folks would
rather they operate on the current line. A repeated-key
solution, cribbed from BRIEF, was suggested: 1st Home
goes to the beginning of current line, 2nd is the top of
the screen, 3rd is the top of the document.
In general, consensus favors user-settable keyboard
bindings and "swappable" editors (such that you could use
the editor of your choice from within the IDE, for
example).
- ----NEW-------------------------------------
Subject: Message interception
Application A can't intercept system messages intended
for application B; nor can you find out which window the
cursor is over if that window isn't yours. A call for
both features was made. The utility of the
get-me-the-window feature was questioned: What could
application A *do* with application B's window? After an
initial muddying of objects and pixels, an answer was
offered: Application A could send a message to the
"foreign" window.
- ----NEW-------------------------------------
Subject: What about the desktop?
It was suggested that the Browser allow icons to be left
on the "desktop" (a la the Mac). But does a desktop filled
with icons look too cluttered? As an alternative, the dock
could provide "drawers" for storing multiple icons (this
would replace the current dog-eared stack of icons).
|
