WWDC1997 Session 201

Transcript

Kind: captions Language: en [Music] good afternoon welcome to session number 201 rep C core OS kernel runtime my name is John signa I'm the rap C core OS evangelist and for the last I'd say five months the expressions been running through my mind has been may you live in interesting times because the last five months have definitely been interesting starting off with the January noun sment of the new OS structure and for that first month of the during January the question that came up frequently was luck colonel is Rhapsody going to use and it was a choice between the new kernel and the mach kernel and both as you know and the month came we made the decision we went with the mock turtle and ironically two months Orsini two weeks later was Macworld in tokyo and actually got my first experience with some hands-on experience with the mach kernel and to be honest it wasn't quite what I had expected it was a little bit difficult I'll just show you okay I did this so it just like Brett has nowhere to go but up but I'll go ahead and introduce Brett Hali who is the manager for the core OS kernel group and the tech lead for the PowerPC bring up and he'll actually talk about the real not Colonel Brett okay we can all grown now so imagine by now you've all seen this particular architecture diagram should be getting pretty familiar with it by now and just for a quick review that for those of you who slept in this morning or something a couple of key components that are here as a part of Rhapsody certainly the focus of this particular session will be on the chorus you're here but other very key core parts of of the technology of the blue box which only runs on Rhapsody and only runs on the PowerPC and the yellow box which is the truly portable environment for writing applications as we move forward it's important to note that in this particular Pete's picture everything in this picture except for the blue box has to run and on the various platform for the deliver to specifically PowerPC and Intel beyond that the focus really is here - - as we get into the core OS and down into the various details of the kernel and such that you really aren't going to be programming to anything but the yellow box api's will try and give you some of the overview of the technology that's in the chorus but the vast majority of the people here will be focusing in the yellow box and you'll find that the services in the yellow box are very very rich all the way down to abstractions for if you will kernel level services and there's a specifically a session on the foundation kit which you should go to later in we could give you a little bit more insight to that as we focus now on the car s is really a fit of key components that make up this part of the system of course it's really provides the foundation and infrastructure for the yellow box and the blue box our charter here is really to provide the best possible performance in hardware integration for Rhapsody it's our job to support take full advantage of great Apple hardware innovations and other innovations that are developed by yourselves so that they all integrate well into the system and provide up through from the bottom all the way up to the user experience a very smooth and apple experience as part of that it means that we have to support quite a lot of Technology in the core RS being able to enable clone vendors and plug and play technology and seamless hardware integration being able to support across PowerPC and Intel platforms being able to deal with processor advances like ongoing PowerPC developments like Arthur or opinion - another key area that impacts the core OS is in symmetric multiprocessing and really it's in this space where we have to do all our work to make the other yellow box perform well and in this space and of course things such as firewire and new i/o are all driven from the Kouros perspective I'm going to focus specifically on the Mach microkernel the BSD space and the runtime and we'll get hornbill into detail event in a moment but it should be noted that there are other very very important components in the core us such as the file systems which immediately follow this one and encourage you to go there to get information and details about what we're doing the file systems IO which is an obviously another very critical component of the chorus and networking so let's focus now really on the kernel on on Mach specifically so it's important to note some of the history of my should be noted that that mark was originally developed at CMU in the mid 80s by a number of graduate students including our fearless leader RV - the game development of Mark continued through early 90s at CMU and have development has continued since that point in areas such as university of utah the open Software Foundation Research Institute it's been integrated into a number of different products things like a lot from OSF one the canoe heard and of course next step Marc's been ported to virtually every processor architecture and was designed from day one to DNP that's what one of the key goals of Maude's some of the other key features that make up the kernel of course for things like tasking in across the communication virtual memory multiprocessor architecture that's all all that we'll get into in a moment but it should be noted that since I won't be able to cover everything that you're going to want to know about the microkernel that there are other places that you can get information there's a good book that's out there called programming under mark there's numerous sources on the net that you can get access to information such as news groups comp OS mark the mark project at CMU has a lot of online documentation the Research Institute OSF resource Institute and even available here is things like frumenty Linux which is also based on mark so to start with we get into in the kernel when they're the key if you will basis of application development it's you gotta have a task or something in which to put a program in and the task is a an entity which is responsible for managing the resources for an application space things like the memory virtual memory space that's available and other resources within the test in addition to the tasks there's at least one thread that's associated with the task which is where your actual program run and as we talk about that later and get into where BSD or the UNIX component fits in these team together with some additional state and information really comprise the concept of a process threads are a scheduling entity that's used by mark so they end up holding certainly the register state and other thing that's actually scheduled on for a given given program if a task can have more than one thread in fact they can have any number of threads and part of the mock architecture allows each of the threads to be to be managed independently so that they're done per schedule preemptively and if you end up being in a multiprocessor situation threads can be on independent processes obviously a single task in the system is kind of boring so being able to run multiple tasks and things become very critical and one thing that's very different from the standard Mac way of writing an application is that you will end up modularizing your system your application in a kind of a different model than you have in the past specifically allowing it to be multi-threaded is one important area but also breaking things up so that they're in multiple processes that you have if you will what things that might be done today in a faceless background app will actually be done as a background process and you may actually wish to factor your application in such a way that it's broken into multiple processes such that it can be used in conjunction with like web objects or some other entity from the web where the UI is presented in a separate way so another and probably the most important thing that MOC provides us is an inter process communication model everything that the task does out from in order to communicate to the outside world outside of the program is done through a mock IPC now again as I mentioned before you really should be programming to the higher level of interfaces the foundation layer which will shield you from the specific details of how this is done but this is a service of panel very specifically by the microkernel and it serves a very very important purpose the communication to and from a given task is done through through IPC and that a through a mechanism called a port there may be any number of ports that exist for a given process and the ports are actually shared amongst threads you can delegate all the communication responsibilities to a given thread within an application or or you can delegate to any of the threads that's done as part of your design but the communication to and from the kernel and to and from other applications are done through this mechanism of our IPC now in order to be able to make that work because ports are not global entities were actually not externally visible from the path it's necessary to establish through a well-known third party a mechanism for being able to communicate from task one to test two and it's done by the means of the kernel again by and another third third-party entity which in the case of Rhapsody as things like the nm server to name server it sits in the background allows you to talk to well well-known servers or allow you to register ports and service and so that they can be used by applications to be able to enable this communication because the concept of report is actually specifically protected import have what are known as port rights the ability to determine whether or not you can send or receive on a given port if you actually have to pass the ability to receive a request off to another task so that a communication can occur in this particular case task one would like to be able to talk to task two but needs to be able to establish that communication path through the port's to be able to do that what's interesting about the way Mach is designed and because everything is done through this mechanism of might be of IPC is that it's not necessary that these two taps have to be on the same processor or on the same system for that matter but the mechanisms intended to be abstract so that it's possible to move towards a more distributed type of environment from the perspective of memory management not going to go into the basics of VM 101 if you will there's really a couple of key services that that exist for Marco specifically it should be noted that the vm system is designed to be to work in if you will a very lazy or on-demand manner so that when you request large quantities of memory for example in the demo that you saw this morning with the mac the blue box running where the teach techs have huge memory requirements this when you actually request the vm ofor for market isn't allocated on the disk or even allocated all at once it's actually allocated on demand so you don't have to have for example like you do now and in Mac OS some huge file that sits out there just to make sure that you can do the M it's actually as needed and as a result applications can actually allocate large VM areas and use them as they need or as another kind of model of use which we'll talk about when we get into some of the basic runtime and use with shared libraries where a file is actually mapped into memory and it's actually loaded in backing store created when it's actually used the other aspect of the VM system is that unlike for example aux or even the Lin for example you don't have to have a separate partition for the backing store its allocated if you will dynamically on the existing filesystem space another very important aspect of the vm system and is very very critical to establishing the performance of the system and something that use very heavily through throughout the open step environment in yellow is copy-on-write and this is the ability to pass information from one task to another and then to be able to share the actual data in memory and only make a copy of it when it's actually written to or modified for those of you familiar with UNIX 101 when you do a fork typically the process that's created has to have an exact duplicate of the process the parent process and that can be very expensive it takes a lot of time to do that and it takes a lot of resources to do that with mark when you fork another process the VM space is duplicated in the system but it isn't actually you will commit it until the pages that are that need to be modified are actually modified the next layer if you will the system is the BSD Aero POSIX layer and this really provides the personality api's and services for the system it's important to note that marketing of itself is actually not terribly interesting it provides DN services and the IPC services and in processor scheduling and those kinds of things but that in and of itself isn't enough to be able to write applications you actually need to be able to get to a file system and to networking and to be able to have other core infrastructure in order to make the useful environment to do anything and this particular part of the system is responsible for exporting up those key services in addition it's responsible for providing the infrastructure for the security policy of the system and this is yet another new area that is very different from the interest Mac OS there is the concept of multiple users in security in the system there is file protection and as they go into the pall systems discussion will be some made some some more data on this but they certainly built into the the base of the system is the concept of security it doesn't mean that where you go through this process of having B level really heavy stuff but it is an important notion that does exist in the system and it's coupled with the memory protection mechanisms are there provides a much more secure environment for applications to exist so in the BSD space again this is something where there's huge quantities of information available and so just this kind of as a reference the things to look at extra daily if you want to go out and get more details on BSD our unix bsd there's also numerous sites on the internet for open BSD free SB net BSD there's also a very good book that's out designing implementation of the four point four BSD operating system and I'll mention is the by the way Bertrand when he drew his picture earlier about how the system is layered indicated it over time will actually look at upgrading or replacing some of those layers and this is an example of a place where through the process of creating rhapsody where where i've actually done that the next the thing that you've got in your attack up this morning the current next step for 4.1 4.2 our base systems are based on bsd for three rhapsody is based on bsd for four so it's a little more modern version of the UNIX environment more POSIX compliant if you will so at this point what I'd like to do is go and actually show a little bit about how the system actually operates and to give you a little bit an idea about how how it is we've been bringing up the system so you got here okay so over on this side right your last I guess we've got the current PowerPC Rhapsody in it's a console mode if you will that we use for as part of the bring up process and on the other side we actually have a version of Intel next step with the yellow box UI of the changes that you think you've seen so far the first thing I want to show you is that here we have a UNIX command line is met exciting and someone earlier mentioned that the yellows command was going to be a replacement for the finder and that's that's a vicious rumor it isn't true so let's do this so what I'm actually going to do is helmut into this this other system over here a Rhapsody box and one thing you'll notice we have messages from the console are actually showing up here that I noting that I happen to go to super user status and I'm going to actually now start up the blue box from here and this one really is intended to give you an idea that one the blue box thing is real we've actually got this up and running and that there are other things going on in the system such as networking and such the demo gods be willing there we go so blue box is coming up now which is all a really really quite interesting but Edition that I can actually continue do things like seeing what it is that's running on the system and that blue is actually just a UNIX process the sum number of threads that are used implemented it's just another application on the system it should give you some idea also that we have things like networking in fact actually activating in conjunction with this and trying to do something a little more exciting oh boy then all this there doesn't just work and that we do have pre-emptive activity going on while blue is running blew within it space is certainly cooperative and if you go through the sessions later this week they'll talk to you more about how all this interaction and stuff works but indeed there is a real system there and lots of other things are running the other thing that should be mentioned here is kind of a little bit about the process we took to bring up the system we actually need something a little bit different from traditional Mac phones in terms of going to network first so they actually brought the system up over the net the system actually boots off of an NFS server and we use that as of how we brought the system up we're adding additional services for discs and things like that or move along the other thing to note is I talked about the BSD and the POSIX and mock space is that in this particular example you see that there isn't any direct dependency in blue for the yellow box and that most of the services necessary any of the system are built on just that core infrastructure but that's where a lot of the real guts of the system work now I don't want to mislead you hanging as we move forward there's there will be become a significant interaction with with yellow box in terms of integrated user experience but just so that you know from a perspective of kind of what's there in the system that just the services that are the part of the BSD POSIX Basin and mock are really the critical part of getting the applications running another thing I'll mention is that the mock IPC as I mentioned is there really the core way that the kernel and tasks and other tasks that communicate with each other and one important communication that occurs between mock and process is even being able to deal with things like exceptions so that it is possible for example to be able to create a debugging environment where debugger can grab exceptions for a given application and be able to process them and be able to deal with things like breakpoints at stuff exception handling is handled for any type of failure condition anything from floating point to break points or things of that nature and after one kind of one of the low-level services for example that the blue box deals with in terms of being able to to deal with you know some emulation of the low level abstractions of the system through exception handling and IPC Bacchus lives so we get into some of the the runtime issues one of the things that's a certainly very interesting about the runtime that exists here one that should note is it's not CFM it's not talk based the runtime has been driven from kind of a long history of next development of having to support multiple processor architectures as a result the focus has been not on trying to drive - which is typically done focused only on a given process architecture for your runtime to be able to support a broad range of issues and therefore we're kind of raising the level of the issues that have to be dealt with focusing obviously on position independent code dynamic shared libraries dynamic binding issues things of that nature the other part of the runtime issue here though is that the way it integrates in the mock and to be able to provide a really effective and efficient environment for an application that the dynamic shared libraries for example are dealt with by taking advantage of en map files multiple processes multiple applications actually share the shared library space in the code against the multiple processes the other piece that comes with that is and this is really the real heart of the benefit of the runtime environment is is the object runtime this is really what makes yellow box and all the frameworks an object in space really sing well together a typical C++ type of object application tends to be bound up all at application build time or you have to create special api's and mechanisms to be able to love plugins or deal with things or there's certainly use of something like foam which is yet another mod for doing sudo late down binding of applications the object one time within Rhapsody however is much more late bound than conventional in the sense that it's totally again lazy evaluated it's everything is done as needed basis so when the application is loaded into memory it isn't all bound at that time but it's bound as needed shared libraries to for example that already exist in memory are bound fairly quickly and those libraries that exist on disk are bound in is needed and there's a built in concept and mechanism of plug-in since called bundles which allow applications to be able at any time in the lifecycle of an application to be able to load in new functionality if you will subclass a subclass from various objects and things within the application there's an enormous amount of information that that going to follow this and I encourage you to go to session 4:15 and get more about it this is really one of the kind of very neat features if you will of Rhapsody and this coupled with using shared libraries and modularizing application out into threads and multiple processes it's kind of a lot changes though kind of the landscape of how applications are developed in a very positive way the other thing to note about the runtime is that this couples with the copy-on-write features that I mentioned before within the VM system so you have an awful lot more reuse in the system but there's also an awful lot more sharing that's going on in terms of the actual resources of the system and that they're only consume more physical resources when they're needed so in that that means not only sharing of code but sharing of data within the system and that as long as you're just reading the data as it comes that's being shared and there's no additional resources at all that it consumed it's only when you write to them or modify them and that applications and the tools that exist are designed to bring order the data within we'll give an application in such a way to reduce the amount of duplication memory duplication is necessary the other important aspect of the runtime is kind of how things are packaged up so it's not pests containers these are for Rhapsody the focus here is around a runtime of disk format called mock Oh me it's not an awful lot behind mark oh that's really interesting in terms of going into specific details but one thing that is worth noting is that it is designed to be able to package multiple processor architectures within one container so it's possible for example to write an application or a Munich's tool or any other thing that can be kept on the server and is that much like an existing PowerPC 68k application is now on Rhapsody you can do that will be able to do the same thing for Intel and PowerPC based applications and tools so the given you will package can contain either and again just like you can with today's fad binaries that exist for Mac OS you can strip the binary to be specific to the given run running platform should you wish to make the reduce the file size so kind of take what we've gone through so far and indicate that really in the chorus base from the standpoint of the kernel and standpoint of the BSD environment from the standpoint of the runtime most of this stuff the details of a and the api's are really not anything that you're going to be using 99% of you will use the foundation framework and other parts of the yellow box and it's important to try and focus as best you can and stay within that space as it's in that area that we get for your portability applications that are written to the foundation or port to Intel the PowerPC to anywhere that yellow runs including NT Windows 95 and Mac OS certainly there going to be situations where you really want to tune an application to a given platform but as much as possible your application should be written to take advantage of the foundation so that you get that portability the other important facility that mechanism that exists in there is being able to be thread safe so if you write applications to the raw for example mock services it's all up to you to make sure that you've got a thread safe pile of code and that can be very very difficult to do certainly you can go one level up into the UNIX layer and take advantage of something like C threads and there are additional services that that help you but then there are concerns about which libraries might be thread safe or which libraries aren't if you focus within the foundation and within yellow box the boundaries of thread safe usage are very well-defined for those people who need to be able to write UNIX demons who can't wait to get the latest units viddy got to have the latest version of Emacs for some reason you want to write command-line tools or other development tools that might be valuable certainly the focus for you then will be able to write to the POSIX of BSD for for API there's certainly lots of free software that's out there lots of things that are available on the net certainly you can get things like Apache or any of those kinds of things and those if those are the kinds of apps that you want to have and targeting background daemons for example then this is the API second when you use it's really only for the debugger developers people are writing monitoring tools [Music] those people who just absolutely have got to have control over the VM environment to a very high degree of control that need to write to the Mach AP is really your focus should be as high up through the system as you can preferably in the yellow box if you can at the level of mark get to some of those key features obviously though you lose some of the portability capability but forget to be highly tuned to a given platform that may be the valuable thing for you to do so I've one more demo if you will and it's mainly to kind of take all this and wrap it up into behind the scenes perspective of what's there so this is the the demo of the stone designs create product that was ported at the end of last week in a matter of hours to the PowerPC Rhapsody it was shown that Bert Ron's presentation earlier I want to give you a sense of what's really here behind this application what's really running and they give you a little better sense of where the system is at if you lo at this particular stage as I mentioned earlier we're actually bringing the system up over the network so we're running in a networked environment and if NFS mounted if you will but even with that I can still actually we have full file system access and this is all very transparent as far as the application and users concerned there's a number of background services that are actually running at this point certainly things like networking and such as I had shown in me when I do is did the PS and the other demo there's a number of different processes that are actually executing at the same time and there may be for example NSS or nm server which is responsible for some of the name service negotiation within the actual yellow box itself it also has a number of services that are there that exist in the background for example the ability to do things like cut and paste a more handled through a server pasteboard server which allows you its deals are they going between multiple processes if you will it arbitrates the pasteboard or the clipboard there are other servers as well that deal with drag-and-drop and those kinds of things and it's not really so important as to what they are but the way that the system's architected is a little different than the Mac OS in the perspective that there are lots of processes that are running and that the way things tend to be factored out really take advantage of the multi thread multi-threaded nature of the system the fact that there are multiple protected editor spaces the fact that you can communicate between different tasks to get your job done and there's benefit in breaking out a given application and potentially given on this given the particular need that you might have to have a server that's responsible background server that's responsible for managing a particular service for example one of the things I've seen one of the apps that we saw ways they have a license server runs in the background or they might be a background compute server which might be done either on a different name images you just do it as a separate thread or again you want to provide a compute engine that can be used for some particular reason for a web interface so that you can come make a common set of services in your system that are broken out modular between your actual application background services and such and net access other things that that come into play here is that we actually have multiple applications running where in this particular case we actually have three things we have a terminal window so that if you just absolutely have got to get to the command line it's there and TextEdit and this create program so there's these are multiple separate processes and there's communication or whether this communication that occurs like I said through the use of like the pasteboard server to copy things back and forth between these different you know process of doing this particular operation involved a number of different processes and services in addition these the multiple applications through shared libraries can actually share code to be honest in the current system for demo purposes we haven't bound the system up these shared libraries enabled yet but in a typical configuration or in existing systems all the libraries that are part of the frameworks and software actually shared between the multiple applications so all the document management all a lot of the things like a fonts color panels those kinds of things are actually shared objects and entities that are used between the multiple applications and processes and that takes advantage of all the services that we talked about before so I need to close up this part part of it if we're going to provide some time for doing a lot of question and answers that when I go back over a little bit of a timeline here that virtue I mentioned this morning you know as we actually started this process supporting to the PowerPC in the in early February and is kind of a curve of activity that's actually pretty interesting as we are bringing up the system and then as soon as we got to the UNIX if you will command line that many many things were able to be brought up in parallel and it's very much because of the layered nature of the system that the fact that there is a lot of portability of the code that most of the things like the commands and the application and frameworks and such once we got to a base level of functionality those things came over fairly painlessly and as even demonstrated by the ability of the third-party apps that we've seen it's just literally a matter of recount so I think you may have noted that in the timeline that there was quite an amount of acceleration that occurred in the development process and that really attributes itself to the way the system is layered and then I focus very much in the platform space is limited to the items that I talked about this morning that you know the bulk of the the platform dependencies the CPU descent dependencies are limited to the kernel to the BSD layer on into the runtime environment so one thing that else that should be taken from this is that there is a lot of other services that are part of the system that we interact with and I didn't get a chance to go into today things like the file systems in i/o and the run more detailed object runtime and I encourage you very much to go to the other sessions to get some of that information and on that note I'm going to complete here and we'll actually be able to take some questions and stuff thank you [Applause] Thank You Brett while we're waiting for the panelists to come up turns over to like to point out some additional sessions coming up we have following this session at six ten in this Hall we have raps key core OS the file system on Thursday at 8:30 a.m. in room a one we have understanding raps key drivers Friday 5:50 we have raps network api's and services I point these sessions out right now before you go up to answer or to ask questions please keep in mind these sessions are there that if you have a file system question or driver or networking related questions it's best to hold off on those until the appropriate sessions because we'll probably a lot of cases will answer your questions in the presentations there in addition there's some additional programming sessions that are related on common object model Roxy runtime and into the open staff foundation framework both those sessions are repeated and finally on Thursday 11:10 room j4 will have a core OS feedback forum in addition if you're unable to attend that forum and you have some feedback for us you can use the rap C - dev - feedback at Apple comm email address we do read that we do forward it on so with that I'd like to go ahead and open the floor to QA please when you as I believe two microphones please before you ask you a question state your name company and your question and before we do so why don't you go ahead and introduce each of you cells our analysis I'm Winston Hendrickson I'm the director of Rhapsody Corollas Eric version chorus Colonel Jeff Glasson manager of the BSD part of the kernel Kevin Enderby compiled a grunt back and forth okay when we just go ahead and we'll just start up in the front here on the right your lives University of Illinois what kind of excuse ability would you have been Rhapsody released for running multiple blue boxes and also the user interface for putting the blue box in a background and or switching between multiple blue boxes actually I think so actually for a lot of the details about the blue box is probably best handled in efficient but certainly some of the the core technology there enables multiple processes there's a much more complicated issue of the user interface interaction issues with Rhapsody and I think they're probably best suited to answer the how the unit how you would use the interface in that manner okay when we move to the far right Marshall Aladdin systems this morning during one of the keynotes people were one of the speaker's was talking about two versions of reps the a client version a server version what are the changes in the core OS and the kernel to support a server version whatever really are the differences here so in terms of the server product I believe there's a server session during this week probably go into some more detail but but but I'm not going to totally cheese out there the main differences that have been discussed so far around the area of say on file system volume formats that are available and supported on things like dynamic tuning remote administration so on and so forth I don't know Conrad if I if I got all the ones there but it's going to be things of that nature on certainly you could say well some of those could end up going in the desktop product and perhaps they will over time but the server product will having needs around specific file system features or features for administration and so on and so forth that may not be necessary in the desktop product Thanks when we move to I guess it's our Center Jonathan Oil Eastman Kodak just a question with regard to the yellow box running on other systems like Mac OS and Wintel since they're not going to be writing on top of the mach kernel as Rhapsody would be it is is the kernel somehow emulated for the foundation layer or what would how do you handle the cases where you've got open step API riding on top of a non pre-emptive environment so the foundation framework is actually responsible for dealing with that level of abstraction visit all the core chorus services things like file systems thread management and all that is done through the foundation and it has to do obviously some emulation if you will of certain kinds of services such as if you will are now with this things to the mock IPC being able to pass is a communication back and forth between multiple processes an implementation on wind 95 for example is going to be if you will less robust or is not as nice of an implementation as it exists on Rhapsody because of the level of negation of services but the foundation instructs that from the application yeah because it seems to me that if the foundation assumes pre-emptive 'ti or make certain assumptions about the OS that's not that it's not there there'd have to be some kind of emulation and then there would be obviously performance differences between how it would run on a true Rhapsody either PowerPC or Intel than it would writing on top of 95 or mac OS so this morning in Berlin session was early this afternoon he actually talked about the fact that we're still wrestling with the issue of thread handling pre-emptive thread issues on terms of Mac OS and we don't really have the answers quite yet as to how we're going to address that issue that's currently being handled on Windows 95 and certainly an mt through layers of emulation just do you know any of the details yeah we Windows 95 actually is multi-threaded so the the main the main way things are dealt with at the lowest level is we've got a wrapper emulation package that kind of emulates the mock IDC API is that foundation can actually call out it's very lightweight on Windows 95 it actually uses some mail slots so if you're familiar with the win32 code so it's very lightweight thanks let's go back to the far left idea Bob Wells allele with respect to the merge between the objective-c runtime and the Java VM how will Java garbage collection work the Java VM garbage collection is handled completely inside the Java package so check to see does not have its own garbage collector as part of a language it does have an auto release mechanism and they are completely separate so you know it was it was quite well so front-left mountain hill couldn't university west australia just wondering regarding the command-line interface what sort of access to allowing for end users and do anticipate a lot of unix utilities and like being ported over just as a straight till up with CLI interfaces without much of a a mac user experience on top well the full berkeley for for bsd set of utilities will be provided it's not going to be encouraged for normal mac user but if you're used to a UNIX environment by all means you can use it and you think the slam that have negative effects as far as a mac experiences concerned I think we've we've done pretty well hiding hiding the UNIX thing and Fortran talked about this morning and if you've ever if you've seen next step or the Rhapsody yellow box implementations there's GUI to do basically everything from system administration to browsing the file system to formatting disks it's all hidden you never have to see a shell prompt let's go to the front Chris wolf from following information systems and wolf where I add too short but unrelated questions which version of the Mont kernel serves as the basis for the rack to the implementation and did you resolve the issue in any of these external layers about the infamous non-sweet non-drinking spot pile bug in next step okay the the kernel is based off the open step kernel least amok kernel so it's basically two five with a lot of other stuff in it there's some 300 isms in there that's what's going to be going out with the developer release there's still some issues it's not necessarily what's going to go out with premiere we're still making some decisions on on that the non shrinking stockpile bug has not been fixed yet to my knowledge but I certainly want to fix it we might mix it to we'll take that as feedback okay let's take the far right theater of Cho from Massachusetts Institute of Technology with regards to the BSC for for environment how much of being about how much of the development environment will be shipped in terms of C compilers the standard libraries that you might expect on a BSD four for system etc well as I said before all of the standard BSD like section two and three calls will be there for your UNIX weenies out there we're going to ship take a new compiler environment so GCC all everything that's part of BSD will be there curses term cap again are oh yeah okay back Center Metro Lobell multi-node Microsystems and parallel processing connection you mentioned I think that the that the mach kernel using pieces of three to five and three oh is that correct yes and I'm wondering is can how much of the API then the maka API can we depend on how much has been modified how much is still available if we really want to write to it well just kind of the obvious caveat and that you know for portability reasons that that's certainly not encouraged but at this particular point the api's that are exposed I think are actually fairly well documented and will be documented and there are two five plus a number of additional API so at this particular stage there isn't a full 300 API set or two part but two five is intact plus if it's of additionals yes here with the only exception that I'm aware of is that the VM system is not completely to five component it's very close but it isn't doesn't exact API mentions it's very documentation to tell us what you you know what's available what's changed yeah there is documentation that's been available I'm not sure the current state of those dots and know that we will be documenting the system so thanks thank you okay far left the chels applause you hey next time user group during the presentation you kept saying using the term microkernel when describing the Mac could you clarify that because you just said a minute ago two point five I put as a monolithic kernel so it isn't three Oh in a sense of a truly isolated microkernel where the server if you will the bsd environment is server eyes din user process or in the case of the OSF our eyes server colocation so it isn't a microkernel in that particular inspector it is architectural II from the standpoint of how its implemented in the system so it's a four semantic clarity yes you're right it's not you will a true isolated microphone it's isn't likely then in the future that you'll be moving over to proper my to pedal muscle even using MK Linux well so I think we're we're evaluating over time which of the technologies from the 300 and the MK based it's used for example for any Linux or really from the OSF Research Institute and other sources are appropriate for Rhapsody so I think Burke I made it pretty clear that we over time will evolve the system is appropriate to be able to meet the needs of our developers and hardware platforms and other things that we're delivering to and we obviously have some experience with that code base of 300 and such in certainly some technology for example part of the IPC system itself has been pulled on through from 300 and will continue to take more technology as appropriate the reason I mentioned the MK limits is because I heard of announcement recently that HP a now negative ported on K Linux for the a risk that's true they have followed our lead on it ok thanks ok front left please yeah john wallis power on software there's obviously a big wall between the yellow box and the blue box most notably the blue box seems to be a second-class citizen running inside of the yellow block yellow box meaning that all my Mac apps on the current system are running separate from my yellow apps is there any community mechanism where on there will be a unified yellow app on top of blue app on top of yellow app on top of blue app in the in the ratcheting system for our we have to live with the unacceptable situation of our current Mac OS being a second-class citizen so in terms of the human interface in the integration between the yellow and the blue box the current plan calls for being able to have two modes one which is the blue box taking over the full screen another is the blue box within a window certainly over time as with all things we're going to investigate you know any types of improved integration that you know our user studies and so on and so forth dictator the appropriate thing to do but it means that nothing in the beginning not at this point now the other piece of this is that I don't think the the blue box is actually a second-class citizen and actually what we've been finding just with the bring up of the blue box so so far is that it it runs in the environment with quite a lot of efficiency and that the users experience I think is the issue that it's a question if in a system level that is of the case in one other one of the things sort of this tag-team question answer on the the user experience group has certain concerns about some of the subtle differences between things you can do in a blue application and things you could do in a yellow application and there's some concern with having a high integration between the two that there might be subtle confusions that get bestowed upon the user that could end up being more harmful than good and so it's an issue we want to investigate over time but that's really where the concern stems from I recommend attending the blue box Mac OS compatibility session tomorrow let's talk actually well confuse me you what shows you what happened when you walk up to an empty mic you said something in the last answer that actually Peaks my feet the concern of mine you said that you can run the blue box at the fullscreen I only have one Macintosh that has only one screen and that's my power book to me full screen means all monitors different depths as many as I can many video cards as I can cram into my 9500 I just want to verify that you meant the same thing fullscreen means all screen yes thank you this is probably the last question since we're running out of time here so up in the front IBM microelectronics had a question as a developer running yellow box applications on a mock kernel is it possible to access the processor instructions specifically MMX type instructions yes absolutely compatibility or your cross-platform capabilities there well sure when you I mean when you dip down in take advantage of a specific platform then you've got to conditional eyes that out either in runtime or in compile time okay there's something but there's nothing specifically keeping you from going through the kernel firm no in addition some of the key libraries that you're probably will be interested to take advantage of MMX such as technology or for example a QuickTime or quick-draw 3d or any of those things obviously those libels libraries will already be built for to take advantage of those particular things on the given platform okay on that question we're out of time I'd like to thank you for attending and again remember the file system session is in the same Hall following in about 20 minutes and the other sessions related Iowa drivers on Thursday and files or assuming young networking on Friday thank you [Music] internal rain