|
Approaching the BeOS |
WILLIAM ADAMS: Hello. Welcome. This session is called Approaching Be. Be as in the company, approaching Be programming, sneaking up stealthily on the new computing power of the 21st Century.
My name is William Adams. I am one of the developers, support-type people. So if you ever send mail to Be, and you're a programmer, and you're asking a question, chances are I or someone I work with will probably be answering it.
In this session, there are two sessions on early approaching Be. In this session in particular, I'm going to go through general high-level concepts, a little bit more detail than what we did in the general session. We're not going to go deep into the code.
In the next session, which is more approaching Be, we're actually going to go through several applications and say, "Oh, here's a thing, how do you do that?" You know, "How do you do Windows? How do you do POSIX? How do you send messages?" Blah, blah, blah, blah, blah. So we unfortunately are going to be cutting this one a little bit short, but it's okay.
At the end of the -- after I stop talking, raise your hands, ask questions; and if you want to ask questions along the way, I think that's all right too. I'm not too rigidly stuck to a schedule on this one, so -- other than 45 minutes.
Okay. I said all my wonderful words in the beginning.
Why Be? And this is the question that
we've already answered a little bit in the general
session. And the question that comes up for
developers, like I was developer before I joined Be,
and the question is, how are you going to make money?
How are you going to create apps that take advantage
of the new hardware? How are you going to take
advantage of all the hardware that's cranking out
there, dual processor, quad processor machines? I
mean, if you're like me and you came from the NeXT
slash -- by way of Commonpoint/NT world, you find that
you keep spending more and more and more on machines,
but the software really sucks.
So we went through this in the general session, but, you know, how is Be the answer?
Well, the general idea is that we provide an operating system that doesn't leave your hardware behind. One of the things that I noticed when I was programming on NeXT Step was how responsive you could make a 68k Mac-like machine operate, at the same time everyone else was marching towards more power, more power, more power.
Well, you know, let's step back, you know, a PowerPC 103, back years ago, we'd be drooling over the fact that it runs at, you know, a hundred and some odd megahertz. I mean, I was excited when people were talking about a five MIPS machine. What happened? Well, the OS layers just kept piling up, and you lost all that power.
So some of the key features that you see in the BeOS that make it the zippy little thing that you saw in some of the demos this morning are all these little buzz words that way have listed up here. But the buzz words on the -- in and of themselves don't really mean much until you actually put them to use.
Symmetrical multiprocessing, does anyone know what that is?
Okay, does anyone run a machine that does symmetrical multiprocessing? Okay, good. Because you're all running the BeOS, and that's a good thing.
Symmetrical multiprocessing basically means that -- let me see if I can dazzle the dorks. We'll just run a simple little app. The application that I'm bringing up right here is called Pulse. And if you're familiar with the BeOS, you're familiar with what this thing does. It's telling me I've got a couple of CPUs; and if you'll look closely at those lights, and we're not on a BeBox, so you don't see the lights going up and down, which is unfortunate, but here's our virtual equivalent. And the general idea is that you can turn one of those things off and processing still occurs, but you'll notice that that second processor is now doing more, okay. And I turn this CPU back on, and the load -- exercise for the reader.
Believe me, as depth support, we've seen that happen. We've had bugs filed against it. That's our developer filter. So if you understand our program, don't send that as a bug report.
This is symmetrical multiprocessing. It basically means that you don't really care how many CPUs are in the machine, and you don't have to -- you furthermore don't have to do anything special to deal with extra CPUs. Your job is essentially to reinvent your application in a very multithreaded way. Our job is to make it run efficiently, and that's what symmetrical multiprocessing is all about. Your application, once divvied up into hundreds of threads, will run even better on a machine that has, you know, four processors, like the quad Daystar, on a single machine.
Preemptive scheduling is different from what you might see with a -- certain other operating systems where you have cooperative scheduling. If you've ever written code that says something like thread yield, you know what I'm talking about. In our operating system, you don't really do that.
Threads, you set them at various priorities, and you're basically saying that in this application, the thread that's drawn to the screen is high priority, okay, do it a high priority. The thread that is taking keyboard commands is maybe a little bit lower priority, so it doesn't have to be high. You don't explicitly have to say okay, go to the screen, go to the keyboard, go to the screen, go to the keyboard, you know, you don't do this processing dance, and that's what preemptive scheduling is all about. I need water.
Protected memory is your apps don't crash when other apps do. So we used to have a demo where we'd actually make an app crash, and it's just so hard to do in DR9 now, I can't get it -- thank you very much.
I'm going to drink while you have nothing.
Okay. So the general idea is, let's pretend that we're on some other OS for now, and let's pretend that, okay, that one just crashed, all right. Well, I've still got my windows, and they're still responsive, and they're still running around, and there's really no problem.
That's not quite as potent a demo as what we did in DR8, where we actually crashed an app and ten things were running and they kept on running; but imagine, if you will. That's what protected memory is all about. Every application runs in its own address space, you crash one, it's gone, the rest move along, there's no problem. And these are all things that you expect out of a modern OS. You'd be silly not to be doing this stuff.
Multithreaded from the bottom to the top. This is something that, unless you've really dealt with something that calls itself multithreaded, you don't really appreciate what that really means.
If you take, for example, oh, I don't know, the Mach 2.5 kernel, this is a -- I was a NeXT developer, I did multithreading; this is something that Mach was designed to do, lightweight multithreaded programming, and it does, the mock kernel does.
As soon as you hit, I don't know what, display PostScript or something like that, you know, you're back into a non-multithreaded world. So it doesn't -- I don't know why someone designed a system like that, but if you don't percolate up the multithreadedness all the way up to the top layer, you've got a killer engine, you've got a killer engine at the bottom, and you've got kind of a Volkswagen at the top, and, you know, it doesn't mesh; and you see it very much so in the interfaces, because they're not snappy, and you have things going on, like you click on a menu and everything stops in the interface; and, you know, I don't know who would do it that way, but if you imagine, you know.
So I'm going to show you briefly -- no, I'm not. I'm going to just show you that yeah, I'm just moving windows around, and it's no big deal, and I'll run a couple of apps to try to tax the machine a little bit, which just gets harder and harder all the time. But as I'm -- I'm calculating this Mandelbrot, and it's running along, and I'm trying to slow the machine down, and not being very successful, but at the same time, I can move things around.
We have a general concept where every window in the operating system is governed by a single thread, so that means that while I'm doing this massive Mandelbrot calculation, I can move this window around, it's still going to stay snappy. It might peg the CPUs, but that's okay, you know.
In some other operating systems, when you do something like that and you click on another window, you stop. The whole point of having multiple threads or multiple CPUs is share the load, you know; you don't need to stop. So there's no real point in that.
Okay. Move on to the next slide.
Okay. Doing good on time.
The evolution of programming on the BeOS.
Oftentimes, when new things come along, and
I wrote a Mac tech article on this whole thing, a
paradigm is worth 20 cents. This is not a paradigm
shift. It's not the whizziest, bangiest thing on
earth. What we are is very small, efficient, usable,
and salient to the times. It's an evolution of
programming.
When I first started programming, it was on a Commodore PET in machine language. You know, you blow up from there, and you take on bigger and better languages, and on and on and on, and one day you wake up and you're 30 something years old, and you go, "You know, I used to be able to program in Assembly," and then you find out that you're a manager now.
Programming has been an evolution. Languages have matured, systems have matured, us as developers have matured, and the BeOS is next on that evolutionary step. It brings to the common programmer, if you will, some stuff that typically you found in, I don't know, a few years ago, mainframes, or at least certainly much larger machines than $1700 boxes.
Multiple processors, I mean, what the heck? It's just an evolution. It brings to you stuff that you were probably thinking and wanting to do a few years ago but probably couldn't because you couldn't afford a dual processor Alpha machine or whatever. So it really brings down a lot of stuff that you've been playing with. And it coalesces, you know. If you've gone -- if you've followed along from the Mac through NeXT through Windows, all these various GUI systems and various other low-level kernel-type things, it pulls it all together and says okay, let's steal from this, I mean let's take the best from here and the best from there, and, you know, let's move forward. Let's stop playing silly games.
At the same time, we stick to familiar frameworks. If you are a Mac developer or even a Windows developer, if you use something like Mac app, PowerPlant, the MFC class library, you know what we're talking about, you know. It's like okay, there's a class; it represents a window. There's a button, it represents buttons. So these concepts many people have already gone through, and there's no need for us to say, "Oh, no, no, no, no, no, let's throw all that out, let's do something completely different. Have you ever heard of Be widgets?" You know, forget it, you know. Let's talk about windows and buttons and get that stuff out of the way so we can get to the cool stuff.
So we give you familiar frameworks. We use familiar languages. As I stated before, C and C++ is what we do. And you can debate the merits or depravities of this language choice, and people have, ad infinitum, ad nauseam. But there it is, you know. If you go into any bookstore, you'll find the most number of books on C++, and that's what we use, for better or for worse.
And we use familiar development tools. At least to Mac and possibly now Windows people. Metrowerks has become well respected, probably the tool of choice, for the whole Mac crowd, at least. Maybe not so much for the Windows crowd, and certainly not for the UNIX crowd, but since a lot of these people are Mac people, I don't know, should be happy about that.
And we do everything with a twist. So not only do we give you the Metrowerks compiler, but you can configure it to do concurrent compile, so you can have three files compiling at the same time, okay. That's a good benefit that we can do that other operating systems don't.
Our windows, you know, thread per window. That's different. And no one else does it like that.
Multithreaded file system. Different, no one else does it like that, really. 64-bit file system. All these things, it's just if you go through the list of all the features that are in the OS, it's like yeah, okay, everyone has a file system, but does everyone have a 64-bit file system? Well, no, so, okay, we've done that, with a little bit of a twist.
Unfortunately, I'm not going to show the code snippet in this session; I'll just hold it for the next session.
It's interesting to look at the BeOS from
its various APIs, because the -- it's the old
elephant, you know, depending on which part you're
touching, you think it's something different. You can
walk up to the BeOS, jump into a shell, live in VI or
emacs and make, and, you know, never know that there's
a GUI above you. You can telnet into your machine and
be happy as a clam. Even Berkeley Sockets, although
they're a little bit different. So you might think
it's UNIX. Someone else from the Mac perspective will
jump into the GUI, never bring up a shell, use
Metrowerks, program to their heart's content, and
they'll think it's PowerPlant.
And for each one of these, just imagine a piece of code, that, you know, Hello World is one line, printf, blah, blah, blah; PowerPlant is about 50 lines of code, you know. And Hello World for us is, you know, ten lines of code if you want a GUI and one line if you don't.
So basically, we have a system that gives you familiarity, not from anywhere you come from; if you come from IRIX on an SGI, maybe it's not really that familiar, but for the most part, if you've done Mac, UNIX, Windows programming, it's going to look and feel very familiar.
You might say well, where's such and such, where's such and such? And the answer is, well, you know, DR10. 1.0. Maybe in the future. Or more likely, excellent third-party opportunity. But that's -- but you're going to feel familiar, you know; you're going to jump in there, and you're going to go, oh, yeah, okay, getting a window on the screen; and you can try this in the lab; it's very easy; it's going to take you ten minutes; you're going to go okay, how do you use the compiler, how do you use the editor? All right, where's make? Done. Okay. It's very familiar. But that again, with the familiarity, you -- it does not come stagnation. Just because it's familiar doesn't mean that it's old. Familiar just means that it's familiar, and we've done the underlying stuff, and in a nice new way that's better, we think.
I thought threads were for cloth.
These are just some specifics. It's like -- and we've already covered some of this.
Threads, what are threads?
Well, if you're familiar with the UNIX world, and even the Mac world or the NT world, processes are things that run your programs. The OS's job is to, when you click on or type the name of a file, is to sequester some chunk of memory, throw your stuff in there, and invoke the magic voodoo to make that thing actually control an airplane taking off.
Processes. Those are the things that actually do all the work. Threads are very lightweight processes that -- it's just a way of segmenting the work within your application. Say a word processor, okay, typical example. Here's my word processor; okay, I'm editing along here; say, I want to spell check at the same time. Okay, I'll spawn off a thread to do spell checking while I'm still typing. That's just multithreading; and the whole benefit of multithreading is, as I -- see if we have a real simple example.
Again, I'll go back to the old Mandelbrot, what I'm clicking on these boxes, and just, you know, zooming in on areas of this, there's several threads that are in operation at the same time. Anyone familiar with Mandelbrot calculation knows that it's a very, you know, calculation-intensive sort of thing.
In this case, I have one thread calculating even scan lines, one thread calculating odd scan lines, one thread displaying the stuff to the screen, the familiar thread that controls the window itself; and then on the app server side, there is another thread that deals with the window and the mouse and on and on.
So even in this simple application, there there are several threads operative; and from the programmer's perspective, they're not really in the way; you don't have to do it this way, and some threads you get for free anyway, and you can't get around them.
So this is what threading does to you. This similar application, if it is not multithreaded, doesn't have lightweight threads; you're not going to get the same sort of performance. You might get -- I'll leave it at that. It's just not going to perform the same sort of way. So threads are a very helpful and useful construct for OS development.
HFS, BS -- BS, who knows; file systems, what are file systems? Who cares? What's the relevance? I don't know. Next slide.
No, the relevance is, you know, file systems are where data is stored. And in this world, you don't live on your own machine. I mean, you typically either network or you're sharing with a friend or you're sharing across the Net to get Web pages or whatever. And all of these things are stored out there in the world, in all sorts of different formats. The Mac has a thing called the HFS. Be has the BFS. NTFS is on NT, strangely enough. DOS FAT, go figure that one out.
The file systems all have their own little peculiarities, features and benefits and trials and tribulations. What some of them don't have is what we do have, which is extensibility.
In the Be file system, there's two separate things. There's Be file system itself, and let's just kind of set that aside for now.
Now there's a structure in which that file system lives. That structure's extensible, such that I can plug in file systems. So if I want to go to my desktop, which I will do, what I've done on this particular machine is, if you look at this window right here, it says disks. I have two disks. One is my internal drive, this top one, and this one is a CD. This top one is formatted for DR9, so it's running the BFS, the Be file system. This bottom one is actually a disk drive, a CD from DR8, which was the OFS, the old file system. Yet I was able to mount this disk, because we have added a plug-in to the current DR9 architecture that knows how to deal with the old file system.
Similarly, we know how to deal with the Mac file system. You can, as a plug-in writer in your spare time, write one that understands how to talk to NTFS or a satellite file system. I don't know. It doesn't really matter what the file system is. There's a world-defined API that says implement these, I don't know how many, five or six functions, and you will now look like a file system.
The logical extension of that is, well, can't I create file systems that don't exist? It's all virtual, right? Yeah, sure.
So what we have is here I am in /dev, okay, and we see things like disk, GCE, hack, keyboard and mouse, these are all devices, basically. /dev is a file system. And these aren't real files. I mean, there's really no content in them. But it's a represent -- it gives you a file representation of devices. So let's say you want to spit something out to the serial port. You type something, open up dev serial one and send it out, away it goes.
A SPEAKER: Is it UNIX stuff or is it Be stuff? What is it?
WILLIAM ADAMS: UNIX stuff or Be stuff. It's our stuff.
A SPEAKER: Looks like sort of UNIX stuff.
WILLIAM ADAMS: Yeah, well, you know, let's go back to the previous slides, of familiarity, right. If you really nail us down, you will -- and start really asking the questions, well, what the heck, where'd this come from, on and on, you will win your way towards Dominic. Dominic Giampaolo. He's the guy that did the file system. And on any given day you can see him muttering through the halls, "POSIX, POSIX rules, POSIX." So --
A SPEAKER: Would you write this stuff, you can -- API stuff, Be-wise, it's --
WILLIAM ADAMS: I think the question is what's the big deal, do we provide anything different than UNIX does for this?
Well, of course, you know, when I joined Be, my official title was Technical Evangelist. So I'm going to tell you a bunch of bull right now, but you're going to believe it.
Our APIs are far superior to anyone's. You will find that it is much easier to create extensible file system plug-ins for our system than it is to do it on any others. Having said that, which means I'm going to follow it up with a, you know, big caveat, this API is not generally public yet. It will be very soon, but that hasn't kept us from sharing that API with people who really want to do it, and we give out source code.
And one thing you'll find about Be is that we're very friendly with our developers. And me being the -- one of the reasons I joined Be was because in my own company I could not give out source code freely, and now I can. It's my job to do so. And we do.
So, you know, I have nothing about corporate secrets, and I don't give out Be's corporate secrets, but anything I create on my own and anything I can steal, I mean, acquire from our internal engineers, you know, we put out.
So if you really want to do this, it is not hard, and we'll give you all the help you need. Like we're helping to do a PGP encryption layer on our file system. Why? Because they want to, and it's not that hard.
So anyways, as you see, /dev has a bunch of things in it, and this is implemented because there is a virtual file system that implements /dev. So if anyone wants to write an NFS server incline, which someone has, you can do that, or whatever. It's wide open.
Okay. Yeah, so what's the difference? The Be file system, which I kind of shoved off to the side there, there are particular features in our file systems, not the architecture but the actual file system itself, that we think make it much more useful, much more beneficial to the people who are trying to get along in their daily lives.
What the Be file system provides primarily is an attributed file system, 64 bits, internally; and there's another session that goes into that completely, about what it means; but basically, what it means is you can have really big files, you will not corrupt your file system quite so easily as you do in some other places; and the other one I left out is multithreaded.
Accessing multiple different files at the same time in a multithreaded way is what we do. And that's not necessarily what you find out of all file systems. So that was one of the very key design criteria, was it's got to be multithreaded. We're running on multithreaded machines, why wouldn't we multithread our file systems.
So it's very multithreaded, which means that, as I always put it, the snappy index is higher, you know. We get a seven whereas other ones get a five. I mean, that's just one of those things that, you know, you're cruising along, you're doing things really fast, and you go, "I don't know that this is any different."
You go back to your other machine, and you
run things, it's like, "Oh, man." You know.
You will notice this stuff. It's not in your face, but you will notice it.
Okay. So the fact that you're here on Mother's Day weekend either means you're dodging Mom, or, you know, you got a free plane ticket or whatever.
You know, we're new and exciting. Most of you probably don't know my personal history, but I'm a technology chaser. NeXT was a big thing for me for quite some years. I even made money off Taligent. And got a few patents. I'm a happy camper.
Be for me came along when I was actually doing work at Taligent. And it was, you know, it's like, imagine you're just standing around, this little kid comes shuffling up to you, "Hey, Mister," you know, it's like get out of here. A little hobbit machine, where you going to go with that thing? Oh, man, it's actually kind of snappy.
And at the same time, I had a, you know, Alpha machine on my desk running NT. And it's like okay, $10,000, $2,000. Okay.
So, you know, it's exciting. It's exciting to get into an OS where it's like, you know, this stuff isn't just -- it doesn't suck. It's not slow and cumbersome, it's loosened up, it's all unwired. It's like, you know, just imagine a kid running around, his arms all flailing all over the place, and he just can't contain his energy and everything, and you're trying to harness it a little bit; come this way, and can you render this for me in real time, please.
This is exciting. You know, it's like if you -- the way I think of it is, when I was a little kid, I always thought, how come cars can't run off water? Then I finally learned about fusion and fission, blah, blah, blah. And it's like, why can't machines run faster? A hundred and fifty megahertz, geez.
Okay. Well, you know, maybe your OS is tired and old and cranky. Maybe you need to replace it. And some people like me have been waiting years and years and programming their little hearts out, gathering frameworks under them as they go, and eventually you just kind of look down and go, "Yeah. I want to program in Assembly again."
And since you've, you know, you are now in the downslope of wasting your brain cells in life, you can't really remember how to do it, but the closest you can come is, well, okay, maybe I just need C++ and C that's done really fast.
And that's what we're about, you know. You can't go back to programming in machine language, and you probably don't need to or want to. You just need something to -- let's you create that killer tractor super ballistic application, and that's what you get, you know. And I'm not a hyping kind of guy, but it's -- I don't know, it's something you have to try.
Okay. Small, lightweight; these are just
concluding points, you know.
The kernel is truly small. Ours is smaller than yours.
A SPEAKER: How small is it?
WILLIAM ADAMS: Well, it's so small -- oh.
Let's see. Let's see how small it really is. It is -- of course, this is a totally unfair test, because it doesn't include the size of the device drivers and blah, blah, blah, but our kernel, and of course all you UNIX guys know what the heck I'm doing, everyone else is, "What the hell is he doing?"
Okay, our kernel is -- you only need one of these -- 462,000 bytes. I've seen smaller, but they were on adolescents.
Okay, so it's small. It's not built atop, aside, astride UNIX or anything else. So, you know, if you ask the question where did it come from, what was the model, you know, a couple of guys actually -- a couple of guys got together said, "Okay, well, okay, we need memory management, we need scheduling, fast scheduling, preemptive, protected," blah, blah, blah, that only requires this much; everything else is an add-on anyway. So it is not built on top of UNIX.
Well, how do you get POSIX? Well, POSIX is just an API. It's just a way of calling functions that is familiar. You know. That doesn't mean you have to sit on top of any particular implementation or anything. POSIX is just an API that comes in from the side and gets things done for you in a way that you want them done.
Multithreading is in its DNA, you know, we show from the bottom to the top, from the very lowest kernel all the way up to the windows. Threading is in there. You can't get it out. You know. You'll see it's very evident when you try to take something that was not designed with threading in mind and you try to throw it on the side of it. It's like, you know, it doesn't work. You will always run into some sort of problems, like, oh, yeah, they didn't think about pressing these two buttons at the same time or whatever.
So that's it. You know, these are the things. And I think Erich Ringewald went over pretty much all that I did this morning; and the bottom line is, your apps will rock on the BeOS. And that's just, you know, all there is to it.
That's not to say there's no work that goes into it. Whenever you have a multithread environment, it can be a very complex environment, and if you don't know what you're doing, and that's not to say you're stupid, but that's to say you may not be familiar with the concepts, there is a learning curve. You know. I'm not just going to say, "Oh, yeah, go out, prosper," you know. "Multithreading is in your future."
It took me two years of very intense sitting with Ph.D.'s, C++ programmers, doing multithreading, to finally understand, "Oh, I know what a semaphore is."
You know, it doesn't come necessarily easily, but then again, it's not that difficult. There's a few concepts you have to understand, and away you go.
So that's generally how you approach the BeOS. That's what we're about, that's what it gives you, that's what it does.
Questions?
A SPEAKER: When is the documentation for all of this stuff coming?
WILLIAM ADAMS: Well, let's see. Well, what we've done is, in DR8, we have the Be book, and all the documentation is online. For this DR9, well, okay, I'll let you in on a little secret. When you approach DR9, or any major release, it goes like this: API changes, API changes, API changes, and then you ship. Documentation happens somewhere along there.
There's a certain amount that we have done right now, and will be on our Web site, like it always is, as soon as we can get it out there. Since we didn't have a heck of a lot in as many areas as we would have liked, we provided several sample applications on the CD that you're getting today, that cover just about every new area that's in the OS. Some areas you can just go and look back at the DR8 documentation and it's exactly the same. Views, for instance. There's a couple of things that changed, but for the most part, the concepts are all the same. Look at the sample app, oh, that's how you set the font now. You know. So sample apps, sample apps, free code. That's my mantra.
A SPEAKER: You said you were a C++, is there any chance in the future --
WILLIAM ADAMS: Java.
A SPEAKER: Such a nicer language.
A SPEAKER: Repeat the question.
WILLIAM ADAMS: I thought I smelled beans.
The question is, will we do Java, or other assorted languages, right?
A SPEAKER: Right.
WILLIAM ADAMS: Java, we certainly have. Now that's what Metrowerks is going to be demonstrating tomorrow. A very fine brew indeed. You know. And you can discuss up and down the features and benefits of Java, and we've got it, and I think our Java will be better than everybody else's Java.
A SPEAKER: The question was?
WILLIAM ADAMS: Not exactly. I mean, Java's Java, so, I mean, AWT is your world, not the Be API. So it doesn't mean that you cannot create an application that looks like a Be application. But if you're writing in Java, you're writing in Java, and your intention is to go cross-platform.
If your intention is not to go cross-platform, you just like Java as a language, well, you've still got the AWT, because it was designed to be cross-platform. There is not a one-to-one mapping between the Java implementation and our classes. You know. There is not a Java window, which is just a Java implementation of a Be window. Although Java is an extensible language, and someone, probably not us, could write the glue layer that would say Be window, Java window. But, you know, with Java, you get what you pay for, and it's -- I don't know.
If you really want to take advantage of this stuff, you're going to have to use the native APIs, at this point. I'm not sure what will happen with Java or anything else in the future, but native APIs is really the way to go.
A SPEAKER: How long will it be before you support --
WILLIAM ADAMS: Oh, very interesting question. When I first got --
A SPEAKER: Repeat. Repeat.
WILLIAM ADAMS: Okay, sorry, sorry.
The question is, how long before you can port X applications to the BeOS, right?
A SPEAKER: Right.
WILLIAM ADAMS: Okay. One of the first things I ever did on my Be box was port several little X applications, and the porting process goes, "Hmm, don't need that, don't need that, don't need that."
But for people who like to have extra code in their applications, there was a -- there is an implementation of an X server that runs on the BeOS. It is not a commercial product at this point. But I've seen a demonstration of it, and it was running Netscape on a Be box, basically, and so, okay, that's cool, if you want to do that. I'm not sure what the -- you know, and I've seen -- that was one that I've seen firsthand, Gregory Humphries.
There's another one that I've seen someone say I'm thinking about doing; we'll see what happens. But X isn't the hardest thing in the world to implement, especially if you want to just take the standard implementation that you get for free. That doesn't take too long.
But as Be, you know, we probably won't do an X server, because it doesn't make sense, really. But there have been a couple of efforts to do that already.
A SPEAKER: I was just wondering, we have a lot of applications that we've developed in C 32 or something like that. Will there ever be a -- a C API to the --
WILLIAM ADAMS: Will there ever be a C implementation to the API.
Not being the CTO, I can't really answer that, but I can give you my opinion. I think it's -- it's a question that's come up enough times, and enough different ways, that I think something needs to happen.
I myself find that, you know, when you're porting a language, like Basic or something, man, I need to tie into the Windows systems, or something like that, it's not too hard to write glue code, you know, C wrappers that go on top of our C++. That can be done -- it was done to get some access in Tcl, for example, which uses C interfaces to do things.
It's not the hardest thing in the world. I don't think that's a main point of the direction that we're trying to go. But I could certainly see someone doing that.
In the back.
A SPEAKER: William, when I was trying to port a UNIX app about six months ago, the version of Be I had at that time, I ran into some difficulties with not having support for a shell, and some other UNIX-type stuff, that seemed to be -- basically required I change --
WILLIAM ADAMS: Well, let's do it like This. DR9's the answer. What's the question?
What you'll find is that the POSIX support in DR9 is more complete than it was in DR8. Fred Fish, if you can find him floating around, does this thing called geek gadgets, which was originally on the Amiga. It's basically a bunch of GNU source, ported. And we gave him an early DR9 disk, and he chugged away and chugged away and ported GCC and autoconf and M4, all these things that you need to make those make files just kind of work out of the box. And he ported a whole bunch of things that just out of the box you can unpack them and type configure and make, and they just work.
So in DR8, it was more difficult. There was a lot more work. In DR9, there are a several tools that have been created or otherwise come to fruition that make it a lot easier.
For example, what do we have, VIM, which is the VI editor. In DR8, someone had ported it and done all the appropriate things. In DR9, you can almost take the straight source, the original straight source, and just make it work. A fork, as Dominic put it, is no longer a spoon.
Signals work a little better. You call system, and you get back the return values of the processes correctly.
So all of these things that in previous releases are like, oh, man, now I got to do this, you know, a lot of those things have been ironed out, fixed, improved, whatever, so I think you'll find a much easier time porting things that are UNIX.
A SPEAKER: In DR8, a lot of the interface was --
A SPEAKER: Question?
WILLIAM ADAMS: Okay, sorry. Well, the question is -- never mind. I won't say it that way.
DR8 was lacking in certain features in the interface in terms of reentrancing. Does DR9 improve on the situation? Yeah.
There's still things that you're going to have to deal with, but for the most part, the places where it's unsafe, if you don't do the right thing, and that's typically you lock something, you're going to hear about it, because the system's going to throw up an exception saying hey, this thing wasn't locked, you know. You can't get the view bounds when you can't lock the window.
So -- oh, you want to answer it?
A SPEAKER: I wanted to understand a little bitter, by reentrancing, what was the problem you were having?
WILLIAM ADAMS: This is Peter Potrebic, Mr. Interface, by the way, so --
A SPEAKER: There are a lot of cases where you have to manually insure that you are doing synchronization properly. You could blow up unless you carefully lock --
PETER POTREBIC: Yeah, that's still the case. A window runs, as William said, every window runs in its own thread. If you're accessing that object from another thread, it is the caller's responsibility to properly lock and unlock the object if you're making direct calls.
We felt if we were to automatically lock in every call, that wouldn't be as efficient, because if you're going to make four calls in a row to the window, and if we were to try to implement the locking, we have four calls to lock and unlock, when one would do.
Secondly, for making the virtual function call, for example, that's going to dereference the pointer before you actually get to any code to look up in the V table, so you have to actually have the object locked before you actually make the function call, in order for it to be safe. So we couldn't even implement the locking for you inside the call. You have to do the locking before.
So all of that is still pretty much the same as it was in DR8.
WILLIAM ADAMS: Yeah, it's really not a question of re-entrancy. It's more a question of how do you properly deal with the multithread user interface; there's some things, like I said, you know, it's not all peaches and cream. There's some things that you have to do yourself.
One more question. Who raises their hand the highest. Okay.
A SPEAKER: Yeah, now that Fred Labs said they're not going to be doing virtual math, does Be have plans?
WILLIAM ADAMS: This is the marketing response that I've been told to say.
Is Mark Gonzales here? Okay, he's not here.
Between you and me -- it's emulation -- okay, let's do it this way. Emulation technology is interesting. There are better ways to go. We are looking at various implementations that are not from Fred Labs. Actually, one of the developers who created the emulator that they use is here today. So, you know, there's not just one way to skin the cat, and we're exploring those other ways. So -- and some of those ways are not simulation, but recompile your code, and boy, look how much faster it is. So, you know.
A SPEAKER: What kind of time?
WILLIAM ADAMS: Well, here we are at -- what is this release? This is the pre, pre, pre announce, preview, blah, blah, blah; DR9's out now, 1.0 is sometime this fall, I believe.
I would say, this is just, you know, me being an industry expert, that we probably have to have a solution by the time we hit Mac World Boston, or at least a well-stated direction of a solution. It would have been nice to show at Apple today, but not going to happen. So -- and that's it.
Now that we're done with that session,
let's move on to the next one.
Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support