Be Newsletters - Volume 2: 1997
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.
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.
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.
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.
| 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 |
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).
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.
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.
| 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 |
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.
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.
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.
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/contrib/gfx/lib/imaging_PR.zip
ftp://ftp.be.com/pub/contrib/gfx/lib/yags_PR.zip
ftp://ftp.be.com/pub/contrib/lib/bebits_PR.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.
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.
