|
Be Newsletter
Issue 87, August 20, 1997
Table of Contents
BE DEMO TOUR: San Diego, CA and Orlando, FL
- Wednesday September 3, 1997
BeOS Demo at the San Diego Macintosh User Group
When:
Meeting starts at 6:30pm
BeOS Demo from 7:30pm to 8:30pm
Where:
Qualcomm Design Center Auditorium
6455 Lusk Blvd.
San Diego, California
You can get more info at:
http://www.sdmug.org/
- Wednesday September 10, 1997
BeOS Demo at the Macintosh User Group of Orlando (MUGOO)
When:
Meeting starts at 7:00pm
Where:
Winter Park Civic Center
1050 W. Morse Avenue
Winter Park, FL 32789
BE ENGINEERING INSIGHTS: Mastering a BFS CD
By Ming Low
With the Preview Release CD out in the hands of developers
and users, BeOS developers can finally ship their software
to paying customers. Several developers have wanted to ship
their products on CD, and in the process came up with
several questions regarding how to make a BeOS (Be File
System, or BFS) CD. To answer some of those questions, I
have put together a short reference to the process we use
here at Be.
There are many ways to accomplish the same results that I
talk about, with different software, hardware, etc. The
examples I give are ones which I know work, and are actually
in use here at Be.
What do I need to make a CD?
From a hardware standpoint, you will minimally need a
Macintosh or a PC with a CD-ROM burner attach to it, a CD
mastering hard disk, and a BeBox or Macintosh running the
BeOS. You can use the machine that is attached to the CD-ROM
burner as the BeOS machine if it is one of the Power Macs
that is supported by the BeOS.
There are several CD-ROM mastering packages available on the
market. At the present time, because none of the packages
understand the BFS format, the key feature that you need to
master a BeOS CD is software that can support making a
direct copy of a hard drive. We need this feature because we
want an exact copy of our master hard disk, without the
mastering software trying to interpret the (unknown) BeOS
format.
Another feature that is good to have is functionality that
allows you to specify the end point of the copy in either
blocks or megabytes. This will give you more flexibility in
the size of the hard drive you can use to master the CD. You
can choose to use any large hard drive (although there are
some tricky calculations involved).
At Be, we use the Astarte Toast CD-ROM Pro 3 software for
the Macintosh. Astarte Toast software has both of these
features. Several companies make good CD-ROM mastering
hardware. The one we use at Be is the Yamaha CDR-100. It is
a 4x reader and writer, and is supported by the Astarte
Toast software.
Our primary CD mastering station is a PowerCenter 132 with a
Yamaha CDR-100 and some old open-faced HD-20 cases used
primarily for ease in attaching other hard disks to the
system for toasting.
Multisession versus multi-partition CDs
If you need to have a CD with more than one partition on it,
you have two choices. You can create a CD with multiple
partitions or you can create a multisession CD. Which is
better? It all depends on what you want to do.
The multisession CD is easier to create and you have more
flexibility on each of the sessions. You also don't have to
record all of the sessions at the same time.
But there are several drawbacks. One is that you won't be
able to simply make a copy of the CD on your personal
mastering system. To make a second CD you will have to go
through the entire process of burning each of the sessions
individually. But possibly the biggest problem with
multisession CDs is that not all of the duplicating houses
know how to duplicate a Mac OS/BeOS multisession CD. We had
many problems with different vendors in the process of
duplicating our BeOS DR8 CDs.
Another problem we noticed with multisession CDs is that if
the sessions are not mastered in the correct order, they may
not show up on some Power Macs. The situation where we know
this will happen is if you burn a Mac OS/BeOS multisession
CD and put the BeOS session first and the Mac OS session
second. The Mac OS session will not show up on Power
Computing systems (and possibly others), because the
standard CD-ROM Toolkit that is shipped with all Power
Computing machines by default mounts only the first session
of a multisession CD-ROM.
The CD-ROM Toolkit tries to mount the BeOS session and
fails, but it does not then look for any other sessions on
the CD. Since this is the default behavior of the CD-ROM
Toolkit software, some Macintosh users will never know that
there is a Mac OS session on the CD.
A multiple partition CD is a bit more work to create but you
will not have the problems you can have with a multisession
CD. Some of the extra work is in creating the partitions. It
is even more work if you want a Mac OS partition for one
partition and a BeOS partition for another. The extra work
involved in creating the multiple partitions is done on the
Mac with a Mac hard disk partitioning utility. The one we
use here at Be is the HDT Primer, part of FWB's Hard Disk
Toolkit, which ships with Power Computing systems.
BFS CDs versus other CD formats
If you have mastered a Macintosh, PC, or ISO9660 CD-ROM,
then making a BeOS CD will be very similar. Since there is
currently no mastering software that runs natively on the
BeOS or understands the BFS format, there is no way to take
advantage of features present in the mastering software
which assume the CD is destined for a Mac or PC. These
features let you do some things very useful to the mastering
process, such as not copying the empty area of the master
hard drive onto the CD, or creating a new CD volume on the
fly without using a master hard disk.
To get around the lack of these features, we need to use a
physical hard disk that we can format on the BeOS, and then
build the master of the CD on the hard drive under BeOS (and
the Mac OS, if there will be a Mac OS partition). Then,
since the software does not understand the BFS format, to
burn the CD we have to do a blind SCSI volume copy of the
hard disk to the CD.
In order to do a blind copy, though, we need a hard disk
that is big enough to hold all of our data but is smaller
than the size of a CD (which is 650 megabytes); otherwise
the copy will overrun the end of the CD. Finding a disk that
is smaller than 650 megabytes today can be a challenge! But
if all of your data is less than 100 megabytes then you can
use a Zip disk as the mastering disk.
But the most important thing to know is that when you
initialize the master hard disk, you must set the File
System Block Size to 2048 or 4096 bytes. This is easy to
forget because when you initialize a Be File System, the
default is 1024 bytes.
This has bitten both Robert Polic, the author of DriveSetup,
and I several times. The reason is that if you forget to set
the Block Size to 2048, you will not get any warning (1024
byte blocks are fine for normal BeOS volumes) and everything
will work normally on the master hard disk.
But, once you master the CD, you will find that the CD will
not mount under the BeOS. The reason is that the Be File
System will not recognize block sizes smaller than the
device's minimum block size, which on a CD-ROM is 2048
bytes.
There is nothing you can do at that point, and the hours
spent copying, laying out, and mimesetting the disk are all
for naught. The only thing to do is to take a deep breath
and start all over again, *this time* initializing the disk
with the block size set to 2048...
The following are two examples of the process to follow to
master a BeOS CD. It is a very high level guide for
mastering the CD, and many of the details are left out. If
you need detailed instructions, let me know.
The hardware and software requirements are based on our
setup here at Be. You can replace them with the hardware and
software available at your site.
Sample CD 1:
Requirements: CD with 100 megabyte Mac OS and
400 megabyte BeOS partitions
Hardware: Power Computing PowerCenter 132, BeBox,
Yamaha CDR-100, 500 megabyte hard drive
Software: Astarte CD-ROM Pro 3.0,
FWB Hard Disk Tookit PE v2.0.5,
BeOS DriveSetup
1. On the Mac OS, initialize the 500 megabyte hard drive
and create partitions of 100 megabytes and 400 megabytes,
using the FWB Hard Disk Toolkit software on the
PowerCenter. Copy the data for the Mac OS HFS partition
onto the 100 megabyte partition (a Finder copy is fine).
2. Connect the newly partitioned hard drive to the BeBox
(or any BeOS system). Use DriveSetup on the BeOS to
initialize the 400 megabyte partition to BFS format with
a 2048 byte File System Block Size. Copy the data for the
BeOS onto the BFS partition.
3. Connect the hard drive back to the Mac OS system. Use
the Astarte CD-ROM Pro software and use the "SCSI Copy"
command to copy the hard drive onto your CD.
Sample CD 2:
Requirements: CD with 50 megabyte BeOS partition
Hardware: Power Computing PowerCenter 132, BeBox,
Yamaha CDR-100, Iomega Zip drive
Software: Astarte CD-ROM Pro 3.0, BeOS DriveSetup
1. On the BeBox, use DriveSetup to initialize the Zip
disk to BFS format with a 2048 byte File System Block
Size. Copy the data for the BeOS partition to the Zip
disk.
2. Connect the Zip drive to the Mac OS. Use the Astarte
CD-ROM Pro software and use the "SCSI Copy" command to
copy the Zip disk onto your CD. To be safe I would set
the CD writer speed to 2x instead of 4x.
BE ENGINEERING INSIGHTS: "Thank you, thank you very much" -- Elvis Presley
By Scott Paterson
How many BeOS demos have you attended? I know I've seen a
few. BeOS demo tours serve many purposes. There's the
obvious: Get end-users excited about the performance that's
hiding inside their Power Macintosh computers, such that
they wish to run the BeOS and purchase third party software
for it. And the not so obvious: Get those software
developers that are hiding in the crowd excited about the
new development possibilities that such a powerful operating
system allows, such that they write applications for the
BeOS.
We spend long hours preparing demos, especially those large
demo sequences we go through at MacWorld. The point is, a
great demo can serve you well. Since the BeOS is moving into
a phase in which we're starting to see some really great
commercial applications being delivered to market, I thought
I'd write an article that may help your demo (of your
application, not just the BeOS) serve you well.
Over the past year I've been compiling mental "keep in mind"
notes about demos. I thought I'd share these with our
developers, many of whom are now entering that phase where
they need to start showing off their software. I'll start
with the obvious and work towards the weird.
- Know your material.
Probably good advice for anything in life, especially when
you are giving a presentation of any kind. If you know your
material inside and out, you'll have more fun telling
someone else about it.
- Be nervous.
Anybody doing public speaking who isn't nervous is either
dead or speaking to an empty auditorium. Trust me, you're
going to be nervous. I've done hundreds of demos and I still
get nervous. This is a classic example of BO. No, not Body
Odor, but Burden and Opportunity. If you've handled point #1
appropriately, then this is your Opportunity to show off
what you know. Your nervousness is just you getting pumped
to deliver. Don't sweat it because once you get rolling, the
butterflies will have migrated elsewhere.
- Pre-stage and bring your own demo equipment.
Give your demo on a known system that you've set up in
advance. Try not to bring software with you to install on
someone else's system. If you really have to do this, set up
the night before and expect to find something that you've
never seen before ("Wow, you've got a hardware interface
controlling the entire building's security system here. Mind
if I disconnect it for awhile?).
- Hard drives die.
Bring an extra hard drive, hopefully identical to the one in
the machine already. What can break, will break, although
there are limits to just how much spare equipment you can
bring. Or live dangerously (I've seen good body impressions
of Pulse and the 3D Book demos).
- Know your software's strengths and show them off.
Software is always changing. Features are added, speed
optimized, interfaces refined. Know your current strengths
and show them off. In fact, I've found that giving concrete
examples of why a particular feature might be useful helps
the crowd put concepts in context.
Two simple examples from the BeOS demo. One, when I show
FontDemo and the real-time scaling of fonts, I use
Photoshop's dialog boxes interface as a contrasted example
("Instead of going through dialog boxes to change my font
attributes, I can do it in my document in real-time).
Another example is when I show off Workspaces. By setting
one workspace in millions of colors and another in 256, I
can show how easy it is to preview a graphic in different
color depths by dragging it from one workspace to another.
- Know the dark side of your software (and don't trespass).
For software to evolve, you have to try new things. Often
this leads to unstable, er, I mean, revolutionary features.
If something doesn't always work right, then stay away from
it. Once you've got a demo put together, run through it as
many times as you can, assuring yourself that everything
works every time.
- Do not hold a party when something goes wrong.
Yes, it'll happen someday and you should be prepared by not
being surprised. Okay, your software has crashed for one
reason or another. Do not call undue attention to the
problem. You are not making the first uncrashable
application in the universe and nobody is expecting this of
you. Don't go into a long speech theorizing on possible
reasons for the crash. Hopefully, you can dismiss the crash
dialog box, restart your application, and continue from
where you left off with a simple, "Hmmm... let's try that
again." At the end of the demo, don't remind everyone by
apologizing for the crash, just thank the crowd for spending
their time with you.
- Demo in the visible portions of your screen.
Position your windows in the upper portion of your screen
area so that everyone can see. Moving windows around in the
BeOS is snappy and impressive, so although you were brought
up not to fidget, fidgeting with BeOS windows is a good
thing. This also helps to call attention to the window with
which you are working.
- Audio is king.
You might think that what you are showing on the screen is
most important, but actually audio rules a demo. If what you
are showing calls for audio, invest in a decent sound
system. Robust sound lends weight to a good demo.
- Be humble.
Your application runs on an "alternative" operating system.
You will get the proud, the few, the ones that *need* you to
know that they can do everything you just did on their
<insert OS/ hardware combo here>. Be humble, nod your head,
and say, "That's cool. Do you have any questions I can
answer?"
You're probably a small developer and your attitude should
be, "I'm just trying to produce powerful new software for
you." Currently, Be and its developers are the underdogs.
Psychologically speaking, there's something about rooting
for an underdog, especially when there's something about the
underdog that's really good for which to root. Who knows,
someday our position in the world will change and I'll write
up a new set of demo guidelines.
- Answer questions to the best of your ability.
When you're up in front of a crowd, your tendency is to want
to answer every single question fully. Sometimes that's just
not possible, so don't be afraid to invite someone to come
up afterwards to exchange business cards so you can do some
homework and make sure they get a correct answer. This also
works for someone who is either asking an impossible to
answer question or who isn't asking a question at all, but
rather is using question time to make some kind of statement
(read the first part of #10 again).
- Make a sacrifice to the demo gods.
I believe in gods, specifically, The Demo Gods. Before any
demo I give, I *always* make a sacrifice to them. This
sacrifice is clean, easy, and most importantly, blood free.
Simply reboot the system.
Walking up to a computer that is in an unknown state is
tempting The Demo Gods to strike you down. It's also just
common sense. Who knows, perhaps someone was trying to test
their software in low memory environments and had run a
utility that chewed up all but 6MB of RAM. Giving a demo in
this environment would be unnecessarily challenging.
- Have fun.
Giving demos of powerful software is fun and gratifying.
Don't forget to enjoy yourself.
David Coursey also wrote an article awhile back on "How to
give a Great Demo." It's a little more general than my
hints, but I found it good reading. You can find it a copy
on the web:
http://www.coursey.com/html/great_demos.html
Finally, here is a list of little items I've come across in
my travels.
- Snow is your friend -- as long as you make time for it.
Although equipment cases don't roll well in it...
- You don't need to honk your horn in New York City. Just
drive aggressively and leave a little of your civility
with them.
- Newark, Delaware and Newark, New Jersey are different
places.
- FedEx delivers equipment boxes with computers inside.
Airlines deliver equipment boxes with broken computers
inside.
- The wind is always in your face, which means you never
drive against commute traffic.
- Sending hardware to Canada is extremely painful. Start
working on this weeks ahead of time.
- Getting hardware back from Canada is extremely painful,
don't plan on using your equipment right away.
- *Always* bring business cards.
News from the Front
By William Adams
Ahhh... At last. It feels good to be using a nice new API
long term. Do you remember the time period that followed the
release of DR8? A very long period of uninterrupted
development. Lots of apps created. Just take a look at the
old archives and you'll find a plethora of applications that
developers wrote in those glorious times. Thankfully, no one
is standing still, the same thing is starting to happen for
the Preview Release. We have a stable API, and the apps are
just gushing forth. I don't want to miss out on all the fun,
so I thought I'd rev a couple of my favorites of the past.
ftp://ftp.be.com/pub/samples/interface_kit/imaging.zip
ftp://ftp.be.com/pub/samples/interface_kit/obsolete/yags.zip
ftp://ftp.be.com/pub/samples/support_kit/obsolete/bebits.zip
For those of you who have seen them before, just say ho hum
and move on, except you'll see some Preview specifics. For
those of you who haven't seen these before, they are:
- imaging_PR.zip -- an example of how to do some direct
BBitmap manipulation. In this specific case the sample does
some bilinear scaling on a bitmap. It also shows it side by
side with what you get by default from the
app_server. This
clearly shows the tradeoffs between speed and a different
quality of scaling.
- yags_PR.zip -- way back when, I had a dream that I would some
day be able to create a graphics system for my daughter.
Yasmin Adams's Graphics System is it. There are a whole
bunch of 2D and a little bit of 3D primitives in this
library. The nifty thing about it is that it will draw into
anything that looks like a chunk of memory. There is also a
Game Kit specific version that will take advantage of
hardware acceleration if it can. This is a nice library to
use if you are trying to do some simple drawing into a chunk
of memory like a
BBitmap, the screen, or just a icon buffer.
And, you learn a little bit more about using BBitmaps,
BScreen, and BWindowScreen.
- bebits_PR.zip -- How many times have you been sitting up late
night wishing you had a nice simple scheduler that would
launch events on time. Or allow you to write code like this:
snooze (seconds(3));
Or create a simple queue or list, or do btree sorts, without
having to learn all of the STL library. Well, this is the
place. A set of useful C++ tools that take care of quite a
few mundane tasks such as these. bebits was originally
called the esoteric library. Just a handful of what I have
found to be useful little tidbits of code that have been
tailored for use on the BeOS. You could probably spend a
little bit of time creating them yourself, and they probably
don't do exactly what you want, but they do save you time if
they come close, and the source is here, so you can tailor
them to your liking.
So what is it to be a developer support type person? Well,
you support developers any way you can. Providing code,
advice, tutorials, marriage counseling... The list can
become fairly extensive. But first and foremost, you have to
love doing what you're doing. We try to spread our
infectious enthusiasm any way we can. These code samples are
my humble offerings.
As you'll see soon on our web site, we have been busy
setting up a new tutorials area. The idea is to make it easy
for newcomers and oldtimers alike to find that special
little code sample that does just what they're looking for.
If you've ever wanted to know how to do off-screen drawing,
you should be able to find the answer fairly easily with our
nice little search engine-based tutorial pages.
What else can we possibly do? You developers have been
giving us good feedback, and we're acting on it. You keep
generating those apps, and we'll keep cheering and bringing
in the water. Happy coding at the Front.
Tickets and a Tin Cup
By Jean-Louis Gassée
On the road again. Outside Heathrow we were asked what
band we're in. Did I miss something? The rock and roll world
may have gone conservative while I wasn't looking, but I would
never have thought that Alex Osadzinski, Wes Saia, Jean Calmon,
Bill Bondie (our Parabooted ex-Navy Seal investment banker),
and yours truly could be mistaken for Mick, Keith, and Bill.
It must be the airline-proof anvil cases -- the type that roadies
use to lug the band's gear. We carry around two of them, one
contains a dual-processor Umax and the other a generic Intel
clone. These cases have already raised a lot of money
-- for airlines -- in excess baggage charges.
Thankfully, not everyone is so confused. I landed in London
early Monday morning and, after suiting up in
a double-breasted chameleon skin, I climbed into one of the
cherished English taxis. "King William Street, please, I don't
remember the number, but I'll find it." "Going to Mercury
Assets Management, guv?" The cabbie is a pin-stripe reader.
After the Boston Be Developer Conference and the Masters
Awards, Alex has updated the demo with new software. The Real-Time
WYSIWYG examples and the 3-D Kit kettle waltzing with the
narcissistic cow help us illustrate the kind of content creation
and editing heretofore impossible at this price level. Or, if
you will, impossible with this very hardware running older general
-purpose operating systems. Our hosts ask hard questions: How could
Microsoft kill us? why focus exclusively on electronic marketing and
delivery of software? why do we think that the tractor apps will
come from new players?
Back at the hotel, the bell captain -- or "porter" in the local
dialect -- isn't confused either: He points at the Be logo on the
cases and asks Alex for his e-mail address. He wants to discuss
Cyrix processors.
From London, we flew to Oslo, where I'm writing this. Two meetings
with high-tech investors and we'll be off to Paris and Geneva
for more presentations. Walking (a rare pleasure on this tour) from
one meeting to the next through the old town, we see students holding
a textbook fair -- and cellular telephones.
We're in the high-tech neighborhood of Europe, the land of
Linux, Ericsson and Nokia. We're here to raise "connected" money,
to attract investors who will link us to the wealth of local software
talent. In turn, the BeOS connects local developers to the world
market through its friction-free, Web-based distribution model.
All the while, we're also connected to the home base...
John Dvorak reports
that Bill Campbell is Apple's next CEO. Bill's not blond,
Japanese or bisexual, features that a Silicon Valley wag claimed
were required to head Apple into the twenty-first century. But
Bill's an excellent leader, as he demonstrated at Intuit, plus
he's a friend of Steve, he's worked at Apple before (as VP of US
Sales and Marketing), he ran Claris, and, in ealier but not
forgotten years, coached football at Columbia. Overqualified
and a great guy to boot. Let's hope.
John Swartz, from the SFO Chronicle, calls; he heard Apple
wrote a letter to Mac clone makers clarifying the company's
position on CHRP. Allegedly, Apple will not support CHRP, or
will enforce restrictions amounting to the same. There's much
confusion surrounding the Mac cloning issue. For Apple, cloning
is a prisoner's dilemma: dead if you do, dead if you don't. The
debate is now 11 years old and still raging. It's the reason why
I wrote the "I love Apple so much I want two of them" column a few
weeks ago: I still believe that cleaving Apple's software from
its hardware is the best way to jump out of the nefarious dilemma.
I suggested that Guerrino De Luca, a Bill Campbell successor at
Claris, could run the software operation, while Steve
Khang, the assertive head of Power Computing, could do predictable
wonders for the hardware business. Taking the rumors at face value
would mean that Apple wants to return to its roots and stay in control
of both hardware and software. As indicated last week, I'll wait
for these issues to settle a little bit more before I attempt
a fuller dissection.
Got to catch a plane to the old country.
|
