WWDC2001 Session 131

Transcript

Kind: captions Language: en hello and welcome to session 131 my job as carbon technology manager is to help you bring your application to Mac OS 10 but of course it is critically important to continue to support your customers who are running Mac OS 8 and 9 and that's what we're here to talk about today so what is Carbon lib I'm going to start by defining carbon as the set of api's that you can use to write well I should stack up excuse me o defined it as the set of API is derived from classic Mac OS that you can use to write native Mac OS 10 programs Carbon lived then is a system extension that implements the subset of those api's that are available on Mac OS 8 and 9 and I say subset because although Carbon is derived from classic Mac OS all current and future development of Carbon api's is targeted at Mac OS 10 so where it's feasible and where it makes sense we will continue to bring back some of those api's and make them run on Mac OS 9 or 8.6 but it's important to understand that our primary goal is to give you the api's you need to write killer apps for Mac OS 10 that fully exploit that platform so it's not always possible for us to go back and re-engineer Mac OS 10th style ap is on top of Mac OS 8 or 9 so why did we do carbon that then simply to allow you to develop for Mac OS 10 while continuing to support your customers who are going to wait a little bit longer to upgrade the greatest thing about carbon is that it provides a single source solution the same code can be compiled and run on Mac OS 8 9 or 10 of course you need to condition condition Eliza and test for API availability at runtime as you always have because not all of these api's are available on every single OS that carbon supports we'll get into that a little bit later and the second great thing about carbon is that it can provide a single binary solution because we continue to support the code fragment manager and CFM executables there are other alternatives as well including ma CO and we'll talk a little bit about that later but rest assured the same binaries that you create today for Mac OS 8 or 9 will continue to work on Mac OS 10 once they're carbonized that is and this diagram simply illustrates what is the beauty of carbon that your application compiled as carbon app will run on Mac OS 8 or 9 calling into carbon lib and on Mac OS 10 calling it to the carbon framework and other frameworks available on Mac OS 10 there are two versions of carbon lab currently available for download from Apple's SDK web page Carbon live 104 and Carbon live 131 y2 versions because carbon live 104 is intended for use only on Mac OS 8.1 it provides the basic set of Carbon api's that you can use to run on Mac OS 8 1 through Mac OS 10 these corresponds the api's you'll find in the universal interfaces version 3 3 2 and with this set of api's you can create a good carbon app that will run on all these platforms but with carbon level 131 which is the current GM release you provide your have available to you a much broader set of api's the more closely match what you'll find on Mac OS 10 and I'm going to talk a bit about this later but the important thing to note is that with carbon Live 131 you must target Mac OS 8 6 and later because many of these well all of these newer api's cannot be brought back to Mac OS 8.1 an interesting thing about carbon of 131 is that it's self localizing it supports all the languages you see listed here what this means to you is that you don't need to carry around within your installer different versions of Carbon live for these regions it's when your carbon app is launched Carbon they will examine your vers resource look for the locale and localize accordingly there's not much that needs to be localized the title of the window menu and some error strings and print dialog types of things none of this was necessary in carbon of 104 so that version doesn't need to be localized at all there will be more locales supported in future revision of carbon which we'll get to later so to summarize this is the version of karbala that we recommend you target unless you absolutely need to support Mac OS 8.1 so I mentioned that you can license Carbon lib there's no fee for this it's similar to QuickTime or many of the other technologies that you've probably already licensed from Apple at one point or another you simply fill out the usual software distribution agreement and then there's a one-page Carbon lib addendum the license does include Apple help 163 that's for you to install on Mac OS 8.6 because the app will help viewer app did not start shipping until Mac OS 9 but by moving your help into the Apple help HTML format you can deliver your HTML help content across all these carbon supported platforms and we recommend that you do that and the carbon lib 104 license includes nav services 101 which we want you to install if you install carbon live on a 8.1 system because it fixes some bugs in the in version 1.0 of nav services so this series of slides coming up here will be familiar to those of you who attended scott forestalls frameworks overview session but I want to highlight a few things so carbonate 1.04 does support development from mac OS 8.1 to mac OS 10 we began with all of the carbon compatible api's that already existed in Mac OS 8.1 and then we added the toolbox access or functions or opaque toolbox data structures control window and menu properties nav services 1o a set of core foundation functionality and the first version of the carbon printing manager this is a solid set of api's you can definitely write very good programs targeting this carbon they want to force that but when you step up to carbon with 131 running on eight six or later a whole slew of new API is become available to you and using these api's you can deliver a much better user experience to your customers first and foremost the Carbon Event Manager this represents the new event model for carbon applications we strongly encourage you to adopt the carbon events they will make it easier to write your Carbon applications and also can dramatically improve performance especially on Mac OS 10 another one I'd like to highlight is the IB Carbon runtime this is what allows you to use interface builders nib files on Mac OS 8 and 9 interface builder is a as you've probably seen in previous demos here at the show a much easier way to design your user interface and now with the IB carbon runtime you can use those nib files in your carbon Live applications when you're running on Mac OS 9 or later that brings in some new API is that were added in Mac OS 9 most importantly the HFS+ ap is for improved file management and if you attended the carbon performance tuning session you learned a bit about those as well as many performance and stability enhancements that we brought with Mac OS 9 and 9.1 so if you can't bring your customers to Mac OS 10 we really encourage you to try and bring them at least two mac OS 9.1 and finally let's not forget why we're all doing this when your app runs on Mac OS 10 you get acqua you get all the new carbon api's because that's where they originate and you get access to all the other api's that are available to you on Mac OS 10 quartz all of corefoundation even BSD or cocoa api's I'm not going to get into all the details here it's pretty well documented now but these are the basic steps that I recommend you follow to get your app carbonized one go get the carbon live SDK read the Carbon porting guide use carbon dater to preview the changes you'll need to make begin adopting those new api's and then finally Aqua Phi your interface because if you don't your app is not going to look very good on Mac OS 10 and that's not the reason why you're doing carbon in the first place so let's talk about each of these briefly the carbon Live 131 SDK includes both the regular and debugging version of the carbon Live extension the debugging version as assertions that help you in your development efforts it also includes stub libraries the latest Universal interfaces folder full of documentation with links to more on our website a bunch of sample code and the Apple help you are 163 which as I mentioned you can install when you're installing on 8 6 in the documentation folder on the sdk you will find the carbon porting guide props read this document it's a hundred and fifty pages of great information it's got step-by-step porting instructions lots of great advice and a complete example of porting an application including before and after sample code and also a section on adopting Carbon advance which I think you'll find very interesting next you should run carbon data on your app this is the instructions for this are in the Carbon porting guide but it's very simple you download this tool from our website drag your application on top of it it spits out a text file that contains a list of all the api's you're importing from the system as well as some other things like potential accesses to low memory or resources stored in the system heap both of which are not supported in carbon you can look at this file make sure you know there's nothing secret in there mail it to us we have a server who sees that mail compares that list against our carbon database and in about an hour sends you back a formatted HTML report that looks something like this at the top of the report is this nifty pie chart gives you an idea of the level of carbon compatibility you're already at for each API or each function that your app imports we tell you whether it's supported in carbon modified in carbon not recommended in carbon or unsupported then the remainder of the report goes on to list specifically for every API that is not fully supported and what that API is its level of support and recommendations for alternatives alternative api's or other methods of achieving similar functionality in carbon if possible so use this report to get a general idea of what you need to do and I would encourage you during your carbonization process that every once in a while we take your your latest binary drop it on carbon data and get a new report and see how far you've come it's a great way to gauge your progress so then you have to get to work right changing all kinds of stuff in your code much of that is fairly tedious and very simple adopting accessors for opaque toolbox data structures changing your upp s we don't support the generic new routine descriptor for example you have to use specific ones like new control descriptor of the new control action upp might be one example all of that is really straightforward and pretty simple search and replace kind of stuff there are some api's that virtually all of you will need to adopt if you're currently using standard file now is the time to stop now if Services has been around since Mac OS 8 it's a much better UI and it's supported on Mac OS 10 as well as beta 9 through carbon we need you to start a diet we need you to adopt nav services and I'll also describe some other benefits of that later the carbon printing manager is necessary for anyone who's going to print because Mac OS 10 has a very different print architecture than Mac OS 8 and 9 and the carbon printing manager hides that from you by providing a high level API that supports both platforms when you're printing on Mac OS 8 or 9 it calls through to the classic route manager and uses the same classic drivers that you're already familiar with and when you're running on Mac OS 10 it uses Mac OS 10 s native print drivers to deliver to output and you don't really need to be aware of that the API is fairly straightforward we try to make it as simple as possible for you to convert to the carbon printing manager without totally altering your print loop and finally for help delivering help to your customers Apple has standardized on HTML help delivered through the Apple help viewer so we no longer support Apple guide or balloon help so we encourage you to adopt the Apple help you or api's and if you do things like tooltips and whatnot then you should use help tags and then the last step you've got your app up and running now you want to make it look good on Mac os10 the first thing I would advise you to do is to create a new high-quality 128 by 128 bit icon your icon is the first thing a user sees it is their introduction to your application and a beautiful well-designed informative icon tells the user that you care and that you want to deliver the best possible application next you'll need to adopt the system appearance or at least we highly recommend that you adopt system appearance through things like the appearance manager and other api's that we've made available to you to automatically adopt or excuse me to automatically appear as an with an aqua interface on Mac OS 10 or with the Platinum interface on Mac OS 8 or 9 and also you need to follow the aqua layout guidelines both of these steps are much easier if you use interface builder to design your interface and then use the nib files resulting from that to display this interface on Mac OS 8 and 9 or Mac OS 10 and finally we recommend that you adopt the sheets api's we've made these very easy for you now because nap services and the carbon printing manager both supports sheets so what this means is a single set of sheets api's will do the right thing on Mac OS 8 9 and Mac OS 10 so when your app is running on 8 or 9 you'll continue to get application modal dialogues and when you're running on 10 you'll get document modal sheets documentation the definitive source of API support and carbon is the header files so always look there first you want to know is this particular API supported in carbon for every function it will state right in the headers what level of carbon support is available after that the carbon spec great place to look for more information about API is not only availability but recommendations for unsupported api's the current specification is the source of the information that gets put in your Carbon Data Report I'll talk about that in a second I've already mentioned the Carbon porting guide lastly techno 2003 is sort of a mini porting guide it's not specific to Carbon developers but it provides a lot of useful information for anyone moving code from eight or nine to Mac OS 10 so the carbon spec lists all the API is in the universal interfaces those that are supported as well as unsupported gives you the inclusion status tells you what version of Carbon lib or carbon that they're available in and also when applicable what version of the OS is required to support that API and for api's that aren't fully supported the spec generally provides guidelines or recommendations for alternative api's here's a picture of the carbon spec this page is on the memory manager you can see that maximum sis is unsupported more master's for example is not recommended and we tell you there you should instead use more master pointers and as you can see more master pointer says Carbon applications should use this function instead of more masters and in all cases for supported api's we tell you what version of carbonate is available in and that they're available in 8.1 and late so again it's very useful information it is not updated as frequently as a header file so there's some lag and that's why you should always look at the headers first but the spec is generally updated several times a year and I think over time we're going to get in closer sync for additional documentation I highly recommend the learning carbon book from O'Reilly I hope you all picked it up how many of you got the learning cocoa book okay leave the room I'm having an informal competition with my cocoa technology manager counterpart and she's winning right now just rather perturbing so I'd like you all to go out and buy the learning carbon book now there is a carbon Tips & Tricks web page you should bookmark this page there's a lot of great information there created by our developer technical support group so as they find issues commented Carbon developers they put a document that on the webpage there so in fact I'll be referring to that a few more times in this discussion and finally the Carbon developer homepage that always contains pointers to the latest SDKs what's new with carbon development things of that nature and I recommend that you book that bookmark that one and check back frequently okay so that's it for the getting started part let's dig in let's talk about some of the things that you're likely to encounter now as you begin your development efforts so the first thing you need to do to get as you carbonize your app or when you're ready to run as a Carbon app is create a plist resource this tells malko is ten that you are a carbon application it is nothing more than the property list the xml property lists that you would create for a bundled Mac os10 application that same information simply paste it into a resource in your single binary application you still need to maintain your verse open FF and all these other resources for compatibility with Mac OS 8 or 9 but when you're running as a carbon app my Mac OS 10 the plist resource supersedes and overrules the information in in your resources and this is documented in tech note 2013 by the way many people ask me about the carb 0 resource which was the first way that we recommended people identify their carbon application we still recommend that you include a carb 0 resource however you must include a plist resource as well it is very important that you continue to test for API availability at runtime as you always have when you have an application that can run on Mac OS 8 9 or 10 it's no different than supporting an app when you when you have had an app that ran on 6 7 & 8 some api's are available in different OS releases that aren't available in others so the way to do this first and foremost is to use Gestalt Gestalt is the best way to test for base functionality like is Quicktime installed and then when you need to test for specific API s that may not be supported across all versions a quick time then use a T vector test to find out if that specific function that you need is there if you haven't used the T vector test before this is documented on the tips and tricks webpage and finally do not rely on the carbon live version to determine whether particular API is available because Carbon live sits on top of Mac OS 8 or 9 and in most cases is simply exporting the api's that are available in the underlying OS so it's not a reliable indicator of whether a particular API is there for you at runtime an example of this would be if you said oh I'm running on a carbon of 1 3 131 the HFS+ API is must be available to me you would be wrong because those api's were introduced in mac OS 9 so your Gestalt test would tell you that right up front accessing non-carbon api's yes you can we don't encourage it it makes your code less portable and more difficult to maintain but the option is available to you and the way you do that is using the get shared library function to find interface Lib and then the find symbol function to locate the specific function that you want to call and this again is documented in the Tips & Tricks web page be sure that you verify that you're not running on Mac OS 10 because interface live is not available there now if you're if you're doing the proper error checking with get shared library you'll of course find out it won't return interface Lib but we find that a lot of developers forget to do that and so they just assume that it's always going to return with interface Lib and when it doesn't they crash so trying to avoid that there's a few things you need to be aware of when you're writing an app that can run in two very different memory environments I'm sure you're all aware that Mac OS 10 provides essentially unlimited address space okay for gigs that's a lot main thing here is don't try and allocate all of it it has performance implications okay there's a finite amount of RAM in the system and even hard disk space for backing store may potentially be limited and of course it's a lot slower so use what you need and give it up when you're done that's really all you have to do if you're currently using free mem to find out how much memory is available for you to allocate you're gonna find that that's not very useful on Mac OS 10 because it returns essentially a meaningless value and it returns that same value every time you call it which is currently 20 megabytes we might change that it doesn't matter it's just an amount that we set to kind of allow apps who aren't being very smart about it to continue to run and another final point is if you're using zones to manage memory right now you should know that your grow zone problem we call them a co s10 zones are essentially well they're unsupported in Mac OS 10 most of the zone functions are simply no ops on 10i Mac OS 8 and 9 you need to continue to do all the same things you've always done to manage memory there Ram footprint so this is primarily of a concern to apps running on 8 or 9 carbon Lib introduces it brings in some extra code that you're probably it wasn't there before with the interface Lib and so you need to adjust your memory requirements accordingly and the amount varies widely so we can't really give any specific recommendations other than retest and wreak Walla Phi with carbon Lib you'll need to increase your stack and your heap some amount if you do plugins or either write plugins or use plugins in your app you should know that carbon apps can load interface live based plugins no problem that's on Mac OS 8 or 9 on Mac OS 10 of course they can't because interface live is not available there non-carbon apps cannot load Carbon plugins Carbon lib explicitly checks at launch time that the host app is carbon and if an interface live based plug-in tries to load it will be refused if you've been to the carbon events session the carbon performance tuning actually most of the keynotes on the first day you've probably heard over and over again stop polling right polling is is bad especially on Mac os10 not so bad on Mac OS 9 nobody really notices but a Mac OS 10 it really kills performance and one of the best ways to do that is to adopt Carbon events the Carbon Event Manager simplifies your code because it can handle for you your human interface elements can drag your windows resize draw the menu bar all these things for you it takes that out of your event loop and manages it for you and it can eliminate the need for null event processing I'll talk about that in a second what one of the biggest areas where we find application developers are polling is with Mouse tracking and there's a very simple way to stop doing that using carbon events so if you have code right now that uses get mouse button still down those kinds of functions in a tight loop you can instead use track mouse location it doesn't alter your loop at all it's very simple to adopt but the difference is that track mouse location does not return until the mouse is moved or a button is released that makes for a much more efficient system and finally we continue to support wait next event and carbon no problem there but you should be aware that there are some differences in the wait next events behavior under carbon and the primary one is that the sleep time that you request is what you're going to get unless an event arrives for your app so if you request six ticks you will not be you'll not get control back in two ticks with a null event okay you'll get returned after six ticks so the important thing here is we really recommend that you use large sleep times two or three months should be sufficient for most applications and then use carbon timers to get processing time when you need it so I think the best thing to say is that if you're relying on null events right now to do idle time processing you'll find that it's it's not going to work reliably under carbons so really you should adopt Carbon event timers and it doesn't alter your event loop you can still keep using wait next event but just start using timers you'll be much happier your customers will be much happier because your app and the rest of the system will be more responsive and finally I'd like to put in a little plug for application packaging this is the preferred way to deliver your apps especially on Mac OS 10 but you can do it on Mac OS 9 today for an example of that look at Apple works six one two it provides a better user experience because it's a drag-and-drop install it supports the localization scheme of Mac OS 10 it works on all file systems flat file systems as well as HFS and a single package can deliver more than one binary so you can deliver a CFM executable for Mac OS 809 and amok Oh executable executable for Mac os10 tech note 1188 describes packaging today on Mac OS 9 we are working on an improved package support in an upcoming version of carbon Lib and I'll talk a bit more about that later and now I would like to bring up a very special guest Vince Parsons of the Adobe Acrobat engineering team to share with you his experiences porting Acrobat to carbon ok so mark thought it'd be a good idea if someone who has actually been to this process instead a few words about our experience is what we learned the mistakes we made and hopefully we can teach a little bit from what we learned and so you won't make the same mistakes we did so I'm calling this carbon lived from the trenches so it's kind of a group of tips tricks in gotchas we discovered during the development of Acrobat Reader 5 so first why do we use carbon lib we've got a large legacy code base and we wanted to move that toward 10 but we didn't want to sacrifice our 9 & 8 development we also didn't want to have two different sets of code bases in two different binaries we wanted a single binary that worked everywhere with a single code base that worked everywhere we also wanted to have an easy way to debug the Carbon API code that we're using even with the latest version of Mitch works they distributed to show the debugging on OS 9 is still more mature so you can debug your Carbon API is on 9 as well as 10 if you use carbon Lib and they also provide the debugging Carbon Lib library which gives you lots of nice asserts when you're using the API as incorrectly and the other thing we got is we got a lot of goodies that came free with carbon Lib corefoundation ml te and carbon events are used extensively in Acrobat core foundation ml te are available in OS 9 but the latest Grist versions are only delivered via carbon lip so you wanna make sure you go that route so a few tips so as is marks gust or several runtime difference you have to worry about there's course the menu layout so quit and preferences belong over under the application menu not in the file and edit or wherever preferences typically goes and rather than just do a check on system version of ten you should probably use the gestalt menu manager aqua layout bit that way it's more dependable and you should actually avoid vert system version checks in general the help menus another issue to get the help menu on nine there was an API for it on ten to help Meany doesn't naturally exist there's a new API with part of carbon called HM getting help menu that means that API will on tin actually create the help me if it isn't already there and will return it to an on 8/9 as well as tell you which offset from beginning the menu the first item actually exists so on eight and nine when they have the show balloons and those sorts of items and let you know what offset off the beginning to use when adding your own menu items some other issues are window attributes so when you're creating a window with the current new window API there are several attributes that are ten only and if you actually create a window with these attributes on eight or nine it will fail and you will just get a null window back so there are some Gestalt checks provided before actually checking those attributes and just make sure you check those attributes before you try to assign or check that each the Stolte bits before you assign the attributes to the window so the create works and the other thing is memory management handles make little sense on OS 10 they make great sense both handles and tip mem handles on OS 9 you can check the gestalt memory map sparse to know whether you're in a sparse environment you should use just pointers or if you're not then you should use the handles like you're used to under eight and nine so most applications will call outside of the core set of API s that are part of carbon it's just a fact of life and Acrobat does it and it's actually not a big deal for calling to the OS 10 only api's just use the use the Cullum Akko framework sample that's part of the SDK as a guide it's a simple case of your loader framework find a entry point in it and you call it you can use this to call directly into core graphics you can call in to i/o kit any of the ten only api's that are currently exported only through mock oh you can also call stuff that exists only an eight nine if you're patching traps yes we still patch a trap in Acrobat it's a big no-no but we do it so you can still call it get your librarian interface live or whatever is the appropriate library for the API you're looking for and do find symbol and just again call the function pointer so you can do that for dealing with patching traps heap zones any of the things that aren't supported in the Carbon API so you've heard a lot this week about drawing text and everyone says make sure you draw text the right way because drawing text the old way looks really really bad on ten so most of us still have drawstring and draw text calls and yes it does work but it looks bad the draw themed text box API has been discussed a lot this conference it works it works well it draws anti aliased with cord graphics it also because it takes a CF string as an argument removes a lot of the issues of encoding and font selection for you so if the if the text you can just pass it into as a CF string the OS automatically figures out O's is Japanese oh this is Roman and we'll pick the appropriate font if you have the language kit installed and will display the text correctly and starting with carbon Lib 1.3.1 it is now available on 8 and 9 not just on 10 so like many Adobe apps we have plugins and we have legacy plugins that are linked to interface Lib we have to support them because they're in existing technology and we found a few caveats with dealing with plugins that you should be made aware of first of all when a plug in this interface live based creates a window with say new see window it will not necessarily be create it in the right layer there's a very distinct difference between the modal and the document and the floating and those sort of layers with carbon live and on 10 they will pretty much always be created the document layer so if you have a modal dialog created from a plugin it may end up in the wrong layer and this is always true if you use a custom proc ID because the system can't even try to guess what type of window it is so to solve this if you see that a plugins created a window you can call set window class on it or the forthcoming s window group API and just move it from the document layer to the appropriate layer and all will be well another thing to think about is Carbon events now if you're moving toward Carbon events and current events are coming any time you call wait Nick Saban's recalling run event loop or there's several other ways anytime you call into a plug-in they're all gonna call modal dialogue they no way next event directly they're gonna call things which may cause your current events and Carbon timers to be called and so just because you're calling you to a plugin doesn't mean you can't be ready for your code to be called back at any time so just be aware if you have any reentrant c issues in your coven event handlers or your timers make sure you think about those before you start dealing with the plugin issues so a few tricks there are a whole suite of api's as part of carbon based on CF string the wonderful thing about these and you sorry you can create controls windows menus almost almost all the major UI elements can be created with CF strings for their titles this allows your UI code to be completely font and encoding agnostic again as mentioning you'd stick in a Japanese CF string you stick in a Roman CF string you stick in a Chinese CF string the OS does the rest you just pass it the string it sets the thought for you deals with all the encoding issues it also makes it easy if you want to have a Roman and a non-roman checkbox say next to each other because just passing the string you can have any number of fonts in in the dialog for the various controls and carbon takes care of it for you if the fonts are available there are a couple limitations there are issues with regard to using these on OS 9nh the menu in window titles are always going to be the system font you can pass in another a string with a different coding due to limitations of the underlying OS they will always be the system thought and they're also limited to two and fifty-five bytes because they are translated into a Pascal string to go into the existing functions that are underneath in the real OS another thing to think about is the create window from nib API interface builders been talked a lot of it in this conference you can create your dialogues in Windows in interface builder and then create them in a carbon app with crate window from nib and this works on eight point six nine and ten it's a whole lot easier than dealing with dialogues and diddles and if you have existing dialogues you can import them directly into interface builders there's you go the file menu say import resource it's there it also has native support for several the new control types so you can do your bubble bevel buttons your round buttons your progress bars all the types that previously with a dialog diddle you had to create control resources and it was rather difficult a couple of issues with regard to nib files is they have to be external you cannot embed a nib file into your application as a resource and this again goes toward the packaging issue and and the nib file is actually a package itself containing a few files and that has to sit outside of your main executable if you want to actually use create window from nib see the converter nib sample on the Carbon SDK and it gives a good description of how to load the nib file and then create the window from it so with all things with new technologies there are a few gotchas so there are several api's that are currently marked as OS 10 only don't assume they'll stay that way several api's have migrated from being 10 only api's into carbon lib over time I mean couple examples get application text encoding a 10-1 to draw theme text box set in 131 there's going to be more in the future don't make assumption that if draw theme text box exists that you're on 10 or any particular API if you're checking on its existence assume that means the API exists not what OS you're running and as Mark said avoid the checking the carbon version from Gestalt well it's useful in some minor areas in most cases of problem this is because if you ask OS 10 it says 1.3 and you ask OS 9 it says 1.3 they don't mean the same thing because the versions of Carbon live in OS 10 have not matched up as nicely as they had hoped it's always good to use narrow Gestalt checks if you can check for unresolved functions with a team vector test and if you do need to check for carbon live versions say to get do a workaround for a bug or some other issue like that combine it with a system check so that you know you're running on Mac OS 9 and this is the carbon live version and the only time we call on this API is at lunch because we require carbon live 125 and later and that's the only time we check for this API gives us a good baseline to work from so resource chain management so the carbon API is added a few new API is for us to modify the resource chain previously we had if you want to modify it you can either open and close or you could modify the chain directly if you knew the structure right now there are new API is for inserting a resource file detaching a resource file there's there's several other API is dealing with this use these wisely especially under Carbon living as a as a plug-in - as a as a developer who uses plugins it's very tempting to every time we call them into a plug-in setup the resource chain but everything in you need it call the plugin and then it says the plugin returns you pull everything out of the resource chains they have no resource collisions this doesn't work as well as we'd hoped first there's an issue with regard to it's not the most efficient thing to do it's far more efficient to step your resource chain in the right order at the beginning and then do you get resources and the collisions won't happen if these things are aligned all the way you want them to be also there's a bug in nav services in Mac OS 8 six through nine one that will cause your resource chain to be corrupted in certain scenarios so if you actually modify the resource chain from a current event handler or timer that's called during a nav call because nav will call what next event whilst I legs are up it will actually corrupt the resource chain when you return from nav so if you do modify the resource change from a coverin event timer or handler make sure you don't do it during a nav call so there are a few things that oh s 10 does for you just behind the scenes that carbon lib doesn't and you got to make sure you do them yourself a couple examples create route control if you want to use the new control embedding architecture built into carbon you have to create route control on OS 8 9 on Tenace automatic on 8 9 you have to call it explicitly or have a deal GX resource next to your D log also idle controls on tan again they do that for you to animate their buttons to animate the progress bars chasing arrows etc on OS 8 9 if you don't call idle controls yourself they won't animate so if you want the chasing arrow as the progress bar to animate correctly stick a call to idle controls in a carbon timer and that'll take care of it so printing printing is an interesting issue for Acrobat because we do a lot of it and moving toward the printing manager API is on in carbon several things you want to be aware of first the carbon printing manager on 8/9 is really just a wrap around the existing print manager and a lot of the API is for getting page sizes and things like that are just wrappers around PR general calls so a few mistakes we made and hopefully I can let you avoid them is use the session api's this the non session api's do work the session API API has worked much better and we did the non session first and then rewrote our whole printing code use the session ones also write your printing code for 10 first not the other way around again we made this mistake we wrote it for 9 got it working treadle intent didn't work at all this is because 10 is far pickier about the way you use the print manager if you don't call things in quite the right order in the right way 10 will not like it but it'll work fine in carbon lips so we need to rewrite our printing code yet again for 10 and once we get it running on 10th it worked everywhere the biggest thing we ran into was some driver and compatibilities not all drivers are fully compatible with carbon loop you'll see this come up in several different ways some features will just be ignored that are part of the print driver for example reverse order printing in invert pages rotation end up printing those sorts of things they just may get totally ignored and your user may choose do to a printing and it comes up without that choice other drivers will not print color and they'll print just complete grayscale again this is caused to intimate abilities between carbon Lib and the printer drivers Apple is currently working with the driver vendors to solve these issues so in the long run this will not be an issue but in the short run be very aware that this will hit you if you are doing lots of printing and the most important thing be sure to test and a lot as new versions of carbon live come out test them as quickly as you can main treat each new version of carbon lived like it's a whole new version of OS 9 because in many ways it is the seeds do get posted in the ADC website for selecting premiere members when they show up get them immediately if you've already got a shipping application or if you're close to shipping and test your entire products because you can test your product far better than Apple ever could and while they may find some things you'll find things that they never thought to look at and you don't want to discover that once you've got a app that's actually out there and shipping that suddenly your user gets new versity carbon lib through software update and your app breaks this has happened to several third parties you don't want to happen to you so get the that get the new seeds and test them immediately and report bugs the only way it's going to get fixed is if your pork bugs and do that through bug report at apple.com so that's that's the biggest thing I want to leave with you is don't let any compatibilities affect you and that's it for my part thank you very much and a good luck in your carbonizing Thank You Vince it's great presentation you know Vince and his team contributed immensely to improvements in carbon live and you guys can too by filing bugs and feature requests so I really encourage you to do that I'm gonna stress it again at the end where we going with carbon lib we're going forward I hope it's apparent to you by now that Apple is investing heavily in carbon and will continue to do so as I said earlier as much as possible we will try and bring back new carbon api's and make them run on eight or nine that will make your development efforts easier obviously but it's important to understand our focus is Mac OS 10 but we will continue to support all the carbon api's we've already introduced so what's next with carbon and carbon Live karbala 1.4 it's currently seated you can download it from the ABC website carbon-14 includes some new api's to more closely match what you'll find on Mac OS 10 improved application package support as I mentioned earlier is coming in Mac in carbon at 1.4 and support for more localizations Brazilian Portuguese Korean Danish and some others give us feedback as soon as possible we're early in the seed stage right now so the sooner you give us your feedback the more likely it is that we can fix that bug or add that feature that you really want how do you do that bug report Apple comm any ADC member even online members can file bugs using our bug reporter system they're seen they're funneled directly into engineering and acted upon so please use that method for non-technical feedback you can send it to carbon at Apple calm I will see it others will see it and it's also a useful feedback mechanism for support I encourage you to sign up for the carbon development discussion list at lists Apple comm this is a great place to get your questions answered as well as share your knowledge with other developers it's monitored by thousands of developers and a whole bunch of Apple engineers as well if you need one-on-one support that's available through our developer technical support group you email dts at Apple comm this is fee based support those of you who are selected premiere members receive a certain amount of tech support incidents with your membership but anybody can purchase those which brings us to the roadmap well most of these sessions have gone by already but I encourage you to watch on ATC TV or on the DVDs when they come out the session on the carbon Event Manager remember improved performance stop poling make your code easier Carbon windows and menus more of the same and the application packaging and document binding well you learn about packages and also how to how to use launch services to bind your document types to your applications on Mac OS 10 if you have feedback that you'd like to give to the high-level toolbox team the feedback forum is today at 3:30 so right after this session in room C this is me again I am the carbon technology manager so I'm the guy you should send your issues and concerns to you