* AltiVec Overview *

Too early in the morning to take notes. Went over the features and functionality. Some discussion of what it will mean for the Mac platform. No firm dates or timelines, but both Metrowerks and Apple Project Builder will have AltiVec compilers ready in the next releases. Lots of sites to get AltiVec info. Nice vector architecture. It is going to provide a lot of horsepower for a lot of tasks. Apple will definitely take advantage of it throughout their application frameworks and core services if applicable.

* MacOS X BSD Support *

Good overview session by Fred. My notes might be a little terse. Continue to push this one picture of the core os as I try depicting below, probably warrants a picture but ...

Common Services ----------------------------------- Core OS | file system | skt layer | -- | - POSIX box & down | | ATalk | IP | | ---------------------------- | Mach 3.0 IOKit Driver ---------------------------- Hardware

Looks better live.

Ok, now BSD is also a full fledged Unix system. For the context of BSD for Apple, it is useful to divide BSD into a kernel level, a library level and a application environment. The BSD kernel type services are the file system, networking stack, POSIX, with Mach sitting underneath. Mach primarily provides the tasks/threads model, memory management, and the device driver layer. BSD libraries provide the system interface for user space processes (open/close/write,...). BSD application environment consists of the shell and related commands. Common services kind of mixes the needs of higher level API layers. Network, file and system tools/interfaces are provided at the common services abstraction layer.

System services offered to users. NetInfo, NTP, DNS/bind, mach_init/init, system starter, update and syslog are some of the system level services provided by the Darwin core OS. System Starter replaces the usually Unix boot process with a graphical scripted startup.

Some of the POSIX apps are apache, emacs, sendmail, perl, tcl, python, and samba.

BSD libraries are provided as a system framework library bundle. This optimizes given all of the calls are in the same lib. Clib, mathlib, POSIX/BSD system API, POSIX threads are provided in the library framework. Cthreads are not offered. Cthreads are the user space threads package for Mach. Mach will still have some notion of kernel threads, but these will be distinct from the Pthreads (POSIX threads) offered in MacOS X.

POSIX compliance is a goal, certification is not. They want to know if POSIX stuff does not work as expected since they want to make the BSD API a first class system in the MacOS X world (along with Cocoa and Carbon).

Issues porting from POSIX to MacOS X. There is no default X Windows implementation. This a nice big whole for third parties. Use -fno-common as a compiler flag for the linker. Use dyld from Mach-O and not dlopen() for dynamic loaded libraries.

Little bit of history. OpenStep was based on BSD 4.3. NeXT Argon moved NeXTStep to BSD 4.4 Lite. 4.4 Lite was the first BSD code base that was not dependent on any of AT&T System V Unix code. Leveraged the FreeBSD and OpenBSD movements for networking and filesystem stuff mainly. Standardizing on OpenBSD now with Darwin moves.

Server (vs. Client). The core OS is going to be the same across both products eventually. Primarily differences will be what is provided out of the box. Client will not have much. This will not preclude you from going out into the Unix GNU world and downloading a lot of robust utilities and Internet tools. Apple will be positioning Server product as offering a lot of these free packages well integrated behind GUIs. Filesharing capabilities. Different levels of administrative configuration and tuning possible. Apple will sell Server with a lot of nice tools to administer server tasks. Kind of like the current AppleShareIP model. It sits on top of 8.5 providing an integrated network admin environment. There are a lot of piecemeal solutions out there, but Apple is trying to provide a, integrated large package of server features.

* I/O Kit for MacOS X *

There are both application level (user space) and kernel level services to be provided by a IO framework. IOKit is primarily about defining device families for networking, storage and buses.

IO Kit will consist of a set of kernel extensions. It is a set of SDK families (SCSI, PCI, serial,...) that provide service libraries to develop drivers of that family. Design goals were to provide device interface that is object oriented, has protected memory space, multiple threads, preemptive scheduling, and SMP efficient. They are really worrying about how the OS will scale across multiple CPUs in the same system. Encouraging for the future.

IO Kit lineage. Derived from NeXT's Driver Kit. Driver Kit was the prototype for development. Added the IORegistry and the IOCatalog. Allows true plug and play, hot swapping, power management and application driver interfaces. Added some level of compatibility with NDRVs and other new technologies. Driver Kit was Objective C, moved to embedded C++ for IO Kit. Embedded C++ is a C++ subset specifically chosen by a group of vendors to provide a device driver safe language. Moving from Objective C made it more complicated since Obj-C had a lot of nice features in the runtime which had to be hacked in with C++. But given the Obj-c learning curve, the C++ route was taken to probably make device drivers a little longer to program than with Obj-c, but not have the language learning curve.

Kernel Extensions. Implementing a method to provide kernel plugins for the core OS. This would allow the addition of file system plugins, network implants, and IO Kit drivers and families. Want to allow the same flexibility as the system folder paradigm of managing extensions and device drivers. NeXT/MacOS X handles apps and drivers as special folders. Since UFS and other Unix FSs does not have a multiple file fork capability, NeXT used special folders that were treated differently by the OS. This allowed for resources to be stored inside this folder. Apple is currently working on the best ways of allowing users to install and uninstall drivers into the system. Providing drivers in an app package is one route. Providing files with type/creator KEXT will also be possible. In some cases, a single file will be needed to extend the kernel (can't rely on folder structure all of the time). Kernel Extension Manager will load and unload these device driver families on demand, that is the goal. Dynamic extensions will allow for a lot of flexibility in the OS space. Would like to even allow special app structure to contain device drivers that can be loaded for the duration of the app. Loadable families not quite there yet.

IO Kit Environment. OO families of devices, IOObject and IOService. Have to deal with memory, interrupts, threads, common classes, kernel extension manager. Hierarchy of where IO Kit fits:

1. Core Services -> File System -> HFS + or Networking ...
2. IO Kit -> Families -> Drivers
3. Kernel

Direct Drivers. Similar to Unix upper/lower implementation drivers. This model is very difficult for SMP systems so Apple has spent a lot of time figuring out a graceful way of handling this. IO Kit provides a hardware abstraction layer. Drivers are single threaded (minimizing a lot of synch problems), VM is easier and is open sourced. Some of the IO Kit families will be released before the fall DR2 cut. Do want developer feedback. Trying to provide an object oriented framework that makes it easier for everyone to develop drivers down low and even for application that might interact with device drivers.

* Project Builder and Interface Builder *

These kind of things have to be seen. They demoed a lot of the functionality in both the current shipping products and with future developer tool cuts. Apple Developer tool world looks like: Project Builder, Interface Builder, WebObjects Builder, EOModeler, FileMerge, Sampler, and MallocDebug. Some misc improvements in the next little while: source code importer, code view of debug panels and other dialogs, Carbon is being added, ECGS compiler will eventually replace the current gcc 2.7.x compiler, provide native debugging with gdb.c ProjectBuilder will provide the ability to pump out a XML version of the project format.

* ThinkFast! Performance! *

Discussed the Instrumentation SDK which I did not know existed. 4PM is another product mentioned. Performance is a key issue with a lot of shipping code. Process of gathering statistics with the Instrumentation SDK is: identify performance target, instrument code, target easy wins, redesign algorithm and micro-optimize. I have never used this or the profiler with Metrowerks. But profilers can provide a lot of statistical insight of where you app is spending its time. There are usually a lot of time suck things being performed which either are hidden by the program logic and discovered, or just areas needing additional programming focus for speed that will matter and offer good results. Use a profiler ... and I went on.

* Developer Tools for MacOS X *

Outlined the major changes for the developer tools over the next little while. Project Builder will be getting some nice new time saving features. Compiler ECGS will be used to generate PEF and MachO binary format code for MacOS 8 and MacOS X. Carbon environment will allow PEF on MacOS X as well. Graphical debugger and gdb are implemented. Kind of a similar setup to what Metrowerks demoed yesterday. Use the network interface to talk between the app and the debugger. Interface Builder is also seeing some nice user task stream lining features. Outlets and actions New NIB format will be XML. XML seems to be the big push. It has advantages over binary because it is human readable (somewhat) and it wills for better management of version control.

For the future, if someone is targeting app development completion some time in the next few months, focus on Classic. If development will be finishing towards the end of the year, target Carbon (might be pretty easy from a Classic app). If targeting next year some time, Cocoa would be the way to go. Apple is still not pushing how they are going to sell all of these things and when. Yellow Box on NT keeps coming up. Apple has not figured out the proper business model for managing this. I get the feeling the they are just losing momentum in a lot of developer shops which will instead of standardize on NT instead of developing an app which can be used in a lot of different OSes. They need to figure this out soon. WebObjects and Yellow Box are beginning to receive more media and customer attention. But Apple is still spending a lot of time communicating the Carbon strategy. But are valuable. But a lot of tools could be offered on NT and gain Apple marketshare given the power and flexibility of the ProjectBuilder/Interface Builder development environments.

>>>

One more day.

Eric