탄소(API)

Carbon (API)
탄소
개발자애플
운영 체제클래식 Mac OS, MacOS
면허증소유권
웹사이트Wayback Machine에서 http://developer.apple.com/referencelibrary/Carbon/(2009년 4월 20일 발표)

Carbon은 애플이 macOS(구 Mac OS X 및 OS X) 운영체제용으로 개발한 두 가지 기본 C 기반 API(API) 중 하나였다.카본은 맥 OS 8과 9에서 실행된 프로그램에 대해 상당한 수준의 역호환성을 제공했다.개발자들은 앱을 OPENSTEP에서 유래한 완전히 다른 코코아 시스템에 포팅하는 것에 비해 거의 노력하지 않고 Carbon API를 사용하여 "클래식" Mac 애플리케이션과 소프트웨어를 Mac OS X 플랫폼에 포팅("탄소화")할 수 있었다.MacOS 10.15 카탈리나 출시로 카본 API가 공식적으로 단종되고 제거되어 코코아가 MacOS 응용 프로그램 개발을 위한 유일한 기본 API로 남게 되었다.

Carbon은 기존 소프트웨어 응용프로그램을 신속하게 포팅할 수 있는 경로를 제공하고 Mac OS X 또는 클래식 Mac OS에서 실행되는 응용프로그램을 배송할 수 있는 방법을 제공하면서 Mac OS X를 시장에 출시하기 위한 애플의 전략에서 중요한 부분을 차지하였다.특히 iOS 출시 이후 시장이 코코아 기반의 프레임워크로 점차 이동함에 따라 포팅 라이브러리의 필요성이 희석되었다.애플은 2007년 타임프레임에서 다른 프레임워크를 업데이트하면서 64비트 버전의 카본(Carbon)을 만들지 않았고, 결국 2012년 7월 24일 발매된 OS X 10.8 마운틴 라이온(Mountain Lion)에서 API 전체를 무효화했다.

역사

Mac OS X 버전 10.2에서 직접 실행되는 "탄소화된" 애플리케이션 Adobe SystemsImageReady v.7.0

클래식 Mac OS 프로그래밍

원래의 맥 OS는 Pascal을 1차 개발 플랫폼으로 사용했으며, API는 Pascal의 콜 의미론(call semantics)을 많이 기반으로 했다.Macintosh Toolbox의 대부분은 Pascal의 변종 레코드 개념에 기초한 다양한 데이터 구조를 사용하여 API와 프로그램 사이를 왔다 갔다 하는 절차 호출로 구성되었다.

시간이 지남에 따라, 많은 오브젝트 라이브러리가 Mac에서 진화했으며, 특히 Pascal의 Object Pascal 라이브러리 MacApp과 TCL(Think Class Library)은 Pascal의 경우, 이후 버전의 MacApp 및 C++의 CodeWarrior의 PowerPlant가 진화되었다.1990년대 중반까지 대부분의 Mac 소프트웨어는 C++로 CodeWarrior를 사용하여 작성되었다.

랩소디

애플은 1996년 말 NeXT를 인수하면서 기존 오픈스텝 플랫폼을 기반으로 새로운 운영체제 전략을 개발했다.The new Rhapsody was relatively simple; it retained most of OpenStep's existing object libraries under the name "Yellow Box", ported OpenStep's existing GUI and made it look more Mac-like, ported several major APIs from the Mac OS to Rhapsody's underlying Unix-like system (notably QuickTime and AppleSearch), and added an emulator known as the "Blu기존 Mac OS 소프트웨어를 실행한 "e Box".

1997년 월드와이드 개발자 컨퍼런스에서 이 계획이 공개되었을 때, 기존 Mac OS 개발자들은 그들의 코드 베이스가 효과적으로 업데이트될 것 같지 않은 에뮬레이터에 고정될 것이라는 사실에 화가 났다.그들은 블루 박스를 "벌의 상자"[citation needed]라고 부르기 시작했다.마이크로소프트나 어도비 같은 대형 개발업체들은 노골적으로 주저했고, 기존 맥 OS와는 너무 달라 호환성이 거의 없거나 아예 없었던 OpenStep에 포팅하는 것을 고려하지 않았다.

애플은 이런 우려를 가슴 깊이 새겼다.스티브 잡스는 1998년 WWDC에서 이러한 방향 변화를 발표하면서 "개발자들이 진정으로 원했던 것은 현대판 맥 OS였고 애플은 그것을 전달할 예정이었다"고 말했다.그 성명은 우레와 같은 박수갈채를 받았다.

기존 맥 OS 소프트웨어를 구동하는 블루박스만을 탑재한 랩소디 컨셉은 결국 1999년 맥 OS X 서버 1.0으로 출시됐다.이것은 랩소디 원작을 바탕으로 한 유일한 발매였다.

코코아와 탄소

애플은 기존 맥 OS 코드 베이스에 대해 실질적이고 잘 지원되는 업그레이드 경로를 제공하기 위해 카본 시스템을 도입했다.카본은 에뮬레이션에서 실행 중인 Mac OS의 복사본이 아니라 Mac과 같은 API를 제공하지만 기본 Unix와 같은 OS 위에서 실행되는 많은 라이브러리와 기능으로 구성된다.탄소 도서관은 광범위하게 청소되고 현대화되며 더 나은 "보호"된다.Mac OS가 데이터를 전달하기 위해 메모리를 공유하는 API로 채워진 반면, Carbon에서는 그러한 모든 액세스가 불투명한 데이터 유형에 대한 액세스자 서브루틴을 사용하여 다시 구현되었다.이를 통해 Carbon은 진정한 멀티태스킹과 메모리 보호를 지원할 수 있게 되었으며, 맥 개발자들이 10년 동안 요청해 온 기능이다.기존 API의 다른 변경 사항으로 인해 개념적으로 Mac OS X와 호환되지 않거나 구식인 기능이 제거되었다.예를 들어, 응용 프로그램은 더 이상 인터럽트 핸들러나 장치 드라이버를 설치할 수 없다.

카본 지원을 위해 랩소디 모델 전체가 바뀌었다.랩소디는 효과적으로 에뮬레이터의 OpenStep인 반면, 새로운 시스템에서는 OpenStep과 Carbon API 모두 가능하면 공통 코드를 공유할 것이다.이를 위해, Objective-C로 작성되고 Foundation으로 알려진 OpenStep 시스템의 하위 레벨에서 유용한 코드의 많은 부분이 순수한 C로 재실행되었다.이 코드는 Core Foundation, 즉 줄여서 CF로 알려지게 되었다.CF를 부르기 위해 포팅된 옐로박스의 버전이 새로운 코코아 API가 되었고, 카본의 맥 같은 호출도 같은 기능을 불렀다.새로운 시스템 하에서 카본과 코코아는 동료였다.이러한 전환은 일반적으로 코코아의 성능을 저하시켰을 것이다. C 라이브러리에 개체 방법이 호출되었기 때문이다. 그러나 애플은 이러한 영향을 줄이기 위해 무료 브리징이라고 불리는 기술을 사용했다.[1]

애플은 이 변환의 일환으로 라이선스 번호 디스플레이 포스트스크립트(Display PDF)에서 라이선스 없는 쿼츠(Display PDF)로 그래픽 엔진을 포팅하기도 했다.[2]Quartz는 Carbon이나 코코아에서 사용할 수 있는 네이티브 콜과 Java 2D와 같은 인터페이스를 제공했다.기본 운영체제 자체는 더욱 고립되어 다윈으로 출시되었다.

릴리스 및 진화

카본은 1997년 맥 OS 8.1과 역호환되는 공유 라이브러리로 2000년에 불완전한 형태로 도입되었다.이 버전은 개발자들이 기존 Mac OS 기기에서 프로그램을 실행할 수 있는 능력을 잃지 않고 Carbon에 코드를 포팅할 수 있게 했다.탄소 포팅은 "탄소화"로 알려지게 되었다.공식 Mac OS X 지원은 2001년에 새로운 OS의 첫 번째 공개 버전인 Mac OS X v10.0의 출시와 함께 도착했다.카본은 거의 모든 주요 소프트웨어 회사들, 심지어 애플에 의해서도 맥 OS X의 초기 버전에서 매우 널리 사용되었다.예를 들어, 파인더는 카본 어플리케이션으로 여러 해 동안 유지되었고 2009년 Mac OS X 10.6의 출시와 함께 코코아에 포팅되었다.[3]

2007년 10월 26일에 출시된 Mac OS X v10.5로 시작하는 64비트 Macintosh 애플리케이션으로의 전환은 Carbon에 첫 번째 주요 제한을 가져왔다.Apple은 64비트 환경에서 Macintosh 그래픽 사용자 인터페이스와 C 프로그래밍 언어 간의 호환성을 제공하지 않으며, 대신 코코아 API와 함께 Objective-C 사투리를 사용해야 한다.[4]많은 논평자들은 이것을 카본의 궁극적인 실종의 첫 신호로 받아들였는데, 애플이 카본 시스템에 새로운 주요 추가 사항이 추가되지 않을 것이라고 발표했을 때 다시 강화되었고,[5] 2012년 그것의 불용성으로 더욱 강화되었다.

코코아로 전환

코코아가 가지고 있는 장점에도 불구하고, 많은 양의 레거시 코드를 다시 써야 하는 필요성은 탄소 기반 애플리케이션의 전환을 지연시켰고,[6] 유명한 것은 어도비 포토샵으로 2010년 4월에 결국 코코아로 업데이트되었다.이는 아이튠즈와[7] 파이널 컷 프로(이것을[8] 구동하는 QuickTime 엔진의 특징뿐만 아니라)가 수년간 카본으로 쓰여져 있었기 때문에 애플 자체의 대표 소프트웨어 패키지로도 확대되었다.아이튠즈와 파이널 컷 프로 X 모두 이후 코코아 버전으로 출시되었다.

사용 중지 및 중단

2012년에는 OS X 10.8 마운틴 라이온의 출시로 대부분의 카본 API가 더 이상 사용되지 않는 것으로 간주되었다.API는 여전히 개발자들이 접근할 수 있었고 모든 Carbon 애플리케이션은 여전히 실행되었지만, API는 더 이상 업데이트되지 않을 것이다.2017년 6월 28일, Apple은 모든 Carbon 애플리케이션과 같은 macOS용 32비트 소프트웨어는 MacOS 10.13 High Sierra 이후 MacOS 버전에서 더 이상 "손상 없이" 지원되지 않을 것이라고 발표했다.[9] macOS 10.15 Catalina는 모든 Carbon 애플리케이션을 포함한 32비트 애플리케이션에 대한 지원을 공식적으로 제거했다.[10]

건축

카본은 툴박스에서 내려오고, 따라서, "매니저"로 구성된다.각 매니저는 기능적으로 관련된 API로, 데이터 구조와 기능을 정의하여 이들을 조작한다.관리자들은 종종 상호의존적이거나 계층화된다.카본은 파일, 메모리, 데이터, 사용자 인터페이스 및 기타 시스템 서비스를 관리하기 위한 광범위한 기능으로 구성된다.다른 API로 구현됨: MacOS에서는 주로 여러 프레임워크(각각 공유 라이브러리를 중심으로 구축된 구조)에 걸쳐 구현됨Carbon.framework,ApplicationServices.framework그리고CoreServices.framework그리고 클래식한 Mac OS에서는 이름이 지정된 단일 공유 라이브러리에 상주하며CarbonLib.

C언어 API 절차를 포괄하는 용어로서, Carbon은 별도의 시스템으로 설계되지 않았다.오히려, 그것은 광범위하게 동등한 코코아 API에 필요한 Objective-C 언어를 모르는 개발자들에게 MacOS의 거의 모든 기능을 개방한다.[11]

Carbon은 PowerPC Mac OS에서 사용할 수 있는 여러 실행 파일 형식과 모두 호환된다.Mac OS X와 이전 버전 간의 이진 호환성은 Apple이 Xcode IDE에서 지원하지 않은 기본 실행 파일 형식을 사용해야 한다.

Carbon의 새로운 부분은 그들의 개념에서 훨씬 더 객체 지향적인 경향이 있는데, 그들 대부분은 Core Foundation을 기반으로 한다.HIView Manager(제어 관리자의 상위 집합)와 같은 일부 Manager는 C++로 구현되지만 Carbon은 C API로 남아 있다.

Carbon Manager의 몇 가지 예:

  • 파일 관리자 - 파일 시스템에 대한 액세스, 파일 열기, 닫기, 읽기 및 쓰기 관리
  • 리소스 관리자 — 프로그램에서 필요로 할 수 있는 미리 정의된 데이터 청크인 리소스에 대한 액세스를 관리한다.Disk 파일에서 리소스를 읽고 쓰도록 파일 관리자를 호출하십시오.리소스의 예로는 아이콘, 소리, 이미지, 위젯용 템플릿 등이 있다.
  • 글꼴 관리자 - 글꼴 관리Mac OS X v10.4 이후 Apple Type Services(ATS)를 위해 사용되지 않음(QuickDraw의 일부임).
  • QuickDraw — 2D 그래픽 원시 요소.Mac OS X v10.4 이후 Quartz 2D를 위해 더 이상 사용되지 않음
  • Carbon Event Manager — 사용자 및 시스템 활동을 코드가 인식하고 대응할 수 있는 이벤트로 변환한다.
  • HIObject — GUI를 구축하기 위해 Carbon a OO 모델을 제공하는 완전히 새로운 객체 지향 API. Mac OS Classic과 Copland의[12] HIToolbox는 버려진 IBM System Object Model에 의존했기 때문에 Carbon은 레거시 코드를 포팅할 수 있도록 빠르고 더러운 대체품을 제공해야 했다.이 기능은 Mac OS X v10.2 이상에서 사용할 수 있으며, Carbon 프로그래머들에게 코코아 개발자들이 오랫동안 친숙했던 도구 중 일부를 제공한다.Mac OS X v10.2부터 HIObject는 Carbon의 모든 GUI 요소의 기본 클래스다.HIView는 애플의 개발 도구의 일부인 인터페이스 빌더에 의해 지원된다.전통적으로 이러한 종류의 GUI 아키텍처는 제3자 애플리케이션 프레임워크에 제공되어야 한다.Mac OS X v10.4부터 HIObjects는 NCObject이며, 전송이나 디스크에 저장하기 위해 데이터 스트림으로 직렬화되는 기능을 상속한다.
  • HITheme — QuickDraw 및 Quartz를 사용하여 그래픽 사용자 인터페이스(GUI) 요소를 화면에 렌더링한다.HITheme은 Mac OS X v10.3에 도입되었으며, 그 이후부터 외관 매니저는 HITheme 위에 있는 호환성 계층이다.
  • HIView Manager — 제어 장치의 생성, 그리기, 히트 테스트 및 조작을 관리한다.맥 OS X v10.2 이후 모든 제어장치는 HIV 바이러스다.Mac OS X v10.4에서 Control Manager는 HIView Manager로 이름이 변경되었다.
  • Window Manager(윈도우 관리자) - 창 생성, 위치 지정, 업데이트 및 조작을 관리한다.맥 OS X v10.2 이후, 창문은 HIV 바이러스에 뿌리를 두고 있다.
  • 메뉴 관리자 - 메뉴 작성, 선택 및 조작 관리맥 OS X v10.2 이후 메뉴는 HIObjects이다.맥 OS X v10.3부터는 HIViews를 사용하여 메뉴 내용을 그릴 수 있으며, 모든 표준 메뉴는 HIViews를 사용하여 그림을 그릴 수 있다.

이벤트 처리

Mac Toolbox의 Event Manager는 원래 애플리케이션 설계에 폴링 모델을 사용했다.애플리케이션의 메인 이벤트 루프는 GetNextEvent를 사용하는 이벤트를 Event Manager에 요청한다.대기열에 이벤트가 있는 경우 이벤트 관리자는 해당 이벤트를 다시 응용 프로그램에 전달하고, 여기서 처리하면 즉시 반환된다.이러한 행동을 "바쁜 대기"라고 하며, 이벤트 루프를 불필요하게 실행한다.대기 시간이 많으면 다른 애플리케이션에서 사용할 수 있는 CPU 시간이 줄어들고 노트북의 배터리 전원이 감소한다.고전적인 이벤트 매니저는 실행 중인 애플리케이션이 유일한 애플리케이션으로 보장되고 전원 관리가 문제가 되지 않았던 1984년의 원래 Mac OS에서 유래한다.

MultiFinder의 출현과 동시에 둘 이상의 애플리케이션을 동시에 실행할 수 있는 기능과 함께 애플리케이션이 절전 주기를 지정할 수 있는 새로운 Event Manager 통화인 WaitNextEvent가 나왔다.레거시 코드가 소스 코드를 크게 변경하지 않고 보다 효율적인 모델을 채택하는 한 가지 쉬운 방법은 단순히 WaitNextEvent에 전달된 절전 매개변수를 매우 큰 값으로 설정하는 것이다(macOS에서, 이것은 할 일이 없을 때마다 스레드를 절전 상태로 만들고 처리할 이벤트가 있을 때만 이벤트를 반환한다).이런 식으로, 폴링 모델은 콜백 모델과 동등하게 되기 위해 빠르게 반전되며, 애플리케이션은 원래 방식으로 자체 이벤트 배달을 수행한다.하지만 허점은 있다.우선, 레거시 툴박스 호출 ModalDialog는, 예를 들어, 구형 GetNextEvent 기능을 내부적으로 호출하여, 차단하지 않고 빠듯한 루프로 폴링이 이루어진다.

카본은 카본 이벤트 매니저라고 불리는 대체 시스템을 도입한다.(기존 애플리케이션과의 호환성을 위해 원래 Event Manager가 여전히 존재함).Carbon Event Manager가 개발자에게 이벤트 루프 제공(Core Foundation의 기능 기준)CFRunLoop현재 구현); 개발자는 이벤트 핸들러를 설정하고 메인 기능에 이벤트 루프를 입력하며, Carbon Event Manager가 응용 프로그램에 이벤트를 디스패치할 때까지 기다린다.

타이머스

고전적인 Mac OS에서는 애플리케이션 레벨 타이머에 대한 운영 체제 지원이 없었다(하위 레벨의 Time Manager를 사용할 수 있었지만, 대부분의 툴박스 루틴에 안전하게 통화를 할 수 없는 인터럽트 시간에 타이머 콜백을 실행했다).타이머는 대개 애플리케이션 개발자에게 맡겨 구현했으며, 이는 대개 유휴 이벤트 동안 경과된 시간, 즉 다른 이벤트를 사용할 수 없을 때 WaitNextEvent에 의해 반환된 이벤트를 계산하여 수행되었다.이러한 타이머가 합리적인 해상도를 갖기 위해 개발자들은 WaitNextEvent를 너무 오래 지연시킬 여유가 없었고, 그래서 보통 낮은 "절전" 매개변수가 설정되었다.이는 매우 비효율적인 스케줄링 동작을 유발하는데, 이는 스레드가 매우 오랫동안 절전 모드로 전환되지 않고 대신 이러한 유휴 이벤트를 반환하기 위해 반복적으로 깨우기 때문이다.애플은 이 문제를 해결하기 위해 Carbon에 타이머 지원을 추가했다. 즉, 이 시스템은 타이머를 매우 효율적으로 스케줄링할 수 있다.

오픈 소스 구현

GNUstep은 Boron이라고 불리는 Carbon API의 구현을 포함한다.그것은 ApplicationServices 및 CoreServices의 비사용 부분과 호환되는 것을 목표로 한다.그 이름은 보론이 주기율표에서 탄소보다 먼저 온다는 사실을 유래했다.[13]달링에는 탄소 구현도 포함되어 있다.두 구현 모두 매우 불완전하며 대부분 스터브 기능으로 구성된다.

참고 항목

참조

  1. ^ "Concepts in Objective-C Programming: Toll-Free Bridging". developer.apple.com. 2012. Retrieved May 8, 2017.
  2. ^ Siracusa, John (2000). "Mac OS X Update: Quartz & Aqua". archive.arstechnica.com. Retrieved May 8, 2017.
  3. ^ Krazit, Tom (October 17, 2008). "Apple moving Finder to Cocoa". CNET. Archived from the original on July 11, 2015. Retrieved May 21, 2015.
  4. ^ Apple Inc. "Introduction to 64-Bit Guide for Carbon Developers". Archived from the original on June 11, 2009.
  5. ^ Apple Inc. "Choosing a Development Path for Your Carbon User Interface". Modifying Your Application to Use 64-Bit Addressing. Archived from the original on August 4, 2009.
  6. ^ John Nack. "Photoshop, Lightroom, and Adobe's 64-bit roadmap". Archived from the original on April 14, 2015.
  7. ^ Chris Foresman (September 3, 2010). "iTunes 10 hands-on: snappier performance, questionable UI choices". Archived from the original on April 2, 2015.
  8. ^ John Siracusa (September 2009). "Mac OS X 10.6 Snow Leopard: the Ars Technica review". Archived from the original on July 13, 2014.
  9. ^ Apple Inc. (June 28, 2017). "64-bit Requirement for Mac Apps". Archived from the original on January 30, 2018. Retrieved February 18, 2018.
  10. ^ MacRumors (June 4, 2019). "32-Bit Apps 'Not Optimized for Your Mac' to Stop Working on macOS Catalina". Retrieved August 10, 2019.
  11. ^ Apple Inc. "Apple Carbon homepage". Archived from the original on October 12, 2012.
  12. ^ Mac OS 8.0(Copland) DDK의 HIEditText SOM 클래스 설명[영구적 데드링크]
  13. ^ "gnustep/libs-boron: Boron is the atom that comes before carbon". GitHub. GNUstep. March 23, 2019.