Be Developers' Conference Approaching the BeOS Andrew Kimpton

Mr. Kimpton: It's actually pretty good to see this number of you in the room. I had thought that after this morning's drop dead demos and the fact that you all had or should have in your hands a copy of the BeOS, you're all going to go home and start going yeah, I can do that. Maybe a few of you said yeah, I can do that, but I need to know how I can do that so you came here so you can work it out.

My name's Andrew Kimpton. I'm one of the evangelists at Be. Yes, that means I'm a marketing dweeb. Oh, dear. More importantly, I'm somebody that many of you developers will see quite a bit more of as I try to encourage you with all of the encouragement that you need to write applications to the BeOS.

I'm joined up here this afternoon by Doug Wright, one of our developer tech support engineers, and between us for the next two hours we have two presentations to give. We'll start off with sort of a brief overview of the features of the BeOS, which I'll give, and then in the second hour we'll look at how do you write a real app and what's a real app and how does it work.

I'll get us going. If you have questions sort of as we progress, then wave your arm at me, throw things at me, do anything you'd like to attract my attention.

In addition to myself, there is a rogues gallery of individuals at the back of the room of Be engineering staff and if it gets to be too much I'm just going to go home and so if it gets really nasty, then I'll just let them answer the questions.

So as you probably observed from this morning's demonstrations, we have real true multitasking. There is none of this yes, the applications get a chance to switch between each other. If you called WaitGetNextEvent(), so forth, no, no, doesn't work that way. We have real multitasking.

The kernel decides who has the CPU, or CPUs because we have multiples, and at which time to switch applications between them. There are a number of benefits that come from that and there are some things that you need to do to take really good advantage of it.

As an operating system, we speak a lot about the use of threads and you'll hear this come up time and time again during this afternoon and tomorrow's presentations, and you'll see it to great effect in all of the applications and demonstrations.

Multithreading is a real key mechanism of being able to take advantage of good multitasking and in particular multiple CPUs. It's not a particularly new concept and, in fact, none of the things up here are really like we haven't reinvented a whole paradigm and language and so forth.

These are just good, fundamental concepts that are not straight out of the lab or something. They're well developed, well engineered and familiar to many people, but we just now started to put them in somewhat of a commodity form where developers can make the most use of them. Multithreading is a mechanism whereby you have a thread of execution where you have a task to perform.

Now, if you have multiple tasks to perform or you need that one task performed multiple times, then you simply create multiple threads. The operating system and the BeOS will then determine which thread gets which processor at which time for you automatically and seamlessly and the Mandelbrot demonstration is a good example of that in action and we'll see that actually make a return to the stage later on this afternoon.

Because we have multiple threads and the ability to run threads of execution in parallel comes from having multiple CPUs. The machines you saw this morning have two CPUs in them, as do our demonstration machines up here. There's no particular magic reason about two or four or eight or sixteen or whatever and we use symmetric multiprocessing so each machine has common access to the memory and the operating system then portions the threads and work between them.

Right now in dual CPU Pentium IIs multiprocessors is a common feature and becoming more and more common, thanks to the good efforts of people at Intel. Four processors for Pentium pros and original Pentium processors are also available. One of the earlier marketing mottos of Be was one processor per person was not enough and that still stands today, and you -- you can see the real benefits from having multiple CPUs in your -- in your applications and in the demos this morning.

One of the technologies that's come over and come forward in the last few years, to everybody's benefit really, is the use of object orientation and design. The concept that a window is an object; it encapsulates both function and data. It encapsulates the function of how you make a window or how the window behaves and it encapsulates the data of what a window color is or what size the window is or its location on the screen.

So it's nothing particularly new. Development environments like MacApp or the Microsoft Foundation Class, which is using C++, PowerPlant and so forth have had these features.

What we've done is extend them in all directions. Things like MacApp, MSC, PowerPlant, when you really sort of got down to the bottom of it or when you needed to do something just a little bit different or little bit odd, you found that you actually just dropped into real C and it was all C at the end. Yes, there was some convenience of using object orientation, but it wasn't really fundamental to the way that the whole thing worked.

In the case of the BeOS, objects are everything. The BWindow object is a real object. Everybody thinks of it as an object. It's not an object that at some point in your life it becomes, you know, create a new window as a function core. It really is an object.

Even the things like the interfaces for Ethernet devices in the BeOS, are objects. There is an Ethernet object with our read and write as functions that that object possesses and data that it manipulates.

All of these things conspire together to our great benefit in order to be able to allow us to have really good performance for the real-time multimedia demonstrations you saw this morning. And it's no one single thing. It's not the support for SMP that does that per se. It's a combination of all of these items. Certainly having more processors is good, but it's not good if you don't use them in the right manner. And perhaps you can even begin to see that today as you get to see some Windows applications or Macintosh applications, where if you have a multiple CPU machine they do work a little faster, but it is only through the good graces of the application you're running that you really get that.

In the BeOS multiple CPUs are just a given. They just work to your advantage at all times. You don't really have to think too much about it, and we'll see that in a little while.

And perhaps one of the best things as a developer, and as much as I might stand here as an evangelist and wear a marketing label and hat, I write code and it's one of the things that I hope makes it easier to do my job and makes it easier to understand what all of you are going through, is that writing and designing code for the BeOS is very simple.

It seems to me as I've gone through, you know, industry and developing software that the -- the hassle of creating software, and it's become a hassle, of creating applications has just grown and grown and a lot of the fun has gone out of it. You have one way of doing things and then you find under certain circumstances it goes in a different direction or something else happens.

The APIs, the objects and the mechanisms and design of the BeOS means that it's the same and conceptually similar across all of the various aspects of -- of windowing or doing menus or doing multiprocessor work or communicating between applications. It all works and works the same, which makes it actually a lot more fun.

And in some respects, as a personal level, we will have succeeded if we simply put a lot of the fun back into engineering for the future. If we have an operating system where writing applications is fun again, then we all benefit in having some good applications and applications will get better, there will be more people doing them because they're more fun.

For developing for the BeOS is one of relying on a very approachable framework. The object-based frameworks are very familiar to many of you. We have an object called BWindow, we have an object called BMenu, we have an object called BApplication and those are all familiar concepts for things like MSC and PowerPlant and so forth. The name might be different. It might be BApplication in one place or WApplication in another, but the concept of an application as an object is familiar to most people.

Primarily this means that we have -- C++ is our language of choice for doing development, and Metrowerks does provide not only the C, C++ tools, but also the Java tools, but the language of choice for nearly all of our work is C++. Because of our good arrangements with Metrowerks and the common interface and environment that they present, the BeIDE and the integrated development environment is the same or very similar to most platforms where Metrowerks provides it, on the Macintosh or Windows or so forth.

So we end up with a very good set of tools with some very good history and knowledge behind them, which gives some great performance in terms of the actual code that ends up being generated and because things are fairly familiar. It's fairly quick and easy to write software. It doesn't take too much of a real sort of brain fade or something to really work your mind to dealing with developing for the BeOS.

And we'll go through the complete Mandelbrot demonstration in the next hour and you can sort of see how quick and easy it is to build up an application, make it work.

So here's a brief look. I have to sort of wave my arms around a little at this point at the arrangement of the BeOS architecture. Fundamental to any system, of course, is the hardware at the bottom of it and be that single CPU, multiple CPU, be it Power PC or Intel architecture machines.

In order to take advantage of that hardware you need to write software and BeOS is really just a convenience for you all. There's nothing stopping you going writing an application completely from the ground up, without any need for an operating system whatsoever, but it's a lot easier if you use one. So we have a number of layers that progress forward until we get to the application system, primarily the microkernel that does much of the marshalling of basic functionality and so forth, this is the ability to manipulate an area of memory, provide for tasks on multiple processors, prevent one task from interacting with another and so forth.

Laying on top of that are the real pieces of real application functionality, the things that applications demand. This is things like the audio server to handle drawing to the -- to handle giving streams of audio out to a sound card. Things like the network server to handle communication through TCP/IP to other entities on your local network. And some fundamental things like an application server and storage server. The storage server looks after the interfaces with regards to file systems.

Now, it doesn't necessarily itself implement a file system, but it provides a framework whereby data can be retrieved from some storage device, be it a disk or CD-Rom or even memory, and then handed off to some layer or application even, for manipulation and presentation as a file system, the concept of files and directories and so forth.

The application server handles all of the necessities of actually doing the presentation of your application with Windows, its menus and so forth. Now, all of these in turn need to communicate with the microkernel in order to make certain that stuff gets up on to the screen.

Now, in order for your application to have a very seamless and easy and common communication mechanism with each of these entities, each of these server entities, we have what we call a software kit. You had mentioned this morning of a media kit being one of those and there are a number of these.

The support kit that provides general stuff and useful sort of widget type routines, the application kit, primarily which provides for the windowing and menus, views, scroll bars and so forth, these are the real software APIs that you will interface with and deal with on a day-by-day basis. This is where the object paradigm comes to the full, where we have a BWindow object, BApplication object, and they're all derived from concepts within the software kit.

Finally, in the green box up at the top is the area where you, the application developers, have all the hard work to do and all the value to add.

Now, you'll notice a yellow line that sort of neatly divides us here as we sort of run across. BeOS has the principles of a client server type architecture. The software kit provides for client communication to these servers, which provide the services.

This is not an unusual concept; in fact, Windows NT tries to do something similar. Windows NT concept to a client server has been sort of a little marketized from time to time, when people think of networks and that type of thing. That's not quite what we're talking about here.

It's a neat, clean division between different sections of functionality that need to be provided and the yellow line sort of serves as a boundary for that, which you yourselves do not necessarily need to be too concerned about, because you are way up here in the green box.

A key thing for any operating system is its file system and the BeOS has probably one of the -- Dominic's waving his hand back there, going yeah, that's mine.

The BeOS file system is a very important component of the operating system. Sure, file system's is just where you keep your data, but it's how you keep your data and where you keep your data and the facilities that the file system provides you for organizing your data that become most important.

A key feature in the BeOS file system is the concept of journals. This means that quite simply if I walk up to this machine, turn it off and turn it back on again, we don't have to wait 25 minutes until it works out what it was it was trying to do to the file system when I turned it off. Journaling allows it to keep an ongoing log and record of the transaction to the filing system, write this block, move this bit of an index over here and so forth, continually written out as a journal. And as items are performed and completed, the journal entries are removed.

That means if we just reboot, all we have to do -- or just have a power failure, all we have to do is replay through the journal and make sure that everything is consistent. And so that's one of the reasons why BeOS reboots that quickly.

We're fortunate now that we don't have to worry about that in our demonstrations anymore. Alex doesn't wait to sacrifice to the Demo Gods anymore. Trust me, play with the machines next door. It reboots very, very quickly.

64-bitness or, you know, images files. This is what this is all about. 64-bits expressed as a decimal number is just huge. Who cares how big it is. It's big. One of the things why this figures to be really important though is, you know what, video is big. The amount of data that moves through if you don't compress it and just want to deal with raw video in terms of flowing through a machine or needing to store it on the disks is a lot. Quite fortunately, not quite as much as the 64-bit number in terms of the amount of bytes that you need.

One of the things that the 64-bit file gives us is the ability to have immense disks and immense sized files, easily and without any real thought or overhead. That becomes very important when you're dealing with video, less so with audio and even less so perhaps with straight still images and stuff, but for video it's a key thing.

One of the great little features, and it's a little feature, but it becomes more and more significant as time goes on, of the Be file system is that you can add attributes to a file.

An attribute is a very simple concept, it's a name and a value. For example, if any of you have played with the operating system, there's a very simple application called People, which allows you to create like a little database of contact names. Their name, their address, their phone number and so forth.

If you actually look in detail at how that data is stored, it's not actually stored as data within the file, but rather it's a 0 byte length file with a number of attributes. Attributes are a great way of creating a very simple and easy-to-use flat file database, without any real work. If you just need to have something that's quite extensible, flexible and easy to use, then attributes is a great way to do that.

Some attributes are even more important to us, because they provide things like an icon or things like last modified time, creative dates and so forth. Some attributes are sort of fairly familiar to people, but the attribute mechanism on the file system can be extended to just strings and time and other quantities and stuff.

Of course, the file system is multithreaded, so there is not any real restrictions of performance hits for dealing with files, and the file system deals with the multiple CPUs and provides for multiple threads of execution. When it comes to moving a file from one disk to another or reading images sections of a file while you're writing other sections of the file, that sort of work is handled by using threads and by using multiple CPUs, if you have it. Threading is important to everybody. It's certainly important to us, so it's in the file system.

And finally, with the file system is this is not everything. There's more that can be done because the file system is very extensible. The attributes I described at the top of the screen here, the first three items, 64-bit and so forth, those are the attributes of the native BeOS files, but the architecture is fully accessible. There's nothing stopping you from going out and writing your own file system should you need it or writing a plug-in or add-on if you like for some other format file system.

Now, we in the past have provided and still provide some good examples of that. The hierarchical file system that's native on the Macintosh is supported in the BeOS by using an add-on.

There's at least one developer who has already created a DOS file system add-on so that if you are using DOS-based disks or FAT format disks you can read those from the BeOS. And another developer has done something which doesn't really rely on disks so much as using a network file system and providing that system, whereby you can have an NFS client and present those files to the BeOS.

And so it's very extensible, allows you to add support for new or odd or different or other architectures, file systems.

Every time and continually throughout the next few days you're going to hear threading. It's just everywhere. One of the great things with threading in the BeOS is it's very easy to implement. It really only takes a couple of -- couple of function calls to create a thread in your application. And there are some sort of utility classes, if you wish, which make that even easier, so that you can create an object that is a thread and that the -- the A routine within that object or function within that object will run as a thread of its own execution.

And by providing these sorts of things you get all of the benefits of the multiple processors in your machine, because threads will run concurrently and together, but they are actually a good idea, even if you only have one CPU. They provide for a very neat division of labor between different parts of your program and it makes for your program to be very scalable and, okay, maybe you don't ever expect anybody to run it on multiple CPUs, but there are people out there with that hardware and they're going to want to run your software and this does provide for a little cash for you as developers. You do need to think about what this really means.

In a lot of cases in a multiple tasking or multiple threading environment people create from multiple threads, but they don't ever actually run together. They make it the illusion of having two threads running concurrently and running, doing things at the same time, but the actual reality is that the processor, really being only one processor, switches very quickly from one to the other, so the chances of there being a collision between those two threads is zero. And that can lead to some port coding or sort of sloppy coding and poor thought.

One of the things that the BeOS is for the multiprocessors and the rapid drops in prices of multiple CPU hardware is that more people have more CPUs on their desks. If any of you are familiar with what we refer to as the Ming specials, this is a selection of machines put together by one of our engineers, available from the local vendor here in California. And I recently purchased from them a dual CPU Pentium II machine for less than two and a half thousand dollars.

That's a very unheard of configuration only a little while ago and that's going to become more and more common for more people and that means there really are going to be circumstances where you will have two threads of execution running concurrently. They will be able to provide, so you do need to provide a little more thought in your design and how your application is arranged.

Buzzwords. I don't know if I've got enough in so far, maybe I missed a couple. These ones are, maybe they're a bit passe. Yes, protected memory. Yes, of course we do that. Who wouldn't?

A Speaker: Y2K? (Year 2000)

Mr. Kimpton: That's a good question. Dominic, Y2K on the date returns?

Mr Giampaolo: It works finr with the R3 reelease

Mr. Kimpton: I missed one. We should update the slides. I mean who wouldn't do protected memory? Actually, seems like quite a few people. Whoops. Just can't count some people.

Internet ready. Yeah, I mean anybody's got an IP stack Internet ready, so that's easy. Here's a better thought, though. MIME types are very, very important to us. Now, a lot of people are familiar now with the concept of a MIME type, a description of a file as being, you know, video MPEG compressed and so forth. Supertypes and subtypes.

You'll see in some of the other sessions, particularly when it comes to dealing with the Tracker, which provides for our user interface and for navigating around files, that MIME types are very, very important. They're used to create distinction between one application and another and they're used to create distinction between one file type and another.

And if you're familiar with the DOS environment, where essentially that information comes from a three-letter suffix, which is weak to say the least, in terms of having the number of sort of descriptions for file type.

The Mac, I have to say, was a little better, you know, had four letters, the user didn't have to worry about them so much. Well, we have complete strings and you can write essays in MIME types if you want to and the user still doesn't have to worry about them. So MIME types sort of go everywhere throughout that.

If you have a chance, you should attend some of the sessions that relate to Tracker. If you can't make those, the What's New With R3 will give you a few examples of where MIME types are going and how they're becoming more and more and more important.

Oh, yeah. The real reason you're here. You all got a copy of R3 this morning. Actually, some of you got a copy of R3 a few weeks ago, because these fine ladies and gentlemen write code so fast that we meet every deadline.

The real reason you're here is we have something new and exciting and as I said, in talking about simplicity, to some extent we will have succeeded if we simply put some of the fun back in. Although it would pain people like Jean-Louis and some of our other investors to hear me say that whether we make money or not is not a personal problem... Forget that. It's a personal problem, we need to make money. Putting the fun back is a good thing and having more engineers and more people write software is a good thing.

Current platforms, what's out there, they're beginning to show a little of their age and in particular as people try to push them into new corners and into new areas of applications they really begin to show their age and show how they're not quite really up to the tasks being demanded of them. And it takes a new kid on the block every so often to try and innovate and create some new things and that's what we're truly trying to do.

We have a whole bunch of features here that provide for writing great multimedia applications, dealing with video and so forth much more easily, much more quickly and with much more flexibility than we see in anything today from those other platforms.

So this gives you as developers a real good framework and an opportunity to come up with something that is really new and exciting. Applications such as the mixing application you saw this morning, the 3D sound stage type application.

There's nothing particularly surprising in the concept of, you know, instruments as blocks on a stage and being able to move them around left to right so that they go left to right in the stereo mix, front to back so they get louder and quieter. That's a very, very good analogy and very good mechanism.

Now, why hasn't anybody done it before? Well, because they couldn't. The idea itself isn't unique. There's no real great thing in that idea, but nobody in their right mind would have ever contemplated trying to do something like that. On Windows or the Macintosh because they would have known once you got about three streams of audio the whole thing would have just fallen apart and you would have never been able to achieve it.

So rather than have to code for the special case, you probably have really good ideas on what a good application should do on some particular area, and all you really need is the framework that we hope we provide in order to be able to get that application out there and happening and so that people can go back to doing things in a logical and sensible fashion. And Dominic did a very fine demo and Benoit's sitting in the back of the room.

How long did it take you to do that, Benoit?

Mr. Schilling: Three days.

Mr. Kimpton: That was days, not years. Three days? You did sleep? You had some sleep?

He slept too, so it wasn't a really sort of MacHack, three days, you know, I'm going to do it, I'm going to do it type thing.

So good ideas are easy to implement and quick to implement and that's the real sort of chance and thing that everybody here now has, the opportunity we hope we give to everybody and make you a little more successful.

So a conclusion and then questions such as you have them.

The kernel's really small. It's very, very flexible, very extensible. It provides very, very low overhead performance penalties for whatever it is you're trying to do.

Jean-Louis mentioned this morning the idea of software silt, and a good take on this analogy is platforms like Windows and the Macintosh have become images, powerful rivers and they have an immense force and carry a lot of water, but as they begin to reach the coastline and turn into sort of deltas and widening sort of all-encompassing types of things, they lose their power, they lose their force and they begin to drop silt on the floor. And that's sort of the thing that we're beginning to suffer from now in software development.

So we try to be the new raging torrent a little, if you like and give you something that can carry you on and forward. And probably the most key part of that is threading; the ability to be able to create a multithreaded application simply and easily and have a platform which really takes the benefits from it is an important thing. It really is in this day and age, threads are just about everywhere.

First the most shocking example of how often threads come up or how easy they are to deal with is the video demos that you saw this morning of the video mixing and playing video and stuff. Conceptually the right way to do a video capture type thing is to create a thread, capture a frame of video, do something with it, destroy the thread.

Now, if you have one video capture source, that means at 30 frames a second you need to create a new thread 30 times a second and destroy an old thread 30 times a second. Two sources, twice as many; two sources and a playback window, three times as many.

And that is exactly what you saw this morning in the video apps. The video mixing demonstration does exactly that. It creates a new thread for each input and each output 30 times a second and deletes them. Not because you can, but because it's actually the right way to do it and it makes the most sense.

And there's absolutely no reason in the Be Operating System why you shouldn't do it that way. That's the real thing. We're trying to remove any barriers or obstacles to doing things the right way and the sensible way.

So thanks very much for sitting through this much. If you have questions, we can certainly take some of them now and as we say, we have a rogues gallery at the back and we're certainly progressing through fairly quickly on time and we'll take about a five-minute break, if nothing else so that I can drink something and we will then move on and have some time to do a look in detail on what the applications are.

I don't see anybody frantically waving at me.

Oh, good. Thank you.

(Inaudible question.)

Mr. Kimpton: Let me just repeat the question for those of you in the back of the room.

One of the things you saw on the slide was the division between client side and server side components. Just see if you go can flip back quickly. Okay. This yellow line here on this slide.

So the question was can you actually go around these software kits here in this top thing. So if you really want to talk direct to here, in fact, even better yet, wouldn't you even want to talk down here? You want to talk this way. Hey, I need the performance.

And the answer is yes, you can. There are a few well-documented examples of how to do that and the best one and the one that's probably most demanding to most people, is the DirectWindow object that was mentioned this morning and was at the heart of a number of the demos you saw this morning and there was some even more sort of mind-blowing ones.

Essentially when an application wishes to put something to the screen, in a regular sense, it talks to the software kit, which talks to the application server, which talks to the hardware and bing! Your bitmap, your window, whatever, is displayed.

Very easy to do and it offers a lot of good features for doing it, but there are times when you just don't want any of that. Software silt layers are a bad thing, get rid of it.

So what DirectWindow allows you to do is very simply set up mechanisms whereby you can draw direct to the video card if you wish or go right around all those layers if you want to.

Now, there are penalties you pay to do that. You have to be very careful, because you have every possibility and every chance of really screwing things up. So there are -- this is, you know, this is not a task for the fainthearted. Playing with DirectWindow is a skill that does require a little more care and attention in how you progress to do things and, you know, if you don't do it right, you have every chance of blatting things all over the screen and putting all sorts of nasty stuff all over the screen. But the features of that -- and DirectWindow is an example of one of those, and I think as we see the necessity to have more of them, then you will see more.

I'm just trying to think. I don't have the schedule memorized, but there are at least two DirectWindow sessions during the rest of this afternoon and tomorrow, so the specifics are probably best covered by those two sessions.

A Speaker: BDirectWindow will be covered at four o'clock this afternoon in this room.

Mr. Kimpton: For those of you that didn't hear that, that was four o'clock in this room for the BDirectWindow detail session and then BDirectWindow is part of the media kit which will be covered tomorrow morning. If you go to the DirectWindow you'll miss Doug again, of course. He's pretty good.

In the red up front.

The question was as well as the journaling mechanisms in the file system, is there a relational database in the BeOS.

There isn't a full relational database. The attributes mechanism provides you with the mechanism to create a simple flat file base. But a full relational database is an area where all of you can contribute. Well, those of you who feel like writing databases anyway.

Okay. We'll take five minutes if we can, so it's 1.35. At 1:40 we'll sort of continue on again with a look at the applications.

(Session concluded.)