Т.к. последнее время я неоднократно встречал вопросы «Что же такое .NET» то, IMHO, единственным правильным решением было написание заметки о том, что же это такое - .NET.
В данной статье я не буду использовать всевозможные рекламные словечки типа "распределенные", "Internet",
"высокопродуктивная", "безопасная" и прочая. Это оставим на совести продавцов. Постараюсь коснуться именно главного – из чего состоит и как работает.
Дальнейшие статьи (а я надеюсь, что я буду делать это более регулярно, чем раньше) буду посвящать различным аспектам программирования под .NET. Само собой все ваши замечания будут приняты с благодарностью и учтены в дальнейшей работе.

Итак, начнем.

Из чего состоит .NET Framework.
.NET Framework состоит из двух основных частей:
1. Среда исполнения
2. Библиотека классов

Среда исполнения
Наверно самое простое объяснение будет выглядеть так – это программа, которая выполняет команды Вашей программы. По сути это интерпретатор. Когда с помощью компилятора какого-либо языка для .NET вы собираете (компилируете) Вашу программу Вы получаете не реальные команды процессора, а некие абстрактные команды, байт-код, промежуточный ассемблер – как Вам удобнее понимать. Т.е. кто помнит QBasic, тот должен помнить, что там команды исполнялись по строчкам. Строка сразу интерпретировалась и исполнялась. В .NET это несколько оптимизировано – среда исполнения работает не с текстом программы, а с уже оптимизированным байт-кодом на языке MSIL - Microsoft Intermediate Language.
На само деле все несколько сложнее – Ваше приложение загружает библиотеку mscorlib.dll и передает управление ей. И уже эта библиотека (которая работает само собой не на MSIL, а на реальных командах процессора)выполняет Ваш код. Кроме этой библиотеки в каталоге с установленной средой исполнения находится еще немало библиотек, но о них речь сегодня мы вести не будем. После загрузки Вашего приложения в память начинается его исполнение. Но и здесь продолжается оптимизация его работы – используется JIT компилятор (Just In Time). Этот компилятор занимается тем, что при первой загрузке кода на MSIL, преобразует его в реальные команды процессора и в дальнейшем Ваше приложение будет использовать уже не MSIL, а полученный код. Такое поведение особенно хорошо видно, когда вы открываете форму с большим количество компонентов, потом закрываете ее и после открываете опять. Первый раз, даже на глаз видно, что система работает гораздо медленнее, чем в последующие.

Как Вы наверно уже поняли, для того, что бы программы написанные под .NET могли быть запущены на другом компьютере, на нем должна быть установлена среда исполнения (устанавливается она в каталог \WINDOWS\Microsoft.NET\Framework\<номер версии>).
Если на компьютере, на котором Вы запускаете свою программу .NET Framework не установлена, то будет выдано, что система не может найти библиотеку mscorlib.dll (о которой я уже упоминал) и само собой дальше этого ничего не пойдет.
По поводу совместимости - на самом деле нормально все это работает начиная с Windows 2000. Хоть и объявлено, что должно работать на Windows 98, Me и Windows NT 4 SP6, но (во всяком случае первая версия .NET) работало это с большим количеством глюков. Так что используйте 2000 или XP.

Что же это нам дает:
1. Возможность повышенной безопасности – Ваша программа не может делать больше того, что ей разрешается. Вы можете с меньшими опасениями использовать незнакомые программы из Internet.
2. Возможность использовать любые языки программирования, которые подпадают под спецификацию - Common Language Specification (CLS) в одном проекте. Почему такое возможно должно быть достаточно очевидно – компилятор любого высокоуровневого языка, удовлетворяющий спецификации, может породить корректный код на MSIL, который в свою очередь без каких-либо проблем будет интерпретироваться средой выполнения.
3. Т.к. код является управляемым, то возникают дополнительные возможности типа метаданных, т.е. данных о самих данных. Вы можете на лету определить тип данных, и даже создать новый тип, скомпилировать и выполнить его.
4. Исчезает «ад dll». Кто уже писал много программ или хотя бы устанавливал много программ, знает, что часто динамические библиотеки могут иметь разные версии, могут быть вообще разными, но иметь одно имя. И все они почему-то хотят стоять в каталоге WINDOWS\System32. Чтобы уметь управлять всем этим хаосом надо немало потрудится. В .NET предполагается, что все, что относится к Вашему приложению должно лежать в одном каталоге и никаких противоречий быть не должно. Мало того, используя механизм метаданных, Вы можете установить точно – какой версии dll будет использоваться Вашим приложением. И никакая другая версия ему не подойдет.
5. Из вышеизложенного должно быть понятно, что система исполнения работает поверх ОС. Таким образом Ваша программа не должна работать с ОС напрямую. Это обеспечивает устойчивость и безопасность системы в целом. Но тем не менее без каких-либо особых затрат Вы можете писать приложения, которые будут работать в операционной системой напрямую. Это может быть обращение к обычным dll или использование так называемого «неуправляемого кода», который будет выполняться как обычный код.

Думаю, что этого объяснения должно быть достаточно для понимания того, что из себя представляет среда исполнения.

Рассмотрим Библиотеку классов
Библиотека классов охватывает просто огромные объемы всевозможных классов и компонент, которые служат для облегчения работы со всевозможными системами и технологиями. Это XML и базы данных, работа с сетевыми ресурсами, технологии SOAP, графическая подсистема. Используя эту библиотеку, Вы можете писать всевозможные виды приложений. Вот список от Microsoft:

- Console applications.
- Windows GUI applications (Windows Forms).
- ASP.NET applications.
- XML Web services.
- Windows services

Как видите, выбор покрывает практически все, что только можно себе представить. На нашем форуме уже есть темы, где рассматриваются некоторые классы этой огромной библиотеки.

Наверно на этом можно закончить предварительное знакомство с .NET. До скорых встреч.

Никак не могу понять - является ли .NET просто оболочкой над WinAPI?
Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API..
Или я не прав? Тут все функции переписаны?..

Оболочкой для WinAPI является MFC
При программировании с использованием FCL забудьте об API,MFC,COM,CORBA и так далее
это совет от MICROSOFT

Цитата(AntonSaburov @ 3.2.2004, 17:44)

По поводу совместимости - на самом деле нормально все это работает начиная с Windows 2000. Хоть и объявлено, что должно работать на Windows 98, Me и Windows NT 4 SP6, но (во всяком случае первая версия .NET) работало это с большим количеством глюков. Так что используйте 2000 или XP.

А как на счет Linux'a?

Под Linux?
Тяжко, хотя теоретически реализуемо.
Под Linux есть проект mono.
Но за 3 (по-моему..) года они не смогли обеспечить работу Windows Forms, а вот консольные приложения работают..
Оно и понятно, ведь поддержки толком никакой.
Вот если б M$ позаботился об этом также как Sun о Java..

З.Ы. Сам еще не пробовал..

Слышал что приложения .NET под Линухом бегают очень быстро...
К сожалению сам не опровергнуть не потвердить информацию не могу...

Цитата(Kurt @ 26.2.2004, 20:00)

Никак не могу понять - является ли .NET просто оболочкой над WinAPI? Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API.. Или я не прав? Тут все функции переписаны?.. ???

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET. В MS говорят, что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде.

Цитата(arilou @ 16.7.2004, 05:37)

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET. В MS говорят, что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде.

а что будеь с ассемблером когда выйдет Longhorn??? как на нем будет писать под .NET не используя эмуляции WinAPI

Deeoni$
Честно говоря, даже не знаю, как-то не задумывался о судьбе ассемблера. Наверное, IL придет ему на замену

Цмтата с одного инф сервера:

Цитата

...Windows Longhorn будет основан на технологии .NET, а приложения Win32(API) будут выполняться в режиме эмуляции...

Но вот вопрос насколко хорошо будет реализована эмуляция???
Кстати, скажите ,плз, что такое IL?

Цитата(ReSeT @ 19.8.2004, 14:46)

Но вот вопрос насколко хорошо будет реализована эмуляция??? Кстати, скажите ,плз, что такое IL?

Насчет качества эмуляции не знаю, но наверное хуже чем Win 95 - Win 3.11 не будет
А нсчет MSIL -

Цитата(AntonSaburov @ 3.2.2004, 17:44)

Среда исполнения Наверно самое простое объяснение будет выглядеть так – это программа, которая выполняет команды Вашей программы. По сути это интерпретатор. Когда с помощью компилятора какого-либо языка для .NET вы собираете (компилируете) Вашу программу Вы получаете не реальные команды процессора, а некие абстрактные команды, байт-код, промежуточный ассемблер – как Вам удобнее понимать. Т.е. кто помнит QBasic, тот должен помнить, что там команды исполнялись по строчкам. Строка сразу интерпретировалась и исполнялась. В .NET это несколько оптимизировано – среда исполнения работает не с текстом программы, а с уже оптимизированным байт-кодом на языке MSIL - Microsoft Intermediate Language.

Цитата

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET.

Цитата

Честно говоря, даже не знаю, как-то не задумывался о судьбе ассемблера. Наверное, IL придет ему на замену

У меня уже стоИт Longhorn build 4074, эмуляция эта работает ч\з раз, а то и ч\з два - некоторые программы (в частности, использующие RASAPI, IMAP и т.п.) иногда вообще не запускаются, т.е. процесс создается, а форма не рисуется - может программа и работает, но отсутствие GUI делает общение с приложением весьма затруднительным ... а иногда все нормально пашет.
Что касается ассемблера, то fasm программы у меня работают нормально (правда ничего серьезного не запускал, так - свои побрякушки). IL придет на смену API, скорее всего придется нам учить этот новый "Microsoft Intermediate Language" и в include пхать модули с описанием IL констант и функций.
Ну а за судьбу чистого асма (ч\з прерывания, стэк, регистры и т.д. работающего) я спокоен
Если только M$ не прикупит вслед за Borland еще и Intel с AMD
-
Надо срочно искать D8.

Цитата

По сути это интерпретатор

Не совсем согласен. Интерпретатор исполняет текстовые команды, а в .НЕЕЕЕЕЕТ сначала происходит JIT-компиляция. Т.е. при вызове какогонить метода Just-In-Time компилятор сначала компилит IL-код а потом исполняет уже откомпиленный код.

Цитата(Run @ 9.2.2005, 12:20)

Не совсем согласен. Интерпретатор исполняет текстовые команды, а в .НЕЕЕЕЕЕТ сначала происходит JIT-компиляция.

А внимательнее читать не пробовал ?

Цитата(AntonSaburov @ 3.2.2004, 17:44)

После загрузки Вашего приложения в память начинается его исполнение. Но и здесь продолжается оптимизация его работы – используется JIT компилятор (Just In Time). Этот компилятор занимается тем, что при первой загрузке кода на MSIL, преобразует его в реальные команды процессора и в дальнейшем Ваше приложение будет использовать уже не MSIL, а полученный код.

Цитата(arilou @ 16.7.2004, 14:37)

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET.

Интересно посмотреть как высокоуровневыми средствами можно эмулировать низкоуровневый WinAPI.