리소스 포크

3. 리소스 식별자

각 리소스는 OSType 식별자(4바이트 값), ID(부호 있는 16비트 워드), 선택적인 이름을 갖는다. 대화 상자 (DITL), 이미지(PICT), 소리(snd), 그리고 실행 파일 바이너리(CODE)에 대한 표준화된 리소스 유형이 있으며, PowerPC 프로세서가 등장하기 전까지는 예외 없이 리소스 포크에 저장되었다.

윈도우 렌더링을 위한 서브루틴은 자체 리소스 유형(WDEF)에 저장되고, 메뉴 렌더링을 위한 서브루틴은 자체 리소스 유형(MDEF)에 저장된다. 이러한 배열을 통해 사용자는 ResEdit와 같은 도구를 사용하여 애플리케이션 파일 또는 시스템 파일의 리소스를 수정하여 개별 애플리케이션뿐만 아니라 운영 체제 자체도 쉽게 사용자 정의할 수 있었다.

애플리케이션 또는 다른 코드 내에서 리소스는 유형, ID, 또는 이름을 조합하여 리소스 포크에 저장되는 방식과 위치에 관계없이 간단하게 로드할 수 있다. 클라이언트는 로드된 리소스에 대한 핸들을 반환받아 다른 힙 기반 데이터처럼 액세스할 수 있다. 이를 용이하게 하는 OS 구성 요소는 리소스 관리자이다. 리소스 관리자는 데이터 저장 세부 정보를 데이터에서 추상화하는 것 외에도 열린 리소스 포크 집합을 스택으로 정렬하여 가장 최근에 열린 파일을 맨 위에 둔다. 리소스를 로드하려고 할 때, 스택의 맨 위(현재 문서의 리소스 포크일 수 있음)에서 먼저 찾은 다음, 그 아래(애플리케이션의 리소스 포크)에서 찾은 다음, 그 아래(시스템 리소스 포크)에서 찾는다. 이러한 배열은 매우 강력하며 로컬 리소스가 더 낮은 수준의 더 전역적인 리소스를 재정의할 수 있으므로 예를 들어 애플리케이션은 표준 시스템 리소스 대신 자체 아이콘이나 글꼴을 제공할 수 있다. 또한 애플리케이션은 다른 리소스와 동일한 API를 사용하여 시스템에서 리소스를 로드할 수 있으며, 해당 리소스가 저장되는 위치나 방식에 관계없이 애플리케이션에 모든 리소스가 동일하게 사용할 수 있고 사용하기 쉽다. 시스템은 이로 인해 발생하는 리소스 충돌을 방지하기 위해 특정 범위의 리소스 ID를 예약한다. 리소스 관리자 API를 통해 프로그래머는 스택을 조작하고 검색 동작을 수정할 수 있다.

4. 리소스 포크의 구조

리소스 포크는 '리소스 맵'이라는 데이터 조각을 포함하는데, 이는 리소스 데이터 항목의 위치를 저장한다. 이 맵은 정의된 ID와 이름을 기반으로 리소스 데이터에 대한 임의 접근을 가능하게 한다. 리소스 포크는 기본적으로 리소스 맵과 리소스 데이터 자체, 두 가지 요소로 구성되어 있지만, 실제로는 각 데이터 유형이 여러 개의 데이터 항목을 저장하는 계층적 구조이다. 리소스 데이터에 정보가 저장되는 형식은 '리소스 유형'이라는 정보 유형에 따라 정의된다. 리소스 데이터는 종종 다른 유형의 데이터를 참조한다.

리소스 포크의 구조는 다음과 같다.

• 헤더: 리소스 데이터 및 리소스 맵의 시작 위치와 길이를 기록한다.
• 리소스 데이터: 실제 데이터이다. 데이터의 앞 4바이트에 데이터 길이를 기록하며, 여러 개가 존재할 수 있다.
• 리소스 맵: 리소스 데이터의 위치 등을 기록한다. 리소스 맵 내부는 다음과 같이 구성된다.
• 리소스 타입 리스트: 사용 중인 리소스 타입 등을 기록한다.
• 리소스 참조 리스트: 지정 ID가 가진 리소스 데이터의 시작 위치와 그 리소스에 붙여진 이름의 위치를 기록한다.
• 리소스 이름 리스트: 리소스 데이터에 이름으로 접근할 때 사용하는 이름을 기록한다.

5. 리소스 포크 접근

이전에는 리소스 포크가 '리소스 매니저' API를 통해 접근되었다. 이 API는 현재 더 이상 사용되지 않는다.^[5]

더 이상 사용되지 않는 API에서 리소스 포크 접근 과정은 다음과 같다.

# 리소스 포크에 접근할 때, 헤더에서 리소스 데이터의 시작 위치 및 길이와 리소스 맵을 포함한 데이터를 읽는다.

# 읽을 리소스 유형이 지정된 경우, 해당 유형이 리소스 목록에 있는지 확인하고, 해당 유형을 포함하는 데이터 항목의 수와 리소스 맵의 시작 위치로부터의 리소스 참조 목록에서의 오프셋을 찾는다.

# 리소스 ID, 리소스 이름의 오프셋, 리소스 속성, 리소스 데이터의 시작 위치로부터의 데이터 오프셋을 찾는다.

# 지정된 ID 또는 이름을 가진 리소스 데이터가 리소스 데이터에 있는 경우, 위에서 얻은 오프셋에 접근하고, 데이터 길이를 찾고, 저장된 모든 데이터를 읽어 반환 값으로 반환한다.

POSIX 인터페이스에서는 리소스 포크를 `''filename''/..namedfork/rsrc` 또는 `''filename''/rsrc`로 접근할 수 있었다. 더 짧은 형태는 Mac OS X v10.4에서 더 이상 사용되지 않았고, Mac OS X v10.7에서 완전히 제거되었다.^[6]

6. 데이터 타입

리소스 포크를 구성하는 가장 작은 요소는 데이터 타입이라고 불린다. 여러 종류의 데이터 타입이 존재한다. 리소스 포크에 접근한 후에는 미리 정의된 데이터 타입에 맞게 내용을 읽어들여 내용을 찾을 수 있다. 데이터 처리 방식을 프로그램 내에 정의하면 TMPL 리소스라고 불리는 리소스도 저장할 수 있다. 이 방법을 사용하면 ResEdit과 같은 프로그램으로 데이터를 볼 때 가시성이 향상되어 나중에 편집하기가 더 쉬워진다. 매킨토시 플랫폼은 모토로라 기반 프로세서(68k 및 PPC)로 시작되었기 때문에 데이터는 빅 엔디안 형식으로 디스크에 직렬화된다.^[9]

다음은 주요 데이터 타입을 알파벳순으로 나열한 것이다.

7. 리소스 타입

리소스 타입은 리소스 포크 자체뿐만 아니라 파일, 클립보드 데이터 등을 식별하는 데 사용된다. 각 리소스는 OSType 식별자(4바이트 값), ID(부호 있는 16비트 워드), 선택적인 이름을 가진다.

리소스 타입은 4바이트 길이여야 하므로, 'snd'나 'STR'과 같은 유형은 실제로 끝에 공백(0x20)이 붙는다.

다음은 몇 가지 일반적인 리소스 타입이다.

8. 리소스 포크 편집

리소스 포크는 ResEdit 등의 리소스 편집기를 사용하여 편집할 수 있으며, 이를 통해 소프트웨어의 지역화 및 사용자 정의를 할 수 있다. 대부분의 리소스 편집기는 데이터의 시각적 편집을 지원한다. 애플에서 무료로 제공하는 통합 개발 환경인 MPW 및 Apple Developer's Tools에는 Rez 컴파일러가 포함되어 있다. 이 컴파일러는 전용 Rez 언어를 사용하여 소스 코드를 컴파일하여 리소스 포크를 생성한다. 또한, 리소스 포크를 다시 Rez 코드로 변환하는 DeRez 디컴파일러도 포함되어 있다.^[7]

리소스 포크 편집기는 다음과 같다.

9. 호환성

리소스 포크는 파일 공유 프로토콜인 AFP, SMB, NFS, FTP 등을 통해 다른 파일 시스템에 접근하거나 파일을 전송할 때 호환성 문제를 일으킬 수 있다. AFP는 리소스 포크를 기본적으로 지원하지만, SMB, NFS, FTP는 그렇지 않다.^[9] macOS는 AppleDouble 형식을 사용하여 메타데이터와 리소스 포크를 별도의 파일로 저장함으로써 이 문제를 해결한다. 예를 들어 '''ExampleFile.psd''' 파일의 경우, 데이터 포크는 '''ExampleFile.psd'''에, 리소스 포크와 메타데이터는 '''._ExampleFile.psd'''에 저장된다.

MacBinary, BinHex 등의 파일 형식을 사용하여 리소스 포크를 보존할 수도 있다.

10. 다른 운영 체제

제록스 알토(Xerox Alto)의 Smalltalk-76에서 그래픽 객체의 리소스 관리자 개념이 처음 시작되었다.^[10] Windows NT의 NTFS는 대체 데이터 스트림을 통해 포크를 지원할 수 있다. BeOS는 파일 시스템 내에 데이터베이스를 구현하여 리소스 포크와 유사하게 사용할 수 있었다.

AmigaOS는 `.info` 파일을 사용하여 메타 데이터를 저장한다. 예를 들어, `MyProject`라는 프로젝트를 디스크에 저장하면 `MyProject`와 `MyProject.info` 두 파일이 저장된다. `MyProject.info` 파일은 프로젝트 아이콘, 프로젝트를 열기 위해 필요한 프로그램 정보, 사용자 주석 등을 포함한다. 최신 AmigaOS 클론인 AROS, MorphOS, AOS4는 `.info` 파일 구조를 상속받았으며, PNG 그래픽 파일을 아이콘 비트맵으로 사용할 수 있다.

NeXT 운영 체제 NeXTSTEP 및 OPENSTEP, 그 후속 제품인 macOS 및 RISC OS는 번들 또는 응용 프로그램 디렉토리 형태로 리소스를 관리한다. 이 디렉토리는 사용자에게 응용 프로그램 자체로 표시되며, 리소스는 TIFF 파일과 같은 원래 형식으로 유지된다. macOS는 하위 호환성을 위해 Carbon 라이브러리의 일부로 클래식 리소스 관리자 API를 유지하며, 리소스 자체를 파일 시스템 내의 별도 데이터 파일에 저장할 수 있다.

11. 리소스 포크의 현재 상황

인터넷이 보편화되면서 다른 운영 체제 사용자들과 파일을 공유하는 것이 당연해졌고, 이에 따라 리소스 포크는 다른 운영 체제 사용자들을 당황하게 하는 경우가 종종 발생하였다. macOS에서는 리소스 포크의 사용을 최대한 자제하게 되었으며, 이로 인해 다른 운영 체제에서 리소스 포크가 문제를 일으키는 일이 없어졌고 파일 공유도 용이해졌다. 한편, 리소스 포크를 대체하기 위해 번들이라고 불리는 폴더 계층 안에 리소스 포크에 해당하는 데이터를 데이터 포크 측에 저장하는 방식도 사용하게 되었다. 이는 정형화된 정보가 많은 응용 프로그램에서 특히 많이 사용된다.

이러한 개선 덕분에 파일 공유가 쉬워졌을 뿐만 아니라, 리소스 포크가 없는 UNIX 소프트웨어도 쉽게 이식할 수 있게 되었다.

macOS에서는 파일에 확장자를 붙이는 것이 권장되지만, 프로퍼티 목록을 사용하여 사용자가 확장자를 의식하지 않도록 하고 있다.

참조

_[1] 웹사이트 Technical Note FL19: Data in Resource Fork: Don't do It https://developer.ap[...] 1986-03-01
_[2] 웹사이트 Technical Note TN1150: HFS Plus Volume Format https://developer.ap[...] 2024-02-11
_[3] 웹사이트 Technical Q&A QA1175: Resource forks in Mach-O binaries https://developer.ap[...] 2002-08-07
_[4] 웹사이트 Mac OS X Resource Forks http://jonsview.com/[...] 2012-10-22
_[5] 웹사이트 Resource Manager Reference https://developer.ap[...] 2012-10-22
_[6] 웹사이트 Using Pathnames http://developer.app[...] 2002-12-18
_[7] 웹사이트 resource_dasm https://github.com/f[...]
_[8] 웹사이트 ResForge https://github.com/a[...]
_[9] 웹사이트 Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear http://support.apple[...] 2010-04-19
_[10] 웹사이트 The Early History of Smalltalk http://gagne.homedns[...] 2008-07-24
_[11] 문서 マルチレコードのファイル、といったようなもの自体は普通にあるものであり、実際には全く特有ではない。
_[12] 웹인용 Technical Note FL19: Data in Resource Fork: Don't do It https://developer.ap[...]