АДав. API новый. Контрольные вопросы Что такое api Дайте развернутый ответ Для чего нужен api Дайте развернутый ответ

Название	Контрольные вопросы Что такое api Дайте развернутый ответ Для чего нужен api Дайте развернутый ответ
Дата	11.04.2023
Размер	52.96 Kb.
Формат файла
Имя файла	API новый.docx
Тип	Контрольные вопросы #1053602

Практическая работа

Интерфейсы прикладного программирования

Цель: Сформировать представление о интерфейсах прикладного программирования

Задачи:

Ознакомиться с примерами различных интерфейсов прикладного программирования;

Задание:

Ответить на контрольные вопросы

Оснащение:

Персональный компьютер, методические указания

Контрольные вопросы:

Что такое API? Дайте развернутый ответ;
Для чего нужен API? Дайте развернутый ответ;
Что представляет сигнатура функций?
Что такое семантика функций? Дайте развернутый ответ;
Что представляет API операционных систем? Какие задачи решает? Дайте развернутый ответ;
Приведите примеры наиболее известных API;
Для чего нужен OpenGL ? Дайте развернутый ответ;
Для чего нужен Pluggable Authentication Modules? Дайте развернутый ответ;
Для чего нужен DirectX ? Дайте развернутый ответ;
Для чего нужен OpenAL? Дайте развернутый ответ;
Сравните OpenGL и DirectX; Опишите общие функции и их различия.
Что такое Windows API? Для чего он нужен? Дайте развернутый ответ;
Что такое Wine? Для чего он нужен? Дайте развернутый ответ;
Что такое .NET Framework? Для чего он нужен? Дайте развернутый ответ.

Теоретический материал

API (англ. application programming interface, API [эй-пи-ай]) — интерфейс программирования приложений, интерфейс прикладного программирования, набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется программистами при написании всевозможных приложений.

API как средство интеграции приложений

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика и которые он может вертеть и дёргать.

Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.

По такому принципу построены протоколы передачи данных по Интернет. Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.

Важно заметить, что понятие протокола близко по смыслу к понятию API. И то, и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором — о взаимодействии приложений.

API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

Сигнатура функции

Сигнатура функции — часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функций в этих языках.

Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

Например, в языке программирования C++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.

В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип значения в сигнатуре не участвует.

Семантика функции

Семантика функции — это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.

API операционных систем. Проблемы, связанные с многообразием API

Практически все операционные системы (UNIX, Windows, OS X и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.

В индустрии программного обеспечения общие стандартные API для стандартной функциональности имеют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере, типичным привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов WxWidgets, Qt, GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах (sh, python, perl, php, tcl, Java и т. д.).
Также необходимо отметить, что в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.

Например: для того, чтобы увидеть в браузере строчку «Hello, world!», достаточно лишь создать HTML-документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ, программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

Наиболее известные API

Операционных систем

Amiga ROM Kernel
Cocoa
Linux Kernel API
OS/2 API
POSIX
Windows API

Графических интерфейсов

Direct3D (часть DirectX)
DirectDraw (часть DirectX)
GDI
GDI+
GTK
Motif
OpenGL
OpenVG
Qt
SDL
Tk
WxWidgets
X11
Zune

Звуковых интерфейсов

DirectMusic (часть DirectX)
DirectSound (часть DirectX)
OpenAL

Аутентификационных систем

BioAPI
PAM

OpenGL (Open Graphics Library) — спецификация, определяющая независимый от языка программирования платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику.

Включает более 300 функций для рисования сложных трёхмерных сцен из простых примитивов. Используется при создании компьютерных игр, САПР, виртуальной реальности, визуализации в научных исследованиях. На платформе Windows конкурирует с Direct3D.

На базовом уровне, OpenGL — это просто спецификация, то есть документ, описывающий набор функций и их точное поведение. Производители оборудования на основе этой спецификации создают реализации — библиотеки функций, соответствующих набору функций спецификации. Реализация призвана эффективно использовать возможности оборудования. Если аппаратура не позволяет реализовать какую-либо возможность, она должна быть эмулирована программно. Производители должны пройти специфические тесты (conformance tests — тесты на соответствие) прежде чем реализация будет классифицирована как OpenGL-реализация. Таким образом, разработчикам программного обеспечения достаточно научиться использовать функции, описанные в спецификации, оставив эффективную реализацию последних разработчикам аппаратного обеспечения.

Эффективные реализации OpenGL существуют для Windows, Unix-платформ, PlayStation 3 и Mac OS. Эти реализации обычно предоставляются изготовителями видеоадаптеров и активно используют возможности последних. Существуют также открытые реализации спецификации OpenGL, одной из которых является библиотека Mesa. Из лицензионных соображений Mesa является «неофициальной» реализацией OpenGL, хотя полностью с ней совместима на уровне кода и поддерживает как программную эмуляцию, так и аппаратное ускорение при наличии соответствующих драйверов.

Спецификация OpenGL пересматривается консорциумом ARB (Architecture Review Board), который был сформирован в 1992 году. Консорциум состоит из компаний, заинтересованных в создании широко распространённого и доступного API. Согласно официальному сайту OpenGL, членами ARB с решающим голосом на ноябрь 2004 года являются производители профессиональных графических аппаратных средств SGI, 3Dlabs, Matrox и Evans & Sutherland (военные приложения), производители потребительских графических аппаратных средств ATI и NVIDIA, производитель процессоров Intel, и изготовители компьютеров и компьютерного оборудования IBM, Apple, Dell, Hewlett-Packard и Sun Microsystems, а также один из лидеров компьютерной игровой индустрии id Software. Microsoft, один из основоположников консорциума, покинула его в марте 2003 года. Помимо постоянных членов, каждый год приглашается большое количество других компаний, становящихся частью OpenGL ARB в течение одного года. Такое большое число компаний, вовлеченных в разнообразный круг интересов, позволило OpenGL стать прикладным интерфейсом широкого назначения с большим количеством возможностей.

Курт Экли (Kurt Akeley) и Марк Сигал (Mark Segal) являются авторами оригинальной спецификации OpenGL. Крис Фрэзиер (Chris Frazier) редактировал версию 1.1. Йон Лич (Jon Leech) редактировал версии с 1.2 по версию 2.0.

OpenGL ориентируется на следующие две задачи:

Скрыть сложности адаптации различных 3D-ускорителей, предоставляя разработчику единый API.
Скрыть различия в возможностях аппаратных платформ, требуя реализации недостающей функциональности с помощью программной эмуляции.

Основным принципом работы OpenGL является получение наборов векторных графических примитивов в виде точек, линий и треугольников с последующей математической обработкой полученных данных и построением растровой картинки на экране и/или в памяти. Векторные трансформации и растеризация выполняются графическим конвейером (graphics pipeline), который по сути представляет собой дискретный автомат. Абсолютное большинство команд OpenGL попадают в одну из двух групп: либо они добавляют графические примитивы на вход в конвейер, либо конфигурируют конвейер на различное исполнение трансформаций.

OpenGL является низкоуровневым процедурным API, что вынуждает программиста диктовать точную последовательность шагов, чтобы построить результирующую растровую графику (императивный подход). Это является основным отличием от дескрипторных подходов, когда вся сцена передается в виде структуры данных (чаще всего дерева), которое обрабатывается и строится на экране. С одной стороны, императивный подход требует от программиста глубокого знания законов трёхмерной графики и математических моделей, с другой стороны — даёт свободу внедрения различных инноваций.

DirectX (от англ. direct — прямой, непосредственный) — это набор API, разработанных для решения задач, связанных с программированием под Microsoft Windows. Наиболее широко используется при написании компьютерных игр.

В целом, DirectX подразделяется на:

DirectX Graphics, набор интерфейсов, ранее (до версии 8.0) делившихся на:

DirectDraw: интерфейс вывода растровой графики. (Его разработка давно прекращена)
Direct3D (D3D): интерфейс вывода трёхмерных примитивов.
DirectInput: интерфейс, используемый для обработки данных, поступающих с клавиатуры, мыши, джойстика и пр. игровых контроллеров.
DirectPlay: интерфейс сетевой коммуникации игр.
DirectSound: интерфейс низкоуровневой работы со звуком (формата Wave)
DirectMusic: интерфейс воспроизведения музыки в форматах Microsoft.
DirectShow: интерфейс, используемый для ввода/вывода аудио и/или видео данных.
DirectX Instruments — технология, позволяющая на основе мультимедийного API DirectX создавать и использовать программные синтезаторы. В отличие от DX-плагинов, такие программы могут полностью управляться по MIDI и служат главным образом не для обработки, а для синтеза звука. Технология DXi была популярна в 2001—2004 гг., особенно в программных продуктах Cakewalk, но со временем проиграла «войну форматов» технологии VST от Steinberg.
DirectSetup: часть, ответственная за установку DirectX.
DirectX Media Objects: реализует функциональную поддержку потоковых объектов (например, кодировщики/декодировщики)
Direct2D: интерфейс вывода двухмерной графики

Изначально нацеленный на разработку видеоигр, DirectX стал популярен и в других областях разработки программного обеспечения. К примеру, DirectX, наряду с OpenGL, получил очень широкое распространение в инженерном/математическом ПО.

В 1994 году Microsoft была практически готова выпустить следующую версию Windows — Windows 95. Главным фактором, определяющим, насколько популярна будет новая ОС, являлся набор программ, которые можно будет запускать под её управлением. В Microsoft пришли к выводу, что, пока разработчики видят DOS более подходящей для написания игровых приложений, коммерческий успех новой ОС весьма сомнителен.

DOS позволяла разработчику получить прямой доступ к видеокарте, клавиатуре/мыши/джойстику и прочим частям системы, в то время как Windows 95, с её защищённой моделью памяти, предоставляла более стандартизованный, но в то же время весьма ограниченный и накладный доступ к устройствам. Microsoft нуждалась в новом способе дать разработчику всё, что ему необходимо. Айслер (Eisler), Сэйнт Джон (St. John), и Энгстром (Engstrom) решили эту проблему, назвав само решение DirectX.

Первый релиз DirectX был выпущен в сентябре 1995 года, под названием «Windows Game SDK».

Ещё до появления DirectX, Microsoft включила OpenGL в ОС Windows NT. Direct3D позиционировался как замена OpenGL в игровой сфере. Отсюда берёт своё начало «священная война» между сторонниками кросс-платформенной OpenGL и доступной лишь в Windows (в том числе Windows NT) Direct3D. Так или иначе, остальные части DirectX очень часто комбинируются с OpenGL в компьютерных играх, так как OpenGL как таковой не подразумевает функциональность уровня DirectX (например, доступ к клавиатуре/джойстику/мыши, поддержка звука, игры по сети и т. д.).

OpenAL (англ. Open Audio Library) — кроссплатформенный интерфейс программирования приложений (API) для работы с аудиоданными. Ключевой особенностью является работа со звуком в 3D пространстве и использование эффектов EAX. Поддерживается компанией Creative.

OpenAL создан фирмой Loki Software как инструмент для их бизнеса — портирование игр с Microsoft Windows на GNU/Linux. После закрытия компании проект некоторое время разрабатывался сообществом свободного ПО — оно добавило функционал звукового чипсета, встроенного в NVIDIA nForce. Сегодня проект размещён на сервере компании Creative Technology, и по большей части разрабатывается ей. Также проект активно развивают компании Apple, Blue Ripple Sound и сообщество свободного ПО.

Хотя хартия OpenAL гласит, что у проекта должен быть «Наблюдательный совет за архитектурой» (ARB), аналогичный проекту OpenGL ARB, до сих пор ни одна организация не взяла на себя обязанность сформировать стандарт технических спецификаций OpenAL. Спецификации OpenAL существуют в черновом варианте, обсуждаются разработчиками по электронной почте и в общедоступных списках рассылки.

Основные функции библиотеки OpenAL — исходные объекты, аудиобуферы, и единственный слушатель. Исходные объекты включают в себя указатель на буфер, скорость, позицию, направление и интенсивность звука. Слушатель содержит скорость, позицию, направление и общее усиление звука в целом. Буферы содержат аудиоданные в формате PCM в 8-ми либо 16-битном варианте, а также в моно или стерео. Функция рендеринга звука производит необходимые вычисления, такие как определение расстояния, эффекта Доплера, и так далее.

Для конечного пользователя результат обработки этих компонентов OpenAL даёт совершенно естественное звучание при перемещении персонажей в трёхмерном виртуальном мире. А программист может легко задействовать OpenAL в своей готовой трёхмерной OpenGL-программе.

В отличие от спецификаций OpenGL, спецификации OpenAL включают в себя два API: ядро, включающее в себя вызовы функций OpenAL, и ALC (Audio Library Context) — API, используемый для управления контекстом рендеринга, контролем использования ресурсов и задействования блокировок в мультипоточных вычислениях. Также существует ALUT — библиотека, предоставляющая функции высокого уровня для упрощения написания программы, она аналогична библиотеке GLUT у OpenGL.

OpenAL расширяем: программисты, либо компании, не входящие в число разработчиков OpenAL, могут добавлять в него свои расширения. Например, для того чтобы «научить» библиотеку задействовать функции своих устройств с закрытыми спецификациями. Расширения могут быть повышены до уровня ARB, то есть войти в спецификации OpenAL в её новой версии.

Для расширенной обработки цифрового сигнала или аппаратного ускорения звука могут быть задействованы EFX (Effects Extension) или EAX.

Pluggable Authentication Modules (PAM, подключаемые модули аутентификации) — это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API. Это позволяет предоставить единые механизмы для управления, встраивания прикладных программ в процесс аутентификации. Является одной из частей стандартного механизма обеспечения безопасности UNIX-систем.

PAM была впервые предложена Sun Microsystems в октябре 1995 года. В качестве автономной инфраструктуры PAM впервые появился в Linux-PAM, разработанной в Red Hat Linux 3.0.4 в августе 1996 года. В настоящее время PAM поддерживается в операционных системах AIX, DragonFly BSD, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD и Solaris.

Windows API (англ. application programming interfaces) — общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Microsoft Windows корпорации «Майкрософт». Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, «Майкрософт» выпускает комплект разработчика программного обеспечения, который называется Platform SDK, и содержит документацию, набор библиотек, утилит и других инструментальных средств для разработки.

Windows API спроектирован для использования в языке Си для написания прикладных программ, предназначенных для работы под управлением операционной системы MS Windows. Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.
Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Сиcu. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие.

Для облегчения программирования под Windows, в компании Microsoft и сторонними разработчиками было предпринято множество попыток создать библиотеки и среды программирования, частично или полностью скрывающие от программиста особенности Windows API, и предоставляющие ту или иную часть его возможностей в более удобном виде. В частности, сама Microsoft в разное время предлагала библиотеки Active Template Library (ATL)/Windows Template Library (WTL), Microsoft Foundation Classes (MFC), .Net/WinForms/WPF. Компания Borland (ныне Embarcadero, её преемник в части средств разработки) предлагала OWL и VCL. Есть кросс-платформенные библиотеки, такие как Qt, Tk и многие другие. Весомая часть этих библиотек сконцентрирована на облегчении программирования графического интерфейса пользователя.

Для облегчения переноса на другие платформы программ, написанных с опорой на Windows API, сделана библиотека Wine.

Wine (/waɪn/ — между «уа́йн» и «вайн», рус. Вино) — свободное программное обеспечение, позволяющее пользователям UNIX-подобных систем архитектуры x86 (и других архитектур, при наличии совместимости, например, AMD64) исполнять 16-, 32- и 64- битные приложения Microsoft Windows (64-битные приложения находятся в стадии ранней реализации). Wine также предоставляет программистам библиотеку программ Winelib, при помощи которой они могут компилировать Windows-приложения для портирования их в UNIX-подобные системы. Название Wine является рекурсивным акронимом и расшифровывается «Wine Is Not an Emulator» — «Wine — не эмулятор» (имеется в виду, что Wine не является эмулятором компьютера, как, например, qemu или VirtualBox, Wine — это альтернативная реализация Windows API). Wine распространяется на условиях лицензии GNU LGPL.

Проект сталкивается с большими трудностями вследствие неполноты или отсутствия документации по многим элементам Win32 API. В то время как функции Win32 в основном документированы, существует масса областей (таких как файловые форматы или протоколы Microsoft), спецификации на которые никогда не публиковались. Таким образом, команде разработчиков Wine приходится заниматься обратной разработкой этих компонентов.

Wine воспринимает системные вызовы Windows-приложений к библиотекам операционной системы и подменяет их своими. Таким образом, эмуляции процессора, аналогично другим эмуляторам типа VMware и QEMU, не происходит, и приложения могут выполняться в Wine почти так же быстро, как и в «родной» операционной системе (а в некоторых случаях и быстрее). Для своей работы Wine не требует наличия установленной ОС Windows, хотя и может использовать её библиотеки.

Также Wine предоставляет инструментарий разработки программ Winelib для переноса унаследованных исходных кодов из среды Windows в среду UNIX путём простой перекомпиляции.

Wine, безусловно, не является стабильным продуктом, и нельзя сказать, что любую программу для Windows удастся запустить с его помощью. Некоторые подсистемы Windows вообще практически не реализованы. Тем не менее, уже сейчас многие из повсеместно используемых Windows-приложений полноценно запускаются и работают в UNIX-подобных ОС при помощи Wine. Особенно это касается приложений, которые не используют недокументированные возможности Windows. В Microsoft официально не делали никаких публичных заявлений по поводу Wine. Однако Microsoft Update будет блокировать обновления для программного обеспечения от Microsoft, если программы будут запущены в средах, основанных на Wine. 16 февраля 2005 Ivan Leo Puoti обнаружил, что Microsoft начала проверять системный реестр в поисках конфигурационных ключей, оставленных Wine и будет блокировать доступ к Windows Update для любого компонента. Windows Genuine Advantage (WGA) также проверяет на наличие ключей реестра от Wine. В WGA FAQ заявлено, что WGA, по своему предназначению, не будет работать в Wine, поскольку Wine не является «подлинной Windows». Когда проверка WGA определяет, что в системе запущен Wine, пользователю будет выдано сообщение, гласящее о том, что он запустил не подлинную Windows, и «загрузки ПО для подлинной Windows» не будут разрешены для этой системы. Тем не менее, было несколько сообщений о работе WGA в Wine, однако и эта возможность использования была закрыта в следующем обновлении компонента WGA. В случаях с Internet Explorer 7 и Windows Media Player, впоследствии, Microsoft удалила требования проверки WGA для установки. Несмотря на то, что Wine представляет собой довольно мощный программный продукт, у него есть определённые проблемы реализации. К примеру, разработчики намеренно не заявляют поддержку USB, однако по словам самих же разработчиковработа с USB драйверами возможна.

.NET Framework — программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), которая подходит для разных языков программирования. Функциональные возможности CLR доступны в любых языках программирования, использующих эту среду.

Считается, что платформа .NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).

Хотя .NET является патентованной технологией корпорации Microsoft и официально рассчитана на работу под операционными системами семейства Microsoft Windows, существуют независимые проекты (прежде всего это Mono и Portable.NET), позволяющие запускать программы .NET на некоторых других операционных системах.

Основной идеей при разработке .NET Framework являлось обеспечение свободы разработчика за счёт предоставления ему возможности создавать приложения различных типов, способные выполняться на различных типах устройств и в различных средах.

Вторым принципом стала ориентация на системы, работающие под управлением семейства операционных систем Microsoft Windows. Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах .NET получается сборка, англ. assembly. Затем код либо исполняется виртуальной машиной Common Language Runtime (CLR), либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Архитектура .NET Framework описана и опубликована в спецификации Common Language Infrastructure (CLI), разработанной Microsoft и утверждённой ISO и ECMA. В CLI описаны типы данных .NET, формат метаданных о структуре программы, система исполнения байт-кода и многое другое.
Объектные классы .NET, доступные для всех поддерживаемых языков программирования, содержатся в библиотеке Framework Class Library (FCL). В FCL входят классы Windows Forms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation, Windows Communication Foundation и другие. Ядро FCL называется Base Class Library (BCL).

Mono — проект по созданию полноценного воплощения системы .NET Framework на базе свободного программного обеспечения. Основной разработчик проекта Mono — компания Xamarin, ранее Novell. После заключения Microsoft договорённости с Novell платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах: Linux, Mac OS X и других. (Хотя Mono успешно работает и под Microsoft Windows). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft (претензии возможны только в странах, где существуют патенты на программное обеспечение). Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в то же время рекомендует не использовать эти API.