네이티브 API(Native API)는 윈도우 NT와 사용자 모드의 응용 프로그램에서 사용되는 API이다. 다른 윈도우 구성 요소들이 사용되기 힘들 때 사용되며, 주로 시스템 부팅 시나 kernel32.dll 같은 윈도우 API를 구현하는 용도로 쓰인다. ntdll.dll의 엔트리 포인트는 LdrInitializeThunk이다. 대부분의 네이티브 API의 호출은 ntoskrnl.exe에서 구현되며, ntdll.dll에 의해서 사용자 모드로 노출된다. 어떤 경우에는 사용자 모드에서 ntdll.dll 내부의 네이티브 API가 직접 호출되기도 한다.

네이티브 API 호출은 SSDT를 통해서 커널에 의해 관리된다.

대부분의 마이크로소프트 윈도우가 잘 정의된 윈도우 API에 의해 구현된 반면, 클라이언트/서버 런타임 하위 시스템같은 소수의 구성 요소들은 네이티브 API로 구현된다. 왜냐하면 이것이 윈도우 NT 시작 프로세스 전에 호출되는데, 이 때는 WIndows API가 아직 사용 가능하지 않기 때문이다.

함수 그룹

네이티브 API는 많은 함수들로 이루어져 있다. strlen(), sprintf() 등이 있고 floor() 같은 기본적인 C 런타임 실행을 위해 C 런타임 함수들을 포함한다. malloc(), printf(), scanf() 같은 공통 프로시저들은 빠졌다. 대다수의 네이티브 API들은 관행적으로 아래와 같은 접두사를 갖는다.

• Nt 또는 Zw는 ntdll.dll과 ntoskrnl.exe에서 선언된 시스템 호출이다. 사용자 모드의 ntdll.dll에서 호출되면, 이 그룹들은 다음과 같은 면에서 거의 같다. 커널 모드에 들어가서 SSDT를 통해 ntoskrnl.exe의 같은 의미를 가진 함수를 호출한다. ntoskrnl.exe에서 직접적으로 호출될 경우(커널 모드에서만 가능)에는 Zw는 Nt와 달리 커널 모드인 것을 보장한다. Zw 접두사는 아무것도 의미하지 않는다.
• Rtl은 ntdll 함수 중에서 두번째로 많은 그룹이다. 이것은 (확장된) C 런타임 라이브러리를 구성하고 있다. (확장된) C 런타임 라이브러리는 (커널 지원을 직접적으로 포함하지 않지만) 네이티브 응용 프로그램들에 쓰이는 많은 유틸리티 함수를 포함한다.
• Csr은 Win32 하위 시스템 프로세스(csrss.exe)와 통신할 때 사용되는 클라이언트-서버 함수들이다.
• Dbg는 소프트웨어 브레이크포인트 같은 디버깅 함수들이다.
• Ki는 APC 디스패칭 같은 이벤트들을 위한 커널 모드에서의 upcall들이다.
• Ldr은 새로운 프로세스들을 시작시키는 것을 다루는 PE 파일을 위한 로더 함수들이다.
• Nls는 네이티브 언어 지원을 위해 사용된다.
• Pfx는 prefix를 다루기 위해 사용된다.

user32.dll과 gdi32.dll은 커널 모드로 가는 다른 호출도 포함한다. 이것은 과거에 하드웨어의 성능 문제로 인해 그래픽 서브 시스템을 커널 모드로 보내기로 결정했기 때문이다. 0x1000~0x1FFF 범위의 시스템 호출들은 win32k.sys용이며, user32.dll과 gdi32.dll에서 정의된다. 이런 함수들은 NtUser, NtGdi 접두사가 붙는다.

또한 ntoskrnl.exe에서 나온 많은 그룹들이 있으며, 그 이유로 오직 커널 모드에서만 사용될 수 있다. 이것들은 네이티브 API에 포함되기도 하고, 되지 않기도 한다. Cc(cache controller), Ex(Windows Executive), FsRtl(file system runtime library), Io(I/O manager), Ke(core kernel routines), Ks(kernel streaming), Lpc(로컬 프로시저 호출), Lsa(로컬 보안 인증), Mm(memory management), Ob(객체 관리자), Ps(Process management), Se(security), Po(power management) 등이 있다.

사용

• 특권 부여와 회수 (RtlAdjustPrivilege)
• 다른 세션에서 실행 중인 프로세스 내부에서 원격 쓰레드 생성 (RtlCreateUserThread)
• 네이티브 응용 프로그램 실행 (RtlCreateUserProcess)
• 강제 종료 (NtShutdownSystem)

같이 보기

• 마이크로소프트 윈도우 구성 요소 목록
• 윈도우 API

각주

외부 링크

• 대부분의 네이티브 API 함수들이 정리된 웹사이트 Archived 2012년 10월 31일 - 웨이백 머신
• Inside Native Applications
• Inside the Native API
• Open source native applications development framework
• Native shell - Windows command prompt which can start before Winlogon and Win32 subsystem
• Windows NT Native Tools - A free native applications development util

구글 네이티브 클라이언트(영어: Google Native Client, NaCl)는 소프트웨어 기반 실패 분리(fault isolation)를 이용하여 인텔 x86이나 ARM 네이티브 코드의 하부집합을 실행하기 위한 샌드박스 기술이다. 현재는 개발 중에 있는 이 기술은 웹 브라우저로부터 네이티브 코드를 안전하게 실행할 수 있도록 하고 있으므로 웹 기반 응용 프로그램들이 네이티브에 가까운 속도를 낼 수 있다. 네이티브 클라이언트는 구글이 개발하고 있는 오픈 소스 프로젝트이다.

페퍼

NaCl는 염화 나트륨을 가리키며 언어 유희로 후추의 이름으로 페퍼가 사용되었다. 페퍼 API는 네이티브 클라이언트 모듈들을 만들기 위한 크로스 플랫폼, 오픈 소스 API이다. 페퍼 플러그인 API, 즉 PPAPI는 네이티브 클라이언트 보안 웹 브라우저 플러그인을 위한 크로스 플랫폼 API로서, 처음에는 넷스케이프 NPAPI에 기반을 두다가 처음부터 다시 작성되었다. 현재는 PPAPI 버전의 어도비 플래시와 내장 PDF 뷰어를 활성화하기 위해 크로미엄과 구글 크롬에 사용되고 있다.

PPAPI

2009년 8월 12일, 구글 코드의 한 페이지는 "페퍼"라는 새로운 프로젝트를 선보였으며 페퍼 플러그인 API, 즉 PPAPI와 연계하였는데, 이는 플러그인을 더 휴대성있게 더 안전하게 만들기 위해 NPAPI에 대한 수정 사항의 집합이다.

각주

같이 보기

• asm.js : 웹 기반 응용 프로그램을 위한 또 다른 기술.

예제

• Native Client Gallery
• NACLBox

외부 링크

• (영어) 네이티브 클라이언트 웹사이트

이 글은 마이크로소프트 윈도우 라이브러리 파일들에 대한 설명이다. 마이크로소프트 윈도우 운영 체제는 dll이라고 알려진 라이브러리를 지원하는데, 이것들은 복사본 하나만 메모리에 올라와도 여러 프로세스에서 사용될 수 있는 코드 라이브러리이다. 이 문서는 현재 윈도우에 포함된 코드 라이브러리들의 개요를 제공한다.

내부 구성 요소

이 단락에서 설명하는 라이브러리 파일들은 대부분의 프로그램에서 직접적으로는 사용되지는 않는다. 하지만 대부분의 프로그램들에서 사용되는 다른 라이브러리들이 의존하는 라이브러리이다.

Hal.dll

하드웨어 추상화(HAL)는 Hal.dll 안에 구현되어 있다. HAL은 다양한 플랫폼들의 다양한 방식들이 구현된 많은 함수들을 구현한다. 운영 체제의 다른 구성 요소들은 이것 덕분에 다른 모든 플랫폼들의 실제 구현 방식을 알지 못해도 이 함수들을 사용하여 일관성을 제공받을 수 있다.

예를 들면, APIC(Advanced Programmable Interrupt Controller)를 사용하는 머신의 인터럽트에 반응하는 것은 다른 것들과 상당히 다르다. HAL은 다양한 칩셋들을 통해 모든 종류의 인터럽트들은 통일시킨 함수를 만들어 준다.

HAL은 커널 주소 영역에 적재되어 커널 모드로 실행되기 때문에 HAL 내부의 루틴들은 응용 프로그램에 의해서 직접적으로 호출될 수 없다. 그리고 어떤 사용자 모드 API들도 직접적으로 HAL과 연동될 수 없다. 그렇기 때문에 HAL은 실행 프로그램과 커널 그리고 커널 모드 장치 드라이버에게 주로 서비스를 제공한다. 비록 대부분의 하드웨어의 드라이버들이 다른 파일들에 포함되어 있지만 .sys나 소수의 중요한 드라이버들은 Hal.dll에 컴파일된다.

PCI와 PCI 익스프레스 같은 커널 모드 장치 드라이버들은 입출력 포트와 자기 드라이브의 레지스트리에 접근하기 위해 직접적으로 HAL의 루틴을 호출한다. 다양한 플랫폼들이 그들만의 다양한 연산들에 의한 구현을 요구하기 때문에 드라이버들은 HAL 루틴을 이용한다. HAL은 각 플랫폼들에게 맞는 적절한 연산들을 구현한다. 이로써 같은 드라이버에서 실행될 수 있는 파일은 (같은 종류의 CPU를 가진다면) 모든 플랫폼에서 사용될 수 있고, 드라이버 소스 파일은 모든 아키텍처에서 이식이 가능해진다.

x86 시스템의 경우, 설치 프로그램에는 여러 다른 종류의 HAL 파일들이 존재한다. 윈도우는 설치 시 현재 플랫폼에 어떤 것이 적절한가를 결정하고 하드 드라이브에 복사해 놓고, 필요한 경우에는 Hal.dll에 renaming을 시킨다. 선택하는 기준은 다음과 같다. ACPI 호환가능한 BIOS의 존재, APIC의 존재, 그리고 여러 프로세스들이 존재하는가와 사용 가능한가. x86-64과 아이테니엄 플랫폼에서는 각각의 CPU에 가능한 단 하나의 Hal.dll이 존재한다.

NTDLL.DLL

NTDLL.DLL은 네이티브 API를 노출시킨다. 네이티브 API는 (Win32나 다른 API 하위 시스템에의 지원 없이) 운영 체제의 사용자 모드 구성 요소에 의해 사용되는 인터페이스이다. 대부분의 이 API들은 NTDLL.DLL에 구현되어 있으며, ntoskrnl.exe(및 그 변종)의 윗면이다. 그리고 이 라이브러리 내부에서 노출되는 대부분의 심볼들은 Nt를 접두어로 갖는다. 네이티브 API들은 또한 KERNEL32.DLL에 의해 노출되는 커널 API들이나 베이스(base) API들을 구현하기 위해 사용된다. 참고로 대부분의 윈도우 응용 프로그램들은 NTDLL.DLL을 직접적으로 호출하지 않는다.

이 라이브러리와 직접적으로 링크된 응용 프로그램을 네이티브 응용 프로그램(native application)이라고 하며, 이것은 Win32 하위 시스템이 사용 가능해지기 전인 윈도우 시작 전에 실행되기 위해 존재한다. 예를 들자면 Win32 하위 시스템 프로세스(csrss.exe)의 호출 같은 경우인데, csrss.exe 프로세스가 존재하기 전에는 어떤 Win32 프로세스도 생성될 수 없기 때문이다.

네이티브 응용 프로그램이 .exe 확장자를 가지고 있다고 해도, 사용자나 Win32 또는 다른 하위 시스템에 의해 실행되는 것은 아니다.

Win32 응용 프로그램들과 달리 네이티브 응용 프로그램은 커널 런타임 코드(ntoskrnl.exe) 안에 생성되며, 그러므로 다른 진입 지점(Entry Point)을 갖는다. (NtProcessStartup 등이 그것인데, (w)(Win)MainCRTStartup 같은 Win32 응용 프로그램에서 볼 수 있는 것과는 다르다.) 이것은 그들의 명령 줄 전달인자(argument)를 인 메모리 구조에 대한 포인터를 통해서 얻는다. 또한 Rtl 힙(heap) API를 통해 자신의 메모리를 관리하고, NtTerminateProcess (ExitProcess가 아닌)를 통해 리턴한다. 네이티브 응용 프로그램에 링크된 보통의 라이브러리는 nt.lib인데, 이것은 네이티브 응용 프로그램의 시작 코드(startup code)를 포함하며, C 런타임이 Win32 응용 프로그램에 시작 코드(startup code)를 제공하는 것과 비슷한 방식이다.

비록 대부분의 API들이 문서화되어 있지 않지만, 네이티브 응용 프로그램은 윈도우 DDK를 사용하여 만들 수 있다. 많은 바이러스 검사 소프트웨어와 유틸리티 프로그램이 이것들을 이용하여 만들어진다.

Win32 API

이 단락에 있는 라이브러리들은 각각 다양한 Win32 API들을 구현하는 부분 집합이다.

KERNEL32.DLL

KERNEL32.DLL은 메모리 관리, 입출력 명령, 프로세스와 스레드 생성, 그리고 동기화 함수들 같은 대부분의 Win32 베이스(base) API들을 응용 프로그램에 내보낸다. 대부분의 것들이 (NTDLL.DLL에 의해 내보내진) 상응하는 네이티브 API를 호출함으로써 KERNEL32.DLL의 내부에 구현되어 있다.

GDI32.DLL

GDI32.DLL은 그래픽 장치 인터페이스(GDI) 함수들을 노출시키는데, 이것들은 디스플레이나 프린터에 출력되는 원시적인 드로잉 함수들을 수행하는 역할을 한다. 응용 프로그램들은 GDI 함수들을 낮은 수준의 드로잉을 위해 직접적으로 호출한다.

USER32.DLL

USER32.DLL은 윈도우 USER 구성 요소를 구현한다. 윈도우 구성 요소는 창이나 메뉴 같은 윈도우 사용자 인터페이스의 표준 요소들을 생성하고 다룬다. 그러므로 프로그램들에게 그래픽 사용자 인터페이스(GUI)를 구현할 수 있게 해준다. 프로그램들은 창 생성이나 관리, 그리고 창 메시지 받기 등을 수행하기 위해 윈도우 USER에서 함수들을 호출한다.

GDI에 관한 많은 USER32.DLL 함수들은 GDI32.DLL에 의해 내보내진 것들이다. 어떤 종류의 프로그램들은 또한 GDI 함수들을 직접적으로 호출하여 낮은 수준의 드로잉을 수행하기도 한다.

COMCTL32.DLL

COMCTL32.DLL는 파일 오픈, 저장, 상태바 같은 다양한 종류의 윈도우 표준 컨트롤을 구현한다. 이것은 이런 UI 요소들을 위한 윈도우를 만들고 관리하기 위해 USER32.DLL와 GDI32.DLL에서 함수들을 호출한다.

다른 API들

SHSCRAP.DLL

SHSCRAP.DLL은 객체 연결 삽입(OLE) 메커니즘의 한 부분이다. 이것은 셸 스크랩(scrap) 파일들에 대한 지원을 구현한다. (OLE이 가능한 응용 프로그램의 선택된 콘텐츠를 바탕 화면으로 드래그할 때 자동으로 생성됨) 또한 오브젝트 패키저(Object Packager)를 통해 생성할 수도 있다. 이때는 다른 OLE이 가능한 응용 프로그램에 드래그할 수 있다.

이 기능은 윈도우 비스타부터 보안 향상과 일반적으로 사용되지 않은 기능을 삭제하기 위해 제거되었다. 스크랩 (.shs) 파일들은 코드부터 시작해서 다양한 내용을 저장할 수 있어서 바이러스로 사용되어 왔다. 이 기능은 윈도우 XP의 DLL에서 레지스트리 엔트리를 복사해서 다시 복구할 수 있다.

런타임 라이브러리

MSVCRT.DLL, MSVCPP.DLL, CRTDLL.DLL

MSVCRT.DLL은 비주얼 C++ 버전 4.2부터 6.0까지의 마이크로소프트 비주얼 C 런타임 라이브러리(C++ 라이브러리로는 MSVCPP.DLL)이다. 이것은 이 버전의 비주얼 C++로 컴파일된 프로그램과 C와 C++ 프로그램이 요구하는 일반적인 라이브러리 함수 집합들을 제공한다. 이것들은 문자열 처리와 메모리 할당 그리고 C 스타일 입출력 호출같은 것들을 포함한다.

이것은 윈도우 95 OSR2 버전 이후로 계속되어 왔으며, 이전 버전은 대신 CRTDLL.DLL 라이브러리였다. 오래된 윈도우 버전에서는 MSVCRT.LL에 링크된 프로그램의 호환되는 복사본을 System32 폴더 안에다가 설치하게 했었는데, 이것은 DLL 지옥로 이어지게 된다.

4.0 이전의 비주얼 C++과 7.0 이후 버전은 각각의 버전마다 다른 이름들을 사용했다(MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL 등). 응용 프로그램들은 적절한 버전의 것들을 설치하도록 요구되었다.

마이크로소프트 비주얼 C++ 런타임은 윈도우에 포함되어 있다. 설치된 운영 체제보다 최신에 나온 런타임들은 비주얼 C++ 재배포 가능 패키지에서 구할 수 있다.

레퍼런스와 디버깅을 위한 런타임 라이브러리의 소스 코드들은 비주얼 C++에 포함되어 있다.(예를 들면 C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src안에).

이 런타임 라이브러리는 비주얼 C++로 쓰인 프로그램들에 의해 사용된다. 또한 MinGW 컴파일러에서도 사용된다. 몇몇 컴파일러들은 자신들만의 런타임 라이브러리를 가지고 있다.

다른 런타임 라이브러리

• ATL*.DLL - 액티브 탬플릿 라이브러리(Active Template Library)
• MFC*.DLL - 마이크로소프트 파운데이션 클래스 라이브러리(Microsoft Foundation Classes)
• MSVBVM60.DLL - 비주얼 베이직 6.0 가상 머신 (대신 비주얼 베이직 닷넷 프로그램에는 닷넷 프레임워크가 필요함)

닷넷 프레임워크 라이브러리

C#, 비주얼 베이직 닷넷, C++/CLI 그리고 .NET 언어로 쓰인 프로그램들은 닷넷 프레임워크를 요구한다. 이것은 많은 라이브러리들과 (예를 들면 mscorlib.dll — Multilanguage Standard Common Object Runtime Library, 이전의 마이크로소프트 공통 오브젝트 런타임 라이브러리(Common Object Runtime Library)) 어셈블리라고 불리는(예를 들면 System.Windows.Forms.dll) 많은 라이브러리를 가지고 있다.

같이 보기

• 윈도우 NT 아키텍처
• 윈도우 NT 시작 프로세스
• 윈도우 API
• 동적 링크 라이브러리

각주

외부 링크

• (영어) API calls list - USER32.DLL - Tips for using the User API Client Library with Visual Basic
• (영어) API calls list - KERNEL32.DLL - Tips for using the Kernel API Client Library with Visual Basic
• (영어) Native API reference
• (영어) Unofficial website that documents most of the Native API methods Archived 2012년 10월 31일 - 웨이백 머신
• (영어) Retrieving the KERNEL32.DLL base address

구글 디벨로퍼스(영어: Google Developers)는 개발자 도구, API, 기술 리소스를 위한 구글의 사이트이다. 이 사이트에는 구글 개발자 도구 및 API 이용에 관한 문서가 포함되어 있으며 구글의 개발자 제품을 이용하는 개발자들을 위한 토론 그룹과 블로그를 아우른다.

이 API를 통해 구글 지도, 유튜브, 구글 앱스 따위의 구글의 유명한 소비자 제품들 가운데 거의 대부분을 제공하였다.

또한 이 사이트는 개발자들에 특화된 다양한 개발자 제품과 도구를 제공한다. 구글 앱 엔진은 웹 애플리케이션을 위한 호스팅 서비스이다. 프로젝트 호스팅은 사용자에게 오픈 소스 코드를 위한 버전 관리 기능을 제공한다. 구글 웹 툴킷(GWT)은 개발자가 Ajax 응용 프로그램들을 자바 프로그래밍 언어로 개발할 수 있게 도와 준다.

이 사이트는 구글이 오픈 핸드셋 얼라이언스와 오픈소셜 (오픈소셜 재단)로부터 안드로이드를 포함한 개발자 제품을 대상으로 하는 커뮤니티를 위한 참조 정보를 포함하고 있다.

구글의 API

• 구글 데이터 API
• Ajax API
• Ads API

개발자 도구 및 오픈 소스 프로젝트

• 앱 엔진
• 이클립스용 구글 플러그인
• 구글 웹 툴킷
• 프로젝트 호스팅
• 기어스

접근 제한

쿠바, 이란, 리비아, 조선민주주의인민공화국, 수단, 시리아 등의 국가는 접근이 제한된다.

구글 개발자 그룹(GDG)

구글 개발자 그룹(Google Developer Groups, GDG)은 안드로이드, 앱 엔진, 크롬, Maps API 등 다양한 Google 관련 기술에 관심을 가진 개발자 커뮤니티 그룹이다.

GDG는 2013년 1월 17일 기준으로 98개 국가에 351개의 챕터를 두고 있다.

대한민국은 현재 안드로이드, 크롬, 앱 엔진, Dart, Go 언어와 같이 기술별 GDG와 서울, 수원, 세종, 부산 등 지역별 GDG 등 총 9개의 GDG가 활동중이다. Google 관련 기술이라고 해서 반드시 안드로이드나 크롬 등만 다루는 것은 아니고 알고리즘 스터디, 미니 해커톤, 전체 개발자 컨퍼런스 등을 개최하며 왕성하게 활동중이다.

구글 개발자 행사

• 구글 I/O
• 구글 개발자의 날
• GSoC
• 구글 코드 잼

같이 보기

• 코드플렉스
• 소스포지
• GitHub

각주

외부 링크

• 구글 디벨로퍼스 - 공식 웹사이트
• A detailed list of the features of Google Code - Project Hosting
• 대한민국 GDG 현황

EGL은 (OpenGL, OpenGL ES 또는 OpenVG와 같은) 크로노스 렌더링 API와 기본 네이티브 플랫폼 윈도우 시스템 간의 인터페이스이다. EGL은 그래픽 컨텍스트 관리, 서피스/버퍼 바인딩, 렌더링 동기화를 처리하고 "다른 크로노스 API를 사용하여 고성능, 가속화된, 혼합모드 2D 및 3D 렌더링"을 가능하게 한다. EGL 비영리 기술 컨소시엄 크로노스 그룹에 의해 관리되고 있다.

약어 EGL은 Khronos Native Platform Graphics Interface에 언급되어 EGL 버전 1.2부터 시작된 initialism이다. 버전 1.2이전에는 EGL 스펙의 이름이 OpenGL ES Native Platform Graphics Interface였다. X.Org 개발 문서 용어집에서는 EGL을 "Embedded-System Graphics Library"로 정의한다.

채택

• BlackBerry 10와 BlackBerry Tablet OS 모바일 장치의 운영체제는 3D 그래픽 렌더링을 위해 EGL을 사용한다. Both support EGL version 1.4.
• 안드로이드 모바일 장치 운영 체제는 3D 그래픽 렌더링을 위해 EGL을 사용한다.
• Wayland 디스플레이 서버 프로토콜은 EGL을 사용한다. Wayland 클라이언트가 EGL을 사용하여 프레임버퍼에 직접 그려주는 방식으로 구현되었다.
• 메사 3D는 이전에 이글(Eagle)로 알려진 EGL을 구현했다.
• 캐노니컬에 의한 Mir 디스플레이 서버 프로토콜은 EGL을 사용한다.
• SDL(Simple DirectMedia Layer) 툴킷은 EGL을 사용하기 위해 포팅되었다. 프레임버퍼에 직접 쓰기위해 Xlib을 사용하거나 EGL을 사용할 수 있다.
• Raspberry Pi 싱글 보드 컴퓨터는 하드웨어 가속 3D 그래픽 랜더링에 EGL 인터페이스를 가지고 있다.
• 2013년 10월 4일부터 독점적인 엔비디아 드라이버 331.13 BETA는 EGL API를 지원한다.
• 타이젠(Tizen) OS는 3D 그래픽 렌더링을 위해 OpenGL ES 1.1 또는 OpenGL ES 2.0과 함께 EGL을 사용한다

구현

• 메사는 많은 그래픽 렌더링 API들의 자유-오픈 소스 소프트웨어 구현이다. EGL도 그중 하나이다.
• 일반 버퍼 관리(Generic Buffer Management)는 버퍼를 관리하는 API이다.

같이 보기

• WGL – OpenGL에 상응하는 윈도우 인터페이스
• CGL – OpenGL에 상응하는 OS X 인터페이스
• GLX – OpenGL에 상응하는 X11 인터페이스
  • AIGLX – GLX를 가속화 하기 위한 시도
• WSI – Vulkan 윈도우 시스템 인터페이스 (WSI)는 OpenGL ES을 위해 EGL이 수행하는 작업을 Vulkan을 위해 수행.

각주

외부 링크

• EGL - 공식 웹사이트

소프트웨어 개발 키트(영어: Software Development Kit, SDK)는 일반적으로 소프트웨어 기술자가 사용하여 특정한 소프트웨어 꾸러미, 소프트웨어 프레임워크, 하드웨어 플랫폼, 컴퓨터 시스템, 게임기, 운영 체제 등을 위한 응용 프로그램 등을 만들 수 있게 해주는 개발 도구의 집합이다. 응용 프로그램을 만들기 위해서는 특정한 SDK를 다운로드 받아야 하는데, 안드로이드 앱 개발을 위해서는 자바를 포함한 SDK, iOS 개발을 위해서는 Swift가 포함된 iOS SDK, MS Windows를 위해서는 .NET을 포함한 .NET Framework SDK가 필요하다. 또한 구글이나 페이스북같이 분석과 활동에 대한 데이터를 제공하기 위해 SDK가 앱에 설치되어 있는 경우도 있다.

소프트웨어 개발 키트에는 여러가지가 복합적으로 들어가 있을 수 있지만, 라이브러리 모양의 응용 프로그램 프로그래밍 인터페이스(API)가 하나 혹은 여러개 들어가있는 간단한 구조로 된 것도 있는데, 보통 그런 것들은 특정 프로그래밍 언어에 접속할 수 있게 하거나 특정한 임베디드 시스템(Embedded system)에 접속할 수 있는 복잡한 하드웨어를 포함시키기 위한 것들이 대부분이다. 공통 도구에는 디버깅 기능과 다른 유틸리티들이 포함되며, 종종 통합 개발 환경(IDE)의 형태로 포함되어 있다. 또한 SDK는 대부분 샘플 코드와 기술 참고 및 지원 문서를 지원하므로, 사용자에게 명확한 사용법이나 해결책을 제공해줄 수 있다.

일반적으로 소프트웨어 엔지니어는 해당 시스템의 개발자로부터 소프트웨어 개발 키트(SDK)를 받게 되는데, 많은 경우 해당 시스템이나 언어를 사용하는 것을 장려하기 위해서 무료로 제공된다. 종종 인터넷으로도 다운로드가 가능하다.

예시

• 다이렉트X SDK
• 자바 SDK
• 소스 SDK

같이 보기

• 응용 프로그램 프로그래밍 인터페이스(API)
• 네이티브 개발 키트(Native Development Kit)
• 위젯 툴킷

각주