RICO TUDOR: Hello. Good morning. Everyone awake? My name is Rico Tudor, and I'll be talking for the next 45 minutes to an hour on BeOS and UNIX compatibility.

I presume most of you here know and use UNIX already, so I don't have to introduce it beyond saying that, in our world, under BeOS, when we say "UNIX compatibility," we mean POSIX compatibility.

For those of you who don't know, UNIX is a fragmented market. There are different versions of UNIX, and part of the problem, the joy, the tedium of living under UNIX is having to port programs to different versions of UNIX. And even users who use UNIX will encounter annoying discrepancies. So we've been forced to choose the version of UNIX that we're going to claim to have compatibility with, and POSIX for various reasons seems to be the suitable version.

One of the things that BeOS advertises on the GUI side of things is no legacy, it's a clean slate, everyone can start writing applications as if the system was fresh and new, which it is. So, some people will be asking, "Well, why are we carrying one of the biggest legacy OSes around into this world?"

Well, I think the reason is, we believe that there are people out there, I'm one of them, who like UNIX. It's what we are used to, it's what we grew up with. And we find a great deal of attractiveness in having a system software layer, which is what POSIX is these days, which runs on all different kinds of computers.

It's also a way for people who want to see what a GUI is about and haven't really used one much before, programmed one, but who have a lot of code that they have already written or have written and intend to maintain and they don't want to give that up, throw it away, this way you can bring over your code, and if you wish, if you're a hard-core text-oriented person, you can use BeOS as a POSIX box.

Meanwhile you've got the -- well, it is claimed that there is a graphics user interface on BeOS for those who want that. There was some comment on the net, some article, someone was saying, if you didn't open a terminal window, you wouldn't realize there was a text interface. I like to say, if you didn't click on one of those pictures in the corner, you wouldn't realize there was a graphics user interface. So I'm going to be doing a lot of the text side of things, and we'll see how much we can do.

What I'm going to do is present these three main topics, and I'll take questions at the end of each one, and that way, if you have any questions in your mind, you're not going to forget it an hour later.

I gave this talk about six months ago in California. Were any of you there? Am I speaking to a fresh audience? Pretty much a fresh audience, so I can tell all my same jokes.

Basically the version of the system that you have now, Advanced Access, Preview Release, I will be considering those basically the same, basically be talking about the Preview Release and differences compared to our Release 8.3, which I'm sure you people have had some experience with. When I say that this didn't work, but it works now, I'm referring to the last numbered release, 8.3, versus our much new improved OS and POSIX compatibility.

BeOS POSIX is a work in progress like the rest of the system. It's true there are things that don't work, things that are incomplete. I just want to say that there are members in Be which support POSIX because we believe in it, and so it's not a passing fad. If you find things wrong, please let us know. It's something that certainly I see as a permanent part of BeOS.

Members of the POSIX camp include kernel writers like Dominic sitting over there; Brad, who does our networking, he's a hard-core UNIX type, he's not here today; myself. Someone is raising their hand over there, is that Peter? Are you a hard-core UNIX type?

PETER POTREBIC: No, I like POSIX.

TUDOR: Even our GUI person likes UNIX. So, Moni, who is not here right now, but he did a lot of the standard C library stuff that I would like to think of being on the POSIX side of things.

So POSIX compatibility, a lot of the early implementations of system calls, and POSIX is a collection of system calls, not that that means very much anymore; we think of it as a collection of useful functions that do system-like services. Our early implementation was not so good. Some of the biggest problems revolved around Fork, which is a pretty bizarre system call, and yet is very important to certain POSIX programs, like the shell. The ones that need Fork really want it to work correctly, and before that wasn't the case.

Thanks to Dominic and another person he worked with, we now have what I consider to be a robust and efficient version of Fork, and that just makes everything work so much better. And it's not only a matter of efficiency and technical correctness, you can also see it in the way, for example, the shell works, and I'll give you some examples, type in some examples of the usual powerful shell commands that we're used to on UNIX working flawlessly under BeOS.

Another area which has seen a lot of work since 8.3 and is now pretty much exceptionally good work is the signals. For those of you who don't know what signals are, it's a way of delivering an asynchronous condition to a process. The most common thing you might do is to interrupt, Control C or something on your keyboard, and that will stop some job running and all of that without crashing the system or affecting programs running in other windows of the system.

Let me talk for a moment now about the face of POSIX, the portal, the way we see things happening. POSIX, of course, being a bunch of functions and the programs that call them, isn't a very interesting thing to look at; however, it's necessary to run your program and see what it's doing as well as to communicate with it to give it input.

On BeOS, the two main ways of interacting with the POSIX program is through Terminal, which is the application that you click on and it pops up a window, which is emulating an ANSI terminal. In that terminal, you will usually find the shell. Notice I said "usually," because if you want, we or you can invoke Terminal without having a shell and it can have some other thing in it. You could run BC, desk calculator straight in that window, if you don't want a shell in there. You could of course open the window and see the shell prompt and type BC and get the same effect.

The second way that you might be using the BeOS and interacting with the POSIX side of things is by connecting in through the network. So, that's what we would call Telnet on the UNIX side. You Telnet into the box, you get the shell prompt. It doesn't sound very security oriented. We have versions of software which we're not shipping right now where you would actually get a log-in prompt and then you would have to log in like a password. So that's more of a UNIX style access to the box.

An area of interest to most UNIX users and to the programmers is terminals, not terminals as in what I just described, but the terminal layer, TTY commands, STTY commands, TTY services like erase and kill and setting your baud rate, things that apply not only to terminal emulators but also to actual physical terminals hooked up by wires to your serial port or, as the case may be, modems or printers.

The services now available in BeOS closely resemble UNIX in that we have STTY commands. When you Telnet in and out, you can set your echo and your erase and your kill, and programs such as Kermit, which may or may not have been ported by some third party, can operate the serial ports in a UNIX-like way, using the Term I/O or the Term I/OS programming services, which is defined by POSIX.

This includes signal-related activities, so Control C is generating a sigint. We also have some of the more obscure signals, like SIGWINCH, which allows you to resize your window. If you're on a remote system and you Telnet into the box and you resize your window, you can run an editor, all that over the network. Similarly from the terminal window, you can resize that, invoke your editor. You could Telnet out of the box to some remote system, maybe some UNIX machine. You can resize your window, edit a file remotely using your favorite editor. SIGWINCH is correctly promulgated in both directions.

We have the notion of process groups. This is necessary if you want to hit Control C and cause the right kinds of programs to stop running. If you detach a program so you say something like sleep 100 amper in shell, that is not going to be something you want to terminate if you hit Control C to that shell. That process has been detached. So that's an important feature for running networks -- I'm sorry, daemons, background processes, which you want to start up from the shell, but you don't want them to be affected when you close the window or log out. So that way you can start maybe a five-hour C compile and then log off of the machine.

Now, one reason you might want to log off the machine is if you wanted to make room for someone else to use it, so you could have your C compile running and you can say, "All right, Joe, you can use the machine now." Does this mean we have multiuser support? Well, not quite. That's one of those things which is being done, and also requires support and agreement from the BeOS native side, that we have and be able to administrate multiple users, multiple user accounts, logging in, doing our passwords. None of that has been decided at this time.

If you were at Dominic's talk on the file system, he mentioned that the file system itself, being freshly written, is already set up to have users, different users owning files and have permissions checked. This does not mean that we have multiple users yet, because one, we don't have administrative aspects like password files with user names in them, and we do not have the support on the process side. We don't have a notion like this process is owned by this user as opposed to that processor. Until we propagate the notion of user ID into the kernel process management side, we don't have multiuser support really at this time.

Since we do have multitasking, you can certainly run multiple jobs, and like I said, if you want to start something up or maybe you're actually logged in over the network or a serial port into the BeBox, you can have two users doing work and not impinge on each other, except for efficiency.

So that's the current state of affairs.

Related to process groups and sending signals, all modern UNIX systems have what is called job control. That's something we're lacking at this time. I think the plan is to put it in. It's just another step in the area of the Term I/O support and TTY, the layer.

I think I'll take a break here and look over on the screen. One of the areas which relates to terminals and terminal groups, we have multiple windows on the screen, and each one of these is doing independent things. So this one can be running a date, another window can be listing something. You can do a compile in one window and so on.

These terminals, in UNIX speak, are actually different devices, and whereas we haven't completed the support for this, you should be able to log in, eventually, and type poo, and see what people are using the console or see what people have logged in on the modem. We're missing some of the services you would want in a UNIX environment, the multiuser and finding out what terminals are being used by what people. It's a small step in our current design.

Another area which I will show you further how you can make use of it, pipes, in UNIX, allow you to communicate from one process to another, often set up just off the cuff. You type it into the shell, you list the directories, pipe it through word count, find out how many files you have, that kind of thing.

Our performance is very impressive these days. I highly recommend that you use them. We have, I think I find 20 megabytes through a pipe, and it's not something that people who use MacOS are familiar with. However, in UNIX, we have pipes, we should be using them all the time, and I'll be giving some examples of how you can put pipes to work for you in terms of using BeOS in particular, not just UNIX way of using pipes but also BeOS way of applying pipes. Very impressive performance.

Our standard shell is bash. Is there anyone here who hasn't typed shell commands and so on? I guess we're all pretty familiar with it. We have the shell -- we have file name completion; you do a tab, you type in part of a file name, and it will type in the rest for you. We have all the usual erase and kill, editing history. If you type some commands in, you can go back and type them again, or if you made a mistake, you can edit them on line and then reenter them. Very much -- very different, of course from point and click, which is the graphics interface that a lot of people are looking forward to using on BeOS.

In the area of -- back again to system calls, some people ask about Select, which is sort of kind of a system call that came originally from networking but is now supposed to be a general purpose facility. You can use it to find out if there are characters waiting for you to read on serial lines, on pipes, any kind of character, special character device, like a parallel port or something. We do not have Select fully implemented, at the moment only on the network sockets. Again, I think we anticipate generalizing Select. It would require a lot of work inside of the kernel itself to support, and nontrivial, but I think it's an essential thing.

So I thought I would just for the hell of it to demonstrate POSIX compatibility, I'll just sit down here and port a POSIX app. Can you hear me back there? The first thing we're going to do -- and when we leave here today, I'm hoping that all of you will rush off and port one POSIX app that we don't already have, and this is the way we extend our little universe of tools, and you will see how easy it is.

First let's go off to some place on the net, Sun Site. Can you read that -- is this visible? Let's run off to the FTP archives, go into GNU. Somebody has already been here. That's interesting. Well, I don't know, there's an awful lot here. Why don't I just pick something out at random. There, that one. (Pause) So there's our tar file, gzip. What I'll do here is take a look at it, extract them. Okay.

So this is the way you will often find a pile of files in a distribution for some utility or another. This one happens to be grep. We do of course already have grep, but I'll just allow us to see that what I'm porting here is the real thing.

So now, it just so happens that this is a GNU distribution, and it comes with a shell command file which will very conveniently scour your system and see what version of UNIX you're using, and since POSIX is one of the standards, it doesn't have much problem finding out what flavor we are. Of course, some applications might take a little more work.

Okay. Now we do get some kind of an error up here, just to let you know that this can happen, so I have a minor error. Okay. Here's the problem. There is something that we need called getpagesize. Basically this is a little example of how our POSIX support isn't quite there. This should have come over straight and ported, and it didn't, so my guess is, we would have to go and look at a certain header file in our system and find out what's not quite right.

DOMINIC GIAMPAOLO: Getpagesize is not really POSIX.

TUDOR: And getpagesize is a BSDism. Nonetheless, we shouldn't have -- okay. So let me take a look at this file. Actually, what I'm going to do is, I'm going to show off a few of our non-GUI development tools. BE is the editor that some of us are using in Be. It's been around for a while, and I'm just going to pull in a bunch of header files. (Pause)

Okay, so we have a whole bunch of -- I'll explain what I'm doing here after I get this thing set up. Okay. So we're now in my textual IDE, and I'll tell you what I mean by that in a moment. We have this problem here with getpagesize.h, and this is the file which is giving us trouble, and basically -- it's not a very big file; however, what I'm going to do is eliminate some dreck here, such that we only have this line in the file, and if anyone wonders what it is, they can ask me later, but basically it's not that important.

There are some warnings, in fact all of these are warnings here, which I'm just going to ignore. So we still have this problem with getpagesize, which means I should make clean and make this again. Okay. Here's a little tag from one of our partners. I left it in there so that we can all remember to buy the unlimited linker when we get home.

So all we have to do now is to somehow manage to get this to link. I happen to have the unlimited linker somewhere. Okay. So that's the link completed, mwld.out. It look like grep. Let's go ps grep team. It looks like a grep working. Let's now use ours. What did I do here? Sorry about that. So that's how you do a port, and since it's so easy, I'll assign one of you to do the latest bash port, and it will take you just half an hour.

Okay. Maybe at this moment I'll take any questions relating to the POSIX compatibility issue, for those of you who might want to be doing ports.

FROM THE AUDIENCE: I'm sure you picked grep because it is fairly easy.

TUDOR: Oh, no, they're all that easy.

FROM THE AUDIENCE: I'm real interested in getting PERL running in your BeOS.

TUDOR: That may be actually an hour job. I'm kidding. That's probably a tough one.

FROM THE AUDIENCE: Really?

TUDOR: Yes. Actually, there may have been a port already of PERL. Does anyone want to confess having done that?

FROM THE AUDIENCE: Something has PERL 4.

TUDOR: There's a PERL 5. Is there a difference? I'm not a PERL user.

FROM THE AUDIENCE: PERL 5 was working for BRA.

TUDOR: So, I guess there is a PERL floating around.

FROM THE AUDIENCE: I did find a version that ran. It was an older version of PERL that ran for a developer, one of our developers, and whoever was doing it was planning on releasing another version.

TUDOR: Okay, then I would imagine if you can somehow --

FROM THE AUDIENCE: I just wasn't sure how involved the process was.

TUDOR: It will be pretty involved. I exaggerate a bit. Some of the tools like bash are not quite so easy to port as this one. But the main thing is that anyone who does a port and encounters certain incompatibilities, we would like to hear about them. So by all means send mail to Be, and -- yes, any other questions?

FROM THE AUDIENCE: You sort of skirted around the topic of user support. Could you speak on that a little bit, but if it doesn't come, will there be at least some sort of user --

TUDOR: It will come. You can count on it.

FROM THE AUDIENCE: Soonish?

TUDOR: Soonish? I mean, what we call internally DR10, kind of a month's away thing. I don't want to get in trouble with marketing, but anyway, the next release, the next serious release will have user support one way or the another. And of course how it looks graphically adding users to the password file, whatever it is, I don't know, but the way POSIX delivers the appearance of the existence of multiple users, you know, get pw name and of course get uid and set group id, all of that kind of stuff will work and will be enforced.

FROM THE AUDIENCE: Does that include shell preferences?

TUDOR: Oh, yes, sure. You will port that, won't you?

FROM THE AUDIENCE: Absolutely.

TUDOR: Okay.

FROM THE AUDIENCE: First question is, has anyone done python?

TUDOR: Someone has, yes, someone has done python.

FROM THE AUDIENCE: How does all of this stuff mix with the GUI stuff? I mean --

TUDOR: That's coming up. That's my very next section here.

FROM THE AUDIENCE: I was just admitting to porting python.

TUDOR: Oh, you're the python porter. Great.

I'm going to go on now to the next area, the second section, which has to do with the interaction of a POSIX application, running on BeOS, with the BeOS facilities themselves.

Now, as I was saying, some of you may be purists. You will say, "I just want to develop software that I can run on any platform, on any operating system. I don't want to get involved with BeOS. I just want the machinery, I want POSIX, the end." Users may want to do that. They will say, "I don't want to use this tool. I want to develop on this machine, but I want to develop under -- I want to design windowless C code. I want to be able to port this code away from this machine if I feel like it."

On the other hand, some of you will say, "Well, we're here, maybe I'm here because I want to learn about the GUI side of things, or maybe I want to play around with some of the kernel level, the BeOS kernel level services."

We have threads, for example; in POSIX, we do not have threads yet. For those of you in a rush or for those of you who want to make use of the kernel level services of BeOS, whether they're semaphores or ports or direct write or calls to the device drivers, that's certainly something that you can tackle by starting off from the POSIX direction and work your way in that direction programmatically or as a user.

Now, some of the interactions that you have to be concerned about -- well, first I should say, in general, what seems to be emerging as our specification is that we have a unified system, and that means that there is the GUI side of the world, there is the POSIX side of the world, but it's all unified under one execution environment, sitting of course on top of the kernel. There is only one kernel, and it supports both these kind of programming personalities.

However, the execution environment is the same. There is no difference really between a POSIX process running under BeOS and a BApp running under BeOS. They're really just the same kind of animal. The kernel doesn't see them any differently.

We tossed up -- I mean, we turned over in our minds whether to do it this way, whether to really do a split kind of different execution environments, as you see on certain kinds of machines, like mainframes that wanted to run multiple OSes actually, but we really don't -- we decided against that.

Now, some of the repercussions are it may be unclear to you, I have to admit it has been unclear to me, what the semantics are for certain combinations of the POSIX side calls and the BeOS side calls which involve kits.

So if you're interacting with kit calls, which do things like graphics and sound and maybe rolling in some file system stuff, BFile, those kind of things, with the POSIX C side stuff, where you might go sysopen to get to your files, and then do fread or something, or in the case of the POSIX side where you say, thanks, I'll run my own devices, I'm just going to open dev midi and do it myself, you may be unclear in your mind what's going on.

It is unclear with me. If you have highly technical questions, you should talk to Dominic. I will simply spout the party line here and say it all works.

One way can you tell what's going on in your system is type PS. It's not the POSIX PS command, but it's a PS command. You can see the number of threads running within each team. A team in our terminology is a single process space, and within it you have multiple threads running around, call threads, and when you go PS, you can see what's going on in your machine. Should you see a team that only has one thread in it, most likely that's a POSIX application, cat, sleep, DD, BC, that kind of thing. The BApps are pretty clearly differentiated by having lots of threads inside of that one space.

We do have some problems, you will see them. One of the ones that annoys me the most is printout. Printdef really should be considered a POSIX side call. Everybody makes use of printdef so you can have BApplications, you're instantiating Be on objects from various kits, and therefore could see this is a BApplication, we then go off and call printdef or something, and you know what is going to have happen now, you have multiple threads running. Well, okay, sometimes there are some problems, there are not enough interlocks in standard C libraries, and there can be some corruption.

In the case of printdef, you see some intermingled garbage, it doesn't seem to make any sense. Just something you need to look out for as you sort of drift off from POSIXland, where you are doing printdefs very happily, into a world where you are calling up some threads, either system calls like create thread or maybe you start creating a Be object or like a BLooper, which is a thread created implicitly, and then you start doing printdefs and you get into some problems there.

If you ask, well, what about Mallick, does it have reentry problems? Well, no. If Mallick had reentry problems, the whole system would fail. So there are some, I would say, mostly cosmetic problems involving calls to the nonPOSIX world when you're writing POSIX apps, should you want to start writing these hybrid applications, ones which are partly POSIX, and partly BeOS, well, Be native calls all within the same application.

Now, I'm going to show you now an example of how I approach the matter of hybrid processes, hybrid applications. Basically it's called back-end/front-end architecture, for whatever that's worth. The idea is that you separate the work that you would like done -- in some designs back-end and front-end architecture has to do with how computation or data storage is maintained on one machine or perhaps in one process on one machine to maintain coherency, and then the front end has to do with presenting or collecting or making use of that data, and of course maybe you have multiple front ends if you have that kind of an architecture.

In this design, what I've done is, I want to separate a POSIX program from a BApplication, and yet have them cooperate, and to the user you will just see one program running. They will not be aware of the internal structure of this application. All they will see is something that they can run.

The advantage of the back-end and front-end architecture is that the back end could be a great big pile of, say, POSIX code that you don't want to write again as a native BApplication, and maybe you want to keep it portable because you would like to run the back end off on the Cray and have the BeOS just do the graphics or the user interface, you know, the mousy stuff, and that way you've got an application which couldn't be written as a monolithic BApplication anyway.

So let me give you an example of what that looks like. Okay. This is on the Advanced Access as well as the Preview Release of BeOS. We're in the demos directory here. Calah is the name of the application, and it plays a game, which is an old game, very simple, but it makes you think, sort of chess-like in that you have to look ahead and there is no dice, there is no luck. It's just you versus the machine, pure logic. If you lose, it's your fault.

The idea is, clearly this is a BApplication. I mean, I've got a mouse, I can click on things, I've got windows, I can pop up rules using the BApplication kit, and basically it's everything that someone who is pushing the Be GUI side would say, "This is the kind of programming, this is the way we want it to look." This is a BApplication.

However, let's find out what's really going on. I'm going to CD to this directory. That's the file which I was just clicking on to launch it. You will notice it is only 116 bytes long, so there is something a bit suspicious about this BApplication. Aha. It's not a BApplication at all, it's a shell command file.

So what we can do, since there is only two lines of it of any significance, is track this down a little further and see what's going on. So the first thing is, we CD onto this directory, and we see what look like applications now. One of them is called Calah. Let's see if I can run it. Aha.

You will notice that it doesn't seem to put any stones on the screen, but the user interface seems to be there. It also seems to have printed out D zero for some reason. And then we have another program, this happens to be a POSIX application, called engine, and look at that. It says printdefs and scandefs. However, it suspiciously looks to be printing out a board in ASCII format.

So we can now take a look again at the shell command file, and without going into exactly how this works, we have feedback, which is some kind of command, and it takes one argument, which is this quoted command, which looks a lot like a shell command, with a pipe.

So basically feedback just fires this thing off, using forks and execs, all the usual stuff, very POSIXy, and the output from Calah, which is ASCII, goes into engine, which reads ASCII, so that's your pipe, and the output from engine goes all the way around, back to the beginning, and goes into Calah. So it's just a feedback loop, and the command feedback is just a small utility that you could use to hook the standard output on one end and the standard input on the other end.

So that's pretty much one approach, the simplest approach that will allow you to port a POSIX application from anywhere and run it on BeOS, and using the simplest of methods, attach a perfectly plausible front end to it, such that it's a BApplication or appears to be one. And you can even make up an icon, stick it in your executable directory next to all of your other BApplications and double click on it.

And this kind of approach is the most trivial of the approaches. Like I said, the Calah is running, the game, the engine is running on your same machine. If you didn't want it to run on your machine or if this was part of a network game where there was input coming from all over a network from different machines, you would have to set up some more advanced network-oriented plumbing, more sophisticated than feedback, but the same rule applies. You write what you want in POSIX, you write the other part as a BApplication, and you can keep them separate for reasons of portability or networking or because the back end is running on the Cray. It all works.

So I guess that's my presentation on BApplications and UNIX applications working together. So I'll take some questions now.

FROM THE AUDIENCE: How do you take the show file and make it double clickable?

TUDOR: If you do nothing except create the file, and just toss it right there in the file system, it will show up as a file icon, maybe yellow, or maybe blue, I don't remember which color. Anyway, you just double click on it, and it will launch.

FROM THE AUDIENCE: (Inaudible)

TUDOR: Yes, or no line type at all.

GIAMPAOLO: You just have to set the executable bit.

TUDOR: You just have to go change mode plus X.

GIAMPAOLO: So if you have a shell script, just make it executable, and then if you double click on it, it will run the shell script.

TUDOR: And if you want to make it look pretty, then you have to learn how to use the MIME set command.

GIAMPAOLO: You can set its icon using the file types app.

TUDOR: Or use the file types app, and you have to do a little artwork to come up on the icon.

FROM THE AUDIENCE: (Inaudible)

TUDOR: Right. What you're clicking on is on the surface going to look like a BApplication, so the magic that makes it look like and actually act like a BApplication launchable from the tracker is not a POSIXy kind of thing. As a POSIX thing all it has to be is a shell command file with the execute bit on, just like in any UNIX system, and then you would type the name and that would also work.

FROM THE AUDIENCE: You type NetPositive.

TUDOR: That's right. I type NetPositive. It doesn't make any difference. That NetPositive really is a BApp, but I can type its name perfectly, yes.

FROM THE AUDIENCE: How does it work, having older UNIX applications that aren't necessarily POSIX compliant?

TUDOR: Generally speaking, the progression of UNIX is from less to more to obscene, but, you know, more. The backwards compatibility is maintained. You could take a Version 7 application, if any of those still existed, and it probably would run very well on POSIX. In fact, it would run particularly well on POSIX, because POSIX really has its group more in the Systems 5 direction, going back to Bell Labs, more than it is through BSD. So one of the reasons we chose POSIX was we felt that it really has the best chances for accepting any UNIX application that you can compile.

FROM THE AUDIENCE: What about X support?

TUDOR: X. Someone did an X windows port, I don't think it was too robust, maybe more to prove a concept. There is no reason why someone can't do, in the tradition of saying the X server is commercially available for Macs, have an X server for BeOS, no problem at all.

As usual, there are issues of interaction between this X windowing system and how does it like wedge its way into the desktop, you know. But between the fact that you have got networking, you know, which is how X applications make contact with the server, with the X server, and the fact that you could go into full screen game kit mode and just throw the whole desktop out of your face, I would expect someone enterprising will do an X server, sure.

FROM THE AUDIENCE: There is at least one person who is implementing an X server from scratch rather than port via Adena sources, partly because the Adena sources are fundamentally single threaded.

TUDOR: Okay. But in the absence of multithread, you would nonetheless have a single- threaded X server, which if you do it right, of course it will run. I don't see any problem there at all. I see it as being a lot easier than on a Mac, where you don't have the multithreaded capabilities of BeOS. So, yes.

FROM THE AUDIENCE: Essentially the kind of the X calls (inaudible).

TUDOR: No, no. It would be BApp calls. I mean, the X server would eventually have to render the bits, but it could do that directly to the screen using a game kit, or, yes, it could do it the hard way and render the whole X desktop into, say, a BWindow. It could be done. Any more questions?

Okay. So just to summarize, then, future directions, future developments. I think our next release, since we just released 1 now, I don't think our next release is going to be for a while, it is really more of a marketing thing. I don't really even know what it is going to be called. We call it DR10 internally.

FROM THE AUDIENCE: 3.1.1. That's what we said yesterday.

TUDOR: However, as I said, POSIX is an ongoing thing. It's not a crutch that we're trying to wean you off of what horrible previous system you were using to the new GUI BeOS. I see the two as being equal partners. And the problems that we have right now with POSIX, incompatibilities, compiles that don't just compile but there is something wrong, header files are not in the right place, bugs, sure, all of those will be addressed, as well as issues of completeness, the fact that we don't have certain services that POSIX applications want. I see those as being done.

And just to enumerate them again, job control I think is going to happen. I'm probably going to be doing it. Term I/OS, completion of those kinds of services. One of the situations right now is if you do use hardware serial devices to plug in modems, or maybe you want to hook in a terminal or do a hard wire connect from one machine to another, that Term I/O service is not unified with the Term I/O service being used with terminal and with the network.

So it's a bit lumpy, but it's going to go away, and that's going to be cleaned up, and we're going to have like your standard UNIX style TTY layer in the kernel, high performance, full featured. Hopefully you won't encounter any serious problems with the hardware serial support at the moment.

ANSI terminals, some complaints in the past. Back in 8.3, people were saying this is not an ANSI terminal, it doesn't do these escape sequences. Again, I'm responsible for that. If you have any applications that don't seem to run, that don't act correctly, you can send mail, E-mail to rico@be.com, and we'll look into it.

The goal is to have a fully featured terminal emulator so that people can log in and out of the machine, and in case you didn't know, we have a term cap, so you can log into the machine and do all those kind of things involving terminal -- cursix based applications, where you dial into the BeBox, and when you go out of the BeBox, the same thing. And for that purpose you obviously want the terminal emulator, Terminal, to be fully featured, so that when you go to that remote system and say, I have a VT 200, everything looks right on the screen.

And finally, and this is not my job, but I'll say that Brad wants sockets to work as file descriptors. So that's part of everything relating to the select that we need to generalize, and the fact that sockets, which on proper UNIX systems are file descriptors, you say, "Well, what does that mean?", well, it means you can run other network applications, where you pass the file descriptor from parent to child, and that's how a lot of sophisticated UNIX programming is done, whether it's for a dial-in -- I mean network incoming services or including things like, you know, Apache or so on. Those kinds of applications want sophisticated network support. So that's something we're committed to doing also.

Nontrivial, but DR10. Yes.

FROM THE AUDIENCE: Will they support LPR?

TUDOR: I think that's a good idea. Yes. From the local end, if we don't have to run the printer, it's actually pretty easy. You just sort of poke in a network connection to some other machine and say, You guys print it. I see that as being essentially a trivial matter.

FROM THE AUDIENCE: The BeBook basically says that you should stay away from using port to spawn a thread. I know that SpawnThread is a POSIX call, but I sort of feel it is a low level mechanism that I sort of feel you should be able to mix them up in some manner.

TUDOR: The last lingering concern which I even had this morning was to say, oh, Fork, SpawnThread, POSIX apps, too scary, don't mix them, that there will be trouble with servers, MIDI servers, anything that you have a connection to will be complicated when you do a Fork or you have a SpawnThread and it tries to make contact with these servers in some surreptitious way.

The party line is we're going to make all of this work if it doesn't work already. Dominic seems pretty confident that you can do a Fork in a BApp and nothing bad will happen. The only caveat is that it is absolutely the case and no different from the server nature of, say, X windows on UNIX that if you have a connection to a server, again, UNIX, BeOS, it doesn't matter, and you Fork, then that child doesn't really have a legitimate connection to the server.

From the point of view of the kernel, it's like it's just a file descriptor, you can do whatever you want with it; but from the point of view of the politeness and correct operation of server communications, you could not do anything with that file descriptor, so you either should close it or you should exec off, which is often what programs at Fork do. They just basically want to exec off and become a different process, in which case that file descriptor, you could arrange to have it closed or something.

So does that answer your concern? You want to be able to do SpawnThread and Forks in any order at any time, and I think the answer is yes.

FROM THE AUDIENCE: Yes, basically.

TUDOR: But watch out for the server.

FROM THE AUDIENCE: The program that you have been exec'ing might want to split its calculations into two threads or something like that.

TUDOR: Right, so if you have a BApplication and you split yourself into two -- using Fork, is that what I presume, Fork or SpawnThread? Which was the call that you are interested in?

FROM THE AUDIENCE: Well, basically both ways, using like using SpawnThread after a Fork in, for example, the child process, but also the other way around. The other way around, of course, I think you would probably only get the one thread duplicated into the job, but....

TUDOR: Right. I think you can safely do those kinds of things, but bear in mind that however you got this new thread, either through a Fork or through a CreateThread, SpawnThread -- is it Spawn?

FROM THE AUDIENCE: It might be Create.

TUDOR: -- that that thread does not have the same kinds of -- you basically have to watch what it does, and not let it go off and interact with certain kits which will confuse the servers.

FROM THE AUDIENCE: Are you giving any thought to supporting the POSIX thread API?

TUDOR: Personally I'm not a big fan of POSIX threads. However, I think the answer is yes. So whoever is really excited about it at Be will be awarded the task. For those of you -- I mean, obviously if you write a POSIX application and use POSIX threads, then you remain a POSIX application and presumably fairly portable.

In the meantime, if you can't wait or you don't really care that much about POSIX portability, you could slip in all the thread calls that are available from the kernel, straight into your POSIX app, and everything should work, again, with the matter of cosmetic defects like printdef and so on.

My recommendation, it's the purist approach, is if you want multithreaded -- if you want to take advantage of multiple CPUs and yet be a POSIX application, do it the old-fashioned UNIX way, which is you have multiple POSIX applications, and you have your pipes; remember that feedback example running Calah, that's not a high bandwidth application, there are just a few moves that are moving between the two.

But, you know, you've got multiple megabytes of bandwidth. You can hook together multiple POSIX processes, using pipes and other plumbing methods, and get that parallelism, you know, and that is actually portable to all UNIX systems as well. It is even portable to UNIX systems that don't have POSIX threads, which is actually quite a lot of them.

Okay. Thanks for your time.

(Applause)

(End of session)

Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support