|
Be Newsletter
Issue 46, October 23, 1996
Table of Contents
European Be Demo Tour
- Geek Weekend in Frankfurt, Germany, November 1-3
Our local geek correspondent in Frankfurt will organize a
three-day meeting where Be developers can share their ideas,
code, and feedback. For more information on this event,
please check:
http://www.beeurope.com/Demos/Thomas/festNov96English.html
- Apple Expo in England, November 6-9
Join us in the Computer Warehouse booth during the
exhibition at:
Olympia
Warwick Road
SW5 9TA
London, England
Demonstrations of the BeOS(TM) for PowerMac will also be
held at the Power Computing booth and at the Developers'
Pavilion in the Full Moon Software booth.
- Amiga Show '96 in France, November 9-10
The annual Amiga exhibition in France will host a Be booth,
where you can see the latest release of the BeOS and
developers' applications:
Espace Rene Fallet - 91560 Crosne - France
More information about all of these events can be found at:
http://www.beeurope.com/Demos/index.html
Be Demo Tour: BeBox Demos in Seattle and Bellingham
- Thursday, October 24, 1996, 3:30 pm
BeBox Demo and General Meeting
University of Washington at Seattle
Hitchcock Hall (Biology Building, just NW of the
Hospital/Med Center, near the corner of 15 Ave NE and NE
Pacific St.)
Room 132
- Saturday, October 26, 1996, 10:00 am to 1:00 pm
Firebug General Meeting and BeBox Demo
Western Washington University Campus
New Biology building - Room 234
More information about Firebug can be found at
http://www.abiogenesis.com/firebug.
The Be Team will demo the BeBox in in Nashville, Tennessee,
on November 4 and 5. For details about this trip as they
become available, visit the Events page on the Be web site
(http://www.be.com/events/index.html).
REGISTRATION FOR BE DEMO TOUR EVENTS: E-mail
bedemotour@be.com to register for any event. Please tell us
your name, the names of the people coming with you, and the
meeting name (UW-Seattle or FireBUG-Seattle). Admission for unregistered guests will be on a
first-come, first-served basis.
BE ENGINEERING INSIGHTS: Writing Netcard Drivers for the BeOS
By Bradley Taylor
A lot of Be developers have expressed interest in writing
drivers for all sorts of network media, such as ATM, 100VG,
100Base-T, alternative ISA and PCI Ethernet cards, PLIP, and
SLIP. In fact, I've had more requests about doing network
media drivers for the BeOS than doing anything else that's
network-related, whether it be alternative protocol stacks,
TCP enhancements, or application issues. It isn't what I
expected, but then again, things never are.
In response to the great developer interest in doing network
drivers, I'll do two things:
- First, I'll increase the priority of developing a netcard
driver architecture for BeOS, aiming for release in DR9.
- Second, I'll start an "early adopter" program where you
can get started with DR8. To enroll in the program, all you
need to do is read this article and download some stuff from
the Be FTP site. I won't ask you for money, date of birth,
spending habits, or how often you pick your nose.
Now, for some caveats and limitations:
- The DR8 version of the driver architecture will only
support Ethernet drivers or things that look like Ethernet.
In other words, your driver had better be prepared to read
and write 1514-byte packets, including the 14-byte Ethernet
header. The header contains the 48-bit destination address,
followed by the 48-bit source address, followed by the 16-
bit protocol field.
- A lot of things will change when the API is officially
released, so please don't start flaming me when your code
doesn't recompile or your binary stops working.
- The interface presented here is somewhat messy. Its
purpose is to get you started getting real work done, not to
be framed, placed lovingly upon a wall, and admired for
hours on end.
OK, now that we have that out of the way, let's get down to
business.
THE DR8 VERSION
For the DR8 version, an Ethernet driver consists of two
binaries. The first is the low-level device driver for the
card you're interested in. The second is a high-level add-
on, which is used to configure the card. For example, let's
say your card is the fictional "Ackme" card. Your device
driver would be stored in "/system/drivers/ackme", and your
add-on would be in "/system/add-ons/net_server/ackme".
The device driver needs the following standard device driver
entry points: open(), control(), read(), write(), and
close().
open(), in most cases, should always return B_NO_ERROR.
The actual opening of the card is performed by...
- ...the
control() call. There are two messages for the
control call: ETHER_INIT and ETHER_GETADDR. ETHER_INIT takes
card-specific parameters -- such as IRQ values or I/O port
numbers -- and attempts to open the card. ETHER_GETADDR
returns the 48-bit Ethernet address associated with the
card.
read() blocks until a packet is received, and then fills
in the input buffer with the packet contents (including
header) and returns the size.
write() does the opposite of read().
close() does pretty much what you would expect.
The add-on contains three entry points: configure(),
driver_open(), and get_pretty_name().
configure() is the main guts of the add-on. It's called by
the Network preferences application, and its job is to put
up a window to ask users how they want the card configured.
driver_open() is called by the net server to open the
driver. It returns a file descriptor that the net server
will invoke ioctl(), read(), write(), and close() on.
get_pretty_name() is called by the Network preference
application to print a more mnemonic name for the driver,
such as "3Com Etherlink II" rather than "3c503".
There are a lot of details that I've left out here, but the
source code from the FTP site should be pretty self-
explanatory.
THE FUTURE
The API for the "real" architecture will be a lot cleaner
than this. Most likely, it will be an object-oriented add-on
that the net server and Network preferences application can
both use. The add-on, in turn, may invoke its own device
driver, but that's an implementation detail that only the
add-on will need to know about. Therefore, some network
drivers can be written completely as user programs. However,
anything that wants to catch interrupts must have a device
driver component.
Stay tuned for further details. In the meantime, check out
ftp://ftp.be.com/pub/samples/drivers/obsolete/netcard_driver.tgz.
News from the Front
By William Adams
The BeOS is full of lots of nifty things that make
programming a breeze. We'd like you to think that the API
presented by the system is much easier to use than a lot of
legacy systems. Well, this is true to a point. And that
point is what distinguishes Be, Inc. from everyone else.
Even if the API isn't easier in some areas, we will make
sure that it is at least well understood so that useful work
can be done as painlessly as possible.
On BeDevTalk and comp.sys.be there has been much discussion
about issues at as low a level as the effects of cache line
contention on multithreaded applications, and as relevant as
optimal graphics blits using the vertical blanking area of a
graphics card.
Well, I've also received requests for some very basic
information on how to get started using the BeOS. This week
I'd like to address this very basic need.
"The Be Book" is very good at explaining the API of the
system as it exists. There are now currently a number of
sample programs that developers can look at to get started.
But there doesn't necessarily exist a straightforward
tutorial on how simple things should actually get done.
So... You will find such a tutorial in:
ftp://ftp.be.com/pub/Samples/January.tgz
It's about time! Well, actually it's not, it's just a simple
calendar program.
In this tutorial you will find things such as:
- How do I create a basic GUI based application?
- How do I draw to the screen?
- How can I display text quickly?
- How do I deal with messages?
- How do I close down the application cleanly?
The sample application is a simple calendar display of the
month of January. The application itself isn't too fancy, as
we don't want its functions to get in the way of a clear
understanding of what's going on. But there's enough
interesting stuff to make it less trivial than the
HelloWorld application.
Most of the information in the tutorial can ultimately be
found in "The Be Book," but this tutorial puts it together
in a succinct way so that you don't have to go read the
whole book to figure things out.
I have a particular agenda for what things will be
introduced in tutorials in the near future, and in what
order. If you have any requests, please feel free to e-mail
me and tell me what you want (wadams@be.com).
FROM YOUR BENCH
Here are some recent ftp.be.com uploads that you might find
interesting and want to employ.
Title: BeInfo
Location: ftp.be.com/pub/contrib/util/BeInfo.tgz
Author: Frederic Tessier (tessier@moebius.qc.ca)
This is a nice system info display that shows you things
like memory used, pages, semaphores, ports, threads, teams.
It also shows machine ID, type of CPU, clock rate, and PCI
bus clock rate. The display of resource information is
updated periodically.
Title: New games including BeTetris, XOIDS
Location: ftp://ftp.be.com/pub/contrib/games
Need I say more? Everybody needs a way to burn all those
extra cycles on their machines. Here are a few games that
will help you do this with ease.
Title: DataTypes
Location: ftp.be.com/pub/contrib/libraries/Datatypes13.tar.gz
Author: Jon Watte (hplus@ix.netcom.com)
This is one of the most powerful concepts that exists on the
BeOS. The problem is simple: How can you translate between
file types without having to write a whole bunch of code?
This library provides a framework that should be used by all
developers interested in integrating foreign data.
Jon Watte, who happens to work for Metrowerks, has developed
and provided this library on his own time to make the BeOS
incrementally better than what's available on other
platforms. You can't go wrong using this free software, or
at least learning from it and trying to implement your own
framework (please don't do this).
Jon is very receptive to suggestions as to how this library
can be improved and has been trying to get it adopted for
the longest time. There is probably no better endorsement
than from the horse's mouth, so I say, "Go use this thing."
It will be used in future tutorials as a matter of course.
Get used to it, feel comfortable with it, make suggestions
as to how it can become better.
THE DEMO SCENE
We are presently in the process of compiling a demo CD,
which will be used by the Be demo team to show off the BeOS
around the world. We have asked that developers wanting
their software to show up on this CD make it available real
soon. The first CD will be pressed within a week (by October
28). Don't panic if you can't make it for this one. There
will be more in the future, because we always want to put
our best foot forward.
If you have any ideas or votes for your favorite demos,
please feel free to drop me e-mail and voice your opinion.
You probably know as well, if not better than we, what
really excites people about the BeOS.
BE DEVELOPER TALK: Masaaki Tani, Toyota Central Research &
Developement Laboratories, Inc.
E-mail: e0926@mosk.tytlabs.co.jp
I'm not a professional programmer. I'm a chemist working on
organic and inorganic hybrid materials for a Japanese
automobile company. Currently, I'm studying the reaction of
silane compounds and the product consequent to such
reactions.
In my laboratory I use a number of different scientific
instruments, which output data in various formats: MS-DOS
text from the X-ray diffract meter, CP-M unknown files from
the Infrared spectrometer, USCD P-sytem(!) files from
TG/DTA. Most modern instruments are computer-controlled, but
some of the older instruments -- the pH meter, thermometer,
and so on -- give me only DC voltage, and I have to store
the data on an analog chart recorder.
Old or new, almost all my instruments have either a serial
port or an analog voltage output. To manage all my
instruments in a uniform way, I need a PC that accepts both
analog data and digital data. This PC is called the BeBox.
It has a nice "GeekPort" and many serial ports (including
the MIDI ports -- it can convert physical properties to
musical data!). I want the BeBox to be the interpreter
between my instruments, and to control the machines that
don't naturally understand digital signals.
I have just received DR8 and am studying the GeekPort. My
plans are only just forming, but here's what I'm thinking:
One of my ideas as a chemist is to make an easy-to-use,
data-collection/analysis/synthesis-control program. As a
geek who likes music, I'd also like to make a MIDI-to-CV
converter application that can play the antique music
synthesizers I have (the one that don't understand MIDI
signals).
Of course, the BeOS isn't perfect; I wish it could handle
the 2-byte character codes we use to represent the Japanese
language. I've heard that the BeOS will support Unicode in
the near future. This is a start -- but in Japan, we use JIS
code on the internet, and S-JIS code on PCs and Macs. If the
BeOS is going to compete with PCs and Macintosh in the
Japanese market, I think it must at least support S-JIS
Kanji code.
BE MARKETING MUTTERINGS: Recruiting
By Alex Osadzinski
Last time I started to describe our channel strategy and
promised future articles to elaborate on it. I haven't
forgotten this promise, but, this time, I wanted to take a
side trip into a topic that's always on our minds at Be:
recruiting.
Startup companies tend to have two distinct recruiting
modes: "Pain relief" and "go for it." You may not be
familiar with these terms (I just made them up), so let me
explain.
The "pain relief" mode of recruiting involves hiring people
into the organization when the workload on people already in
the company has attained maximum tolerable pain level. For
example, if you find yourself waking up in the morning with
your face down on your keyboard, you've probably reached
this level. I should hasten to add that this is a rare
occurrence at Be and, when it does happen, has occasionally
resulted in the production of useful code, C++ being a
sufficiently flexible language that random nocturnal
movements of one's face on the keyboard during REM sleep can
generate compilable code. "Pain relief" recruiting is partly
a way of conserving cash during a company's formative years,
mostly a consequence of the fact that, when you're busy, it
takes longer than it should to hire new people.
The "go for it" mode of recruiting involves eyeballing a
one, two, or three-year business plan, deciding that the
company is destined for continued, solid growth, and hiring
ahead of the curve to ensure that the growth is actually
supportable.
You're probably ahead of me at this point: Be is about to
enter a phase of "go for it" recruiting in the sales,
support, and marketing areas. Next month, we'll be shipping
Developer Release 8 of the BeOS for PowerMac, and "MacTech"
magazine will be bundling a free copy in its January issue
(which will also ship next month, because magazine
publishers have a different calendar from the rest of us).
Early next year, we'll be shipping a release of the BeOS for
PowerMac targeted at a wider audience, not just at
developers. This translates into big volumes, which in turn
translates into the need for excellent order fulfillment,
customer support, and technical support organizations.
Our web site will carry detailed job descriptions of
positions as they come open; check out
http://www.be.com/aboutbe/jobs/index.html if you're
interested. During the next two months, we'll be building
the support organizations designed to carry us through what
promises to be a very interesting 1997.
Apple's Quick Rebound
By Jean-Louis Gassée
The one-two punch of good news from Apple deserves more than
a perfunctory cheer, it signals a new competitive stance and
raises interesting questions for the Mac clone makers,
including Motorola (who makes the PowerPC chips and is to
supply Mac motherboards to cloners). Apple's numbers
surprised most analysts. They expected a loss in the $30-60
million range. Instead, Apple posted a $25 million net
profit. Perhaps more important, Apple's cash flow from
operations amounted to $410 million. The next day, the
company made headlines again by announcing some of the
models Apple's COO had energetically previewed the week
before -- with surprisingly low prices. The new Performa
6400 models are priced several hundred dollars lower than
Wintel clones with comparable processor speeds. The
announcement was so sudden it must have caught some
resellers off guard. This Sunday's "New York Times" offers
an IQ test in the same J&R ad: would you rather buy a 120MHz
7200 with 16 MB RAM, a 1.2 GB drive, and a 4X CD-ROM, or a
new 200 MHz 6200 with 16 MB RAM, a 2.4 GB drive, 8X CD-ROM,
and 28.8 Kbps modem, microphone, and speakers thrown in? We
can expect a little scrambling here and there. The rumor is
Marco Landi won the decision for these aggressive prices at
the last minute. Planned or not, this is exquisite timing,
right at the edge of the Christmas buying season. First,
announce financial results showing Apple coming out of a
tailspin. This tells potential buyers they can trust Apple
to be around for a while. Second, blow away the old Wintel
selling point -- price. This should make for an interesting
quarter. Writing Apple's obituary isn't new: When I first
started at Apple, naysayers were already predicting Apple's
impending demise by reason of lacking CP/M and 8-inch
floppies -- and the company's imminent destruction by
Fortune Systems homing in on Apple with 68000-based Wang
emulation. Not then, not now. And marketing being just as
much about minds as things, there's reason to hope Apple is
beginning to reverse its downward momentum.
A few interesting questions remain, though. FY 96 revenues
fell about 11 percent below the FY 95 $11 billion level, and
this past quarter sales fell 23 percent under last years
comparable level, this at time when the PC industry
continues to experience double-digit growth rates. This
could explain the aggressive pricing for the new models.
Notwithstanding the dangerously naive "Win 95 = Mac
89" bumper stickers, the Macintosh had lost its technical
edge over the Wintel machines and it was more expensive.
This is no longer the case. It will be interesting to watch
if and how new entrants, such as Sony and Toshiba, react and
reprice their new 200 MHz machines and how the established
home Wintel machines get repositioned against an aggressive
160 Mhz Performa at $1,499.
This, in turn, raises another question: What about the
PowerMac clone makers? A few days before the latest
announcement, a new Mac compatible maker appeared on the
scene, APS, well-known in the Mac market for their storage
devices and accessories. ("Maker" is probably a misnomer, as
Motorola will make the motherboard and chassis for APS's
clone.) The prices posted on their web site are not
materially different from comparable Apple machines. Apple
even appears to enjoy an advantage in bundling a modem and
an interesting collection of software. Apple execs have been
heard grumbling that clone makers were "cherry picking,"
that is, going for the juiciest higher-end segments of the
Mac market instead of obediently focusing on the low end,
where Apple couldn't make money. Things will get interesting
and will test Apple's genuine will to create a vibrant
hardware market based on the Macintosh platform. The
conversations among Apple, Motorola, and clone makers are
likely to be animated. Who gets the best price for
processors, and by how much? Apple, the Motorola division
making Mac motherboards, or Power Computing if they buy CPU
chips from IBM? Besides the cost of the microprocessor, who
manufactures the lowest cost motherboard: Apple, Motorola,
Power Computing? We'll be watching to see whether the Mac
clone market becomes freer or if it becomes smothered by the
kind of "managed competition" that brought other plans to a
halt.
|
