Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API..
Или я не прав? Тут все функции переписаны?..
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Что же такое .NET ? |
| Автор: AntonSaburov 3.2.2004, 17:44 |
| Т.к. последнее время я неоднократно встречал вопросы «Что же такое .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. До скорых встреч. |
| Автор: Kurt 26.2.2004, 20:00 |
| Никак не могу понять - является ли .NET просто оболочкой над WinAPI? Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API.. Или я не прав? Тут все функции переписаны?.. |
| Автор: Paradox 27.2.2004, 09:48 |
| Оболочкой для WinAPI является MFC При программировании с использованием FCL забудьте об API,MFC,COM,CORBA и так далее это совет от MICROSOFT |
| Автор: Dana 4.6.2004, 00:54 | ||
А как на счет Linux'a? |
| Автор: Kurt 4.6.2004, 01:08 |
| Под Linux? Тяжко, хотя теоретически реализуемо. Под Linux есть проект http://www.go-mono.com/. Но за 3 (по-моему..) года они не смогли обеспечить работу Windows Forms, а вот консольные приложения работают.. Оно и понятно, ведь поддержки толком никакой. Вот если б M$ позаботился об этом также как Sun о Java..  З.Ы. Сам еще не пробовал.. |
| Автор: chipset 4.6.2004, 07:06 |
| Слышал что приложения .NET под Линухом бегают очень быстро... К сожалению сам не опровергнуть не потвердить информацию не могу...  |
| Автор: arilou 16.7.2004, 13:37 | ||
На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET. В MS говорят, что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде. |
| Автор: Deeoni$ 5.8.2004, 22:39 | ||
а что будеь с ассемблером когда выйдет Longhorn??? как на нем будет писать под .NET не используя эмуляции WinAPI |
| Автор: arilou 6.8.2004, 12:08 |
| Deeoni$ Честно говоря, даже не знаю, как-то не задумывался о судьбе ассемблера. Наверное, IL придет ему на замену  |
| Автор: ReSeT 19.8.2004, 14:46 | ||
Цмтата с одного инф сервера:
Но вот вопрос насколко хорошо будет реализована эмуляция??? Кстати, скажите ,плз, что такое IL? |
| Автор: arilou 19.8.2004, 14:53 | ||||
Насчет качества эмуляции не знаю, но наверное хуже чем Win 95 - Win 3.11 не будет  А нсчет MSIL -
|
| Автор: DeeZ 26.11.2004, 01:55 | ||||
У меня уже стоИт Longhorn build 4074, эмуляция эта работает ч\з раз, а то и ч\з два - некоторые программы (в частности, использующие RASAPI, IMAP и т.п.) иногда вообще не запускаются, т.е. процесс создается, а форма не рисуется - может программа и работает, но отсутствие GUI делает общение с приложением весьма затруднительным  ... а иногда все нормально пашет.Что касается ассемблера, то fasm программы у меня работают нормально (правда ничего серьезного не запускал, так - свои побрякушки). IL придет на смену API, скорее всего придется нам учить этот новый "Microsoft Intermediate Language" и в include пхать модули с описанием IL констант и функций. Ну а за судьбу чистого асма (ч\з прерывания, стэк, регистры и т.д. работающего) я спокоен Если только M$ не прикупит вслед за Borland еще и Intel с AMD  - Надо срочно искать D8. |
| Автор: Exception 9.2.2005, 12:20 | ||
Не совсем согласен. Интерпретатор исполняет текстовые команды, а в .НЕЕЕЕЕЕТ сначала происходит JIT-компиляция. Т.е. при вызове какогонить метода Just-In-Time компилятор сначала компилит IL-код а потом исполняет уже откомпиленный код. |
| Автор: AntonSaburov 9.2.2005, 16:45 | ||||
А внимательнее читать не пробовал ?
|
| Автор: Петрович 9.2.2005, 22:02 | ||
Интересно посмотреть как высокоуровневыми средствами можно эмулировать низкоуровневый WinAPI. |
| Автор: Vex 10.2.2005, 00:11 | ||||
Они вроде собираются полностью переписать весь API, вроде будет называться WinFX.
Ну приложение обращается к .NET, а .NET в свою очередь к API, что мешает "интегрировать" в среде исполнения .NET функции, которые дает WinAPI... |
| Автор: [Last]Wizard 10.2.2005, 16:01 | ||
Да, а еще будет такая штука, как Avalon - замена стандартному GDI. Декларативное программирование и все такое... |
| Автор: Exception 10.2.2005, 19:25 | ||||||
Сам себе противоречишь:
Библиотека НЕ ИСПОЛНЯЕТ IL-код. Она его компилирует. Хоть и JIT. Если я не прав не злись а объясни, ОК? |
| Автор: Петрович 10.2.2005, 19:41 | ||||
Дык речь шла о
|
| Автор: Exception 11.2.2005, 16:01 |
| Тогда ОС надо бы назвать Windows .NET |
| Автор: $tatic 28.2.2005, 19:01 |
| Вся эта затея с Windows.NET (привет, Run-time error) мне кажется довольно стремной: полностью менять внутренности системы, эмулировать WinAPI и т.п. будет очень сложно даже самому Биллу Как мне кажется, такие извращения приведут к следующему: * Все программы, кроме .NET, уже написанные на настоящий момент (и по-любому использующие WinAPI), особенно игры, будут работать значительно медленнее (покупайте новый компьютер! ??? )* Эмуляция естественно будет глючить (любая программа содержит ошибку, при ее устранении появляются еще две ), а значит почти все программы (см. пункт выше) по принципу наследования будут глючить (в т.ч. и Винда - еще больше)* Эмуляция может не поддерживать очень сложных программ (как это было когда-то с эмуляцией MS DOS) * Так как код .NET полностью защитить (в настоящее время) нельзя, то воровства кода и крякинга (MSIL - это не ASM) будет еще больше (Неужели наступает пришествие Open source) Вот, вроде бы, все. Будет что-то еще - дополняйте. Кстати, Мелкософт может эмуляцию эту сделать по принципу VirtualPC (который они когда-то купили ). Т.е. фактически в отдельной тормозной (поскольку виртуальной) Винде. |
| Автор: chipset 28.2.2005, 19:35 | ||
А кто тебе сказал что это будут делать? |
| Автор: Domestic Cat 28.2.2005, 19:40 | ||
Так будут или нe будут? |
| Автор: $tatic 1.3.2005, 14:10 |
| Это лчно мое мнение. Скорее всего - нет. |
| Автор: WolfON 6.5.2005, 17:23 | ||
тут даже вопрос не в сложности [вполне реально], а впроизводительности, те старые преложения замедляться как минимум на 20% |
| Автор: РКК 28.5.2005, 22:08 |
| Господа, а все же что будет с асемблером? |
| Автор: Ch0bits 29.5.2005, 00:31 |
| Скорее .НЕТ исчезнет, чем ассемблер! |
| Автор: stab 29.5.2005, 18:34 | ||
Мне кажется, что ни чего во внутренностях переделывать не будут, просто, сверху навесят .NET и в дальнейшем будут наращивать только его возможности, все новые API публично будут доступны только через .NET сборки, например, тот же Avalon, который уже сейчас работает под Windows XP и которой будет частью Longhorn. Не ясно откуда вобще появилась идея эмуляции Win32 API, технология .NET под Windows опирается на Win32 API, а это тонны отлаженного кода, полученного большой кровью, сомневаюсь, что кто-то будет рубить сук на котором сидит. |
| Автор: NixoL 8.6.2005, 20:27 |
| 2Петрович : низкоуровневый WinAPI !!!???? |
| Автор: nikf 8.6.2005, 20:51 |
| если писать прогу под DOS она будет работать везде и без API. вот только одна эмуляция от доса к сожалению осталась, DirectDraw работает без GDI. Эмуляция GDI в частности, и APi в целом не такая уж кощунственная идея... асм пока никуда не денется, а вот все надстройки над апи(VCL MFC) уже сейчас не так актуальны, в большинстве случаев они нужны для поддержки старых проектов. Сейчас нет смысла использовать эти библиотеки в новых проектах, при возможности использования сретств дотнет.. |
| Автор: neutrino 31.8.2005, 23:30 |
| Не понимаю... На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API. API останется и никакой эмуляции не будет. И вообще не надо пользоваться API, иначе ваши приложения будут не кросплатформенными. Кстати, что там с .NET в Linux и в MacOS? Мне кажется воняет мертвичиной. Надо переходить на Java. Там реальная кросплатформенность, а не ее подражание. Чего стоит .NET без нее? |
| Автор: Ch0bits 1.9.2005, 00:54 |
| Во-во! Правильно говоришь. Я про енто чудо-юдо МелкоНЕТ уже забыл давно. |
| Автор: Denn 1.9.2005, 09:08 |
| Цитата из Рихтера: в далеком будущем планируется, что процессор будет поддерживать IL. ЖУТЬ! |
| Автор: neutrino 1.9.2005, 09:30 | ||
ИМХО не реально. В IL переменные, а не адреса. ЦП не может оперировать данными в такой абстрактной (относительно) форме. |
| Автор: mr.DUDA 1.9.2005, 10:25 | ||
Что такое переменная ? Адрес в памяти. |
| Автор: arilou 1.9.2005, 11:48 | ||
Во-первых,
Не ну можно было почитать немного прежде чем выражать сомнение и непонимание? Не надо называть IL байт-кодом, потому что
IL - это не p-code из VB6, который интерпретировался при помощи VBRUNx00.DLL. Во-вторых, На .NET framework никто ОС писать не собирается. Вы слышали про такое понятие "уровень абстракции" ? Вы писали бизнес-приложения для платформы Windows, которые бы работали с COM+, SQL Server, BizTalk и другими серверными платформами? API - метрв. Он не будет расширяться и дорабатываться. Он останется, как режим совместимости для старых программ. MFC, VCL и проч. упрощали работу с WinAPI, за что им большое спасибо. Как сейчас помню программы из тысяч строк кода на C, которые окно отрисовывали и мышкой в нем линии выводить позволяли под Win 3.0. Нельзя бесконечно тюнинговать Запорожец - рано или поздно это перестанет приносить выгоду. Так же и в программировании. А решать умозрительные задачи, типа реализовать синглтон без статиков, это пусть на олимпиадах студенты делают, алгоритмизацию свою прокачивают. В реальном мире, где программер зарабатывает созданием бизнес-приложений, это не нужно. Нужно уметь в сроки укладываться и программы стабильные выпускать. Так вот такой уровень абстракции над сервисами ОСи и дает эту возможность. Вот. |
| Автор: Denn 1.9.2005, 12:28 | ||
Это возможно, но только не в ближайшем будущем. Для того, чтобы .NET стала действительно стОящей системой, ее еще развивать и вазвивать. Я год пишу под нее и слишком много обнаруживаю недоделок, багов, тормозов... Ждем .NET framework 2.0, можт будет по-лучше. |
| Автор: Дрон 1.9.2005, 12:37 | ||||||
Да ню? Списочек пожалуйста Я не говорю, что .НЕТ идеален, но всё-таки пока реальных недостатков я не видел. Добавлено @ 12:38
Точно подмечено.
У Windows есть такая вещь как ядро, которое выставляет наружу свой интерфейс -- WinAPI. Теперь интерфейсом к ядру будет .NET. По-моему, очевидно |
| Автор: Denn 1.9.2005, 13:27 | ||
Да сейчас только некорректно наследуется форма, контролы невозможно нормально разместить на наследованной - они располагаются непонятно как после компиляции. Тормозит. MFC очевидно быстрее в большинстве случаев. В C# нет некоторых вещей - шаблонов, например, вроде как есть 2.0. Некоторые исключения не ловятся - например, обращение по null указателю иногда продолжает выполнение. Продолжу позже... Когда всплывет очередное... |
| Автор: Дрон 1.9.2005, 13:31 | ||||||||
Хмм... Маловероятно. Единственное, где я видел, что исключения не ловятся вообще -- так это в обработчике событий ActiveX объекта. Помню долго не мог найти этот глюк, а потом пришлось принять как факт.
Вот именно. Будет. Они особо-то и не нужны. Типизированные контейнеры делаются очень легко и без них
Это совсем разные вещи. Нечего сравнивать.
Переустанавливаем драйвера рук и головы -- всё будет Ок Добавлено @ 13:34 По поводу последнего. Загляни Windows Form Designer Generated Code и посмотри внимательно каким именно способом в .NET создаются формы. Тогда и поймёшь |
| Автор: Denn 1.9.2005, 14:31 | ||||||||
Что не было такого - отлаживаешь строчка за строчкой, а на строке, где указатель null отладка прерывается и выполнение приложения продолжается?
Мда ждем...
А почему бы и не сравнить скорость выполнения однотипных приложений?
Я понимаю как создаются формы. А ты пробовал когда-нить менять этот сгенеренный код? Лучше не пытаться. И не редактировать имена сгенеренных переменных в начале исходника. |
| Автор: Дрон 1.9.2005, 14:37 | ||||
А мне это никогда не было нужно Зачем извращаться-то. Наоборот, я как-то долго матерился, когда увидел, что один из моего проекта вручную отредактировал сгенерённый код. Вообще надо стараться не злоупотреблять дизайнером форм, а генерировать в рантайме.
Заказчика волнует больше скорость разработки, а не скорость выполнения. Тут MFC нельзя сравнивать с .NET Что-то мы наоффтопили тут... |
| Автор: arilou 1.9.2005, 16:49 | ||||||||
Много раз так делал и никогда не было проблем.
Что такое указатель ? Ты имеешь ввиду ссылку? Тож не видел. Скорее всего, сырцы были модифицированы, но не было перекомпиляции.
А вот этого никогда не стоит делать. На то код и сгенерированный. Если тебе надо что-то поменять в сгенерированном классе - наследуешься от него и меняешь. Вот так вот. Кстати, и в MFC лезть руками в сгенерированный код - себе дороже выйдет.
Согласен. |
| Автор: Denn 1.9.2005, 20:12 | ||||||
Это вылазит иногда, если форма нагружена контролами.
Да, ссылка. Скомпиленные, конечно. В run-time такое видно, как если бы функция не отработала.
Я знаю, что не надо. А зачем тогда этот код, сгенеренный компилятором, лежит в исходнике? Пусть тогда в .resx будет. |
| Автор: mr.DUDA 1.9.2005, 23:04 | ||||
Бред полный. Код, сгенерированный дизайнером, отлаживается точно так же как и любой другой код.
Если и бывают подобные проблемы - всё дело в том, что в директории с исполняемой программой отсутствуют PDB-файлы для исходников, в которых возникло исключение. Лечится сие выставлением опции "отлавливать все .NET-исключения" (сочетание клавиш Ctrl+Alt+E, поставить красный крестик напротив "Common Language Runtime Exceptions"), и "подкидыванием" pdb-файлов для всех длл-ок в директорию с программой. В этом случае, если уж приаттачишься к процессу - точно не пропустишь ни одного исключения. З.Ы. приаттачитсья к процессу можно с пом. Ctrl+Alt+P. |
| Автор: Denn 2.9.2005, 09:05 | ||||
если он предназначен только для отладки, его можно было бы как-нить защитить от редактирования.
спасибо, посмотрю. Ладно. На это надо тему отдельную заводить. |
| Автор: Hidrag 11.9.2005, 07:23 |
| Интересно а что будет с драйверами? Будут новые драйвера под .NET или подойдут старые виндовские в новой винде... или тоже в эмуляции будет все? ) |
| Автор: mr.DUDA 11.9.2005, 13:12 | ||
По крайней мере эта версия Windows (Vista aka Longhorn) построена на старом ядре (WinXP), поэтому и дрова будут старые, вроде. |
| Автор: Guest 9.11.2005, 08:49 |
Народ, присоветуйте...  Я немного программирую на Visual C++ 6.0, на какую систему мне лучше переходить: на С++.NET или на C#.NET А то я уже весь в растерянности Кстати, это правда, что на С++.NET легче работть с контролами диалогами и т.д и т.п. |
| Автор: Exception 9.11.2005, 14:39 |
| 1. на с#. 2. мс++.нет умрёт. 3. неправда, наоборот сложнее 4. один топик - один вопрос 5. это уже неоднократно обсуждалось |
| Автор: Diless 7.3.2006, 07:04 | ||
Понять то поняли, но тормозим как это с делать.. подскажите пожалуйста. где ее взять как ее устанавливать?)) |
| Автор: kobra 7.3.2006, 09:27 | ||
|
| Автор: Calve 10.3.2006, 10:25 |
| OS на C#: http://research.microsoft.com/os/singularity/ будущее шарпа: http://research.microsoft.com/phoenix/ http://research.microsoft.com/act/ http://research.microsoft.com/~nick/polyphony/ http://research.microsoft.com/comega/ http://research.microsoft.com/projects/specsharp/ Как вам такие наработки? |
| Автор: mr.DUDA 10.3.2006, 13:25 | ||
Главное - не красивое название, а практическая польза. Пока что ничего нового не предлагается (разве что датасеты превратили в часть языка и обозвали Linq-ом  ) |
| Автор: arilou 10.3.2006, 13:32 |
| mr.DUDA, не скажи. Например, Singularity OS - это другой подход к разработке ОСи |
| Автор: mr.DUDA 10.3.2006, 13:56 | ||
я грю про "C omega", XLinq, DLinq, blablabla-Linq... |
| Автор: Exception 10.3.2006, 14:14 | ||
LINQ не трожь . Мне очччень понравился DLinq.Добавлено @ 14:16 Это гораздо лучше, чем типизованные датасеты, по крайней мере. |
| Автор: Calve 13.3.2006, 07:00 |
| В этих языках интересен не только LINQ. Там есть такие штуки как асинхронные вызовы функций и свойств, ключевые слова requires ... otherwise ..., ensures, expose, assert и т.п. Это я про Spec#, остальное еще не смотрел |
| Автор: chipset 13.3.2006, 08:16 | ||
Однако-ж ты меня заинтриговал! Качаю |
| Автор: Exception 13.3.2006, 13:02 |
| На самом деле функциональность Spec# реализуется штатными средствами С#, но более коряво. |
| Автор: Calve 14.3.2006, 12:29 | ||
Даже более того, средствами асемблера ))Вопрос только лишь в стоимости применения того или иного функционала. |
| Автор: Lord Dagger 15.3.2006, 12:07 | ||
Бред какой, драйверы на .Net... Долго смеялсо Вот до чего уже неокрепшие молодые умы додумалисьШучу, шучу;) Обычные там драйверы, на C\С++ написанные, как и вся ОС Старые драйверы(Win XP) подходят прекрасно и к Windows Vista. |
| Автор: Exception 15.3.2006, 16:14 | ||
Singularity OS вся на .NET |
| Автор: arilou 15.3.2006, 16:22 |
Exception, я так и знал, что ты это скажешь  |
| Автор: nettitan 14.6.2006, 15:04 |
| Привет всем !!! Насколько я знаю и слышал есть два вида програмирования под .NET: 1. Windows Form 2. програмирование под WEB Я шас пишу на С# (под Windows), но меня также интересует второй пункт, так как над первым пунктом я сейчас работаю... Хотелось бы узнать побольше о програмировании под WEB, что это такое и с чем его едят..... Так как на С# можно писать и под WEB, хочу о нем узнать больше, может в будущем займусь всем этим. Зарание благодарен !!! |
| Автор: arilou 14.6.2006, 22:35 | ||
за что? |
| Автор: Ch0bits 14.6.2006, 22:56 |
| nettitan Для начала изучи HTML и JavaScript, потому что без них "програмирование под WEB" как сапожник без сапог. |
| Автор: kaa 15.6.2006, 00:28 |
| А у мя такой аопрос: можноли компилить программу на C# не в IL-код а в native сразу? любапытно ж черт возьми |
| Автор: VisualProgrammerNET 15.6.2006, 01:58 |
| Мнэээ... внутренний голос подсказывает, что только из MC++ можно компилить native код |
| Автор: Ch0bits 15.6.2006, 05:55 |
| kaa Низя. |
| Автор: mr.DUDA 15.6.2006, 10:51 | ||
kaa, а зачем ?
Воистину так, аминь  |
| Автор: ivashkanet 15.6.2006, 12:37 | ||
Могу предложить массу вариантов ответа. |
| Автор: VisualProgrammerNET 15.6.2006, 13:58 |
А как же MC++?  Стопудово где-то читал, что оттуда можно компилить native код |
| Автор: Exception 15.6.2006, 14:00 | ||
C++/CLI только. Можно, конечно. |
| Автор: nettitan 15.6.2006, 14:47 |
| Вот это я новость нашел, радуйтесь братья мои..... "Мне кажется, что переименование WinFX в .NET v3.0 вполне разумно, но я ни встречал ни одного упоминания, значит ли это, что в состав пакета будут включены C# 3.0 и LINQ, не говоря уже о DLINQ и ADO.NET v3.0. Похоже, что .NET v3.0 выйдет скорее, нежели C# 3.0 и ADO.NET v3.0, и не похоже, чтобы последние были выпущены раньше; итого, значит ли все это очередную задержку WinFX, или надо ли нам ожидать, что все другие продукты будут переименованы в 3.х или вообще в 4.0? Извиняюсь за игнорирование VB, но с тех пор как он не носит имени 3.0, то и не возникает проблемы с переименованием или задержкой выхода." |
| Автор: Exception 15.6.2006, 17:52 | ||||
Он носит имя VB 9.0 Добавлено @ 17:53
Это почему же? |
| Автор: kaa 9.7.2006, 02:02 |
| А вот возник вопрос. Существует-ли в C#.NET вариант компиляции сразу в бинарный код с включением внего всех необходимых библиотек и функций? |
| Автор: Evghenii 9.7.2006, 10:52 | ||
Насколько мне известно нет. |
| Автор: ivashkanet 9.7.2006, 11:06 | ||
Нет, не существует, не реализовано P.S. Уже тысячу раз обсуждалось!!!!! P.P.S. Модераторы: Предлогаю попросить у Вовы (илу у кого там просят, dm9? ) добавить в шапку раздела большими буквами: Приложения под .Net НЕ компилятся в бинарный код Красными, жирным.... |
| Автор: kaa 9.7.2006, 12:38 |
| Понял Добавлено @ 12:39 А насчет того что сто раз обсуждалось - так я пытался найти поиском и ничё невышло, может у мя конечно руки кривые, а может... |
| Автор: sgi1981 14.7.2006, 12:20 | ||
Опарафинились Microsoft? |
| Автор: ivashkanet 14.7.2006, 12:28 | ||
Врятли, это такой маркетинговый ход --- типа все устанавливаем FrameWork и баста sgi1981, неужели ты думаешь, что MS не могла написать компилятор IL в native-код  Тем более это делает JIT-компилер при запуске проги |
| Автор: mr.DUDA 14.7.2006, 12:54 |
| http://www.xenocode.com/ И подобные ему позволяют создавать .NET приложения, не требующие установки Framework. З.Ы. насчёт "микрософт опарафинилась", sgi1981, SUN что тоже опарафинилась с Java ??? |
| Автор: sgi1981 14.7.2006, 15:32 | ||
Ну, знаешь ли. Джава первоначально был предназначен совсем не для того, для чего его применяют сейчас - в то время и не думали даже... А насчет исполняемых файлов под .NET - есть свои преимущества и недостатки. Первое преимущество, которое я заметил - маленький размер "*.exe" - весь машинный код по инициализации окна теперь в ОС (включая .NET). А недостаток - много ограничений в программировании. Ну хотя бы кто-нибудь мне ответит на вопрос: как мне вставить мной составленную последовательность инструкций процессора на C# ? Никак. А почему я должен всегда подчиняться NET ? Она умнее моего мозга ? Или комп должен права качать ? Компилятор никогда не создаст код эффективнее чем это может сделать человек. А почему я должен использовать средства WINDOWS только через NET постоянно ? А может я могу эффективнее использовать АПИ в некоторых случаях ! Да, а как там вообще SSE2 инструкции процессора - чё, только .NET их будет генерить ? Она самая умная да ? А как же мне обрабатывать графические изображения с применением инструкций SSE2 собственным алгоритмом. Ну неужели все алгоритмы по обработке графики исчепываются ОС ? НИКОГДА ! Потому что их бесконечное множество. Так я непонимаю - у меня есть шанс на применение собственного машинного кода в C# ? Как мне добавить в прогу исходный код на асме (помните меня на АСМ-форуме, если не помните - просмотрите мои сообщения) ? Может можно составить DLL а потом подключить. Так чего то я не нахожу неи в одной книге из двух книг как подключить DLL к проекту. Да, надо же вспомнить, что вызываться могут только те подпрограммы, которые являются методами класса. А если DLL не экспортирует классов, то вообще тогда непонятно... Как мне использовать DLL-библиотеки в своей программе на C# ? |
| Автор: Дрон 14.7.2006, 15:45 | ||||||
Гражданин, sgi1981, поменьше эмоций, пожалуйста. Вас никто не заставляет писать на .NET
Никто и не запрещает
Легко. Поиск на форуме по слову DllImport
А почему бы и нет... |
| Автор: mr.DUDA 14.7.2006, 15:51 | ||||
Если только в этом вопрос... Пишем любую длл с любыми экспортируемыми функциями. Затем на C# пишем класс, в котором объявляем метод с модификаторами public static extern и ставим над методом атрибут [DllImport("имя dll")]. Всё, при вызове метода будет вызвана длл-функция с тем же именем, что имя метода. Добавлено @ 15:52
Иногда, к сожалению, наоборот. З.Ы, а native код никогда не умрёт, ИМХО. Не будут же САПРы и движки баз данных писать на .NET |
| Автор: sgi1981 14.7.2006, 16:39 |
| Первоначально мне понравился маленький размер *.exe файла по сравнению с исполняемым файлом, сгенерированным C++ Builder. В общем кажется странным, почему размер "*.exe" такой сравнительно большой получается на C++ Builder даже если просто пустую форму создать. То бишь если так сделать, чтобы программа могла выполняться на других машинах и ничего не поместить на форму, то и тогда количество кода будет в полметра. Может я не знаю способа как уменьшить объем генерируемого кода С++ Builder ? По поводу DLL. Да, я просто хотел спросить как можно подключить DLL. А динамически никак ? И чего то оно странно. Могла бы Майкрософт и предусмотреть возможность вставки native-кода в "*.exe". Допустим предшествует в файле некая директива, которая означает что следующие байты будут просто native-кодом. Неужели такая нужна супер-безопасность кода ? Они че думают, что хакеры накроют в скором будушем их WINDOWS ? |
| Автор: mr.DUDA 14.7.2006, 16:49 | ||
А какой смысл тогда был бы в промежуточном языке ? Вместо IL можно было бы компилировать прямо в native-код, и делать вставки на асме в C#. Задумано всё было ради переносимости: JIT в рантайме переводит IL в исполняемый код, оптимизированный под конкретную платформу, под процессор и т.д. Кстати, поэтому .NET-приложение скомпилированное под x86, по идее должно без перекомпиляции работать под x64 (не проверял). |
| Автор: arilou 14.7.2006, 17:34 | ||
Visual C++ вам в помошь. Там все это можно сделать. |
| Автор: sgi1981 14.7.2006, 18:45 | ||
А знаете, в HELPе Borland Developer Studio по поводу использования DLL написан пример использования АПИ из User32.dll
|
| Автор: mr.DUDA 14.7.2006, 20:35 | ||
Замечательно ! Об этом я и говорил выше. |
| Автор: Freelancer 25.12.2006, 09:51 |
| Моё мнение по поводу .НЕТ: Майкрософты как всегда стремяться урвать все более-менее хорошие идеи дабы в будущем предоставлять пользователям большую свободу (в плане что всё уже включено). Типичный пример технология Флеш. Как она набрала популярнгость её активХ включили в пакет ОС. Чтоб юзер сразу после установки ОС мог выйти в нет и не чувствовать каких либо неудобств. Сейчас они идут по пути натоптаному Явой. И у них все получиться больше чем уверен. Так как денег у них и не на то еще хватит. .НЕТ это конкурент яве причем мощный. Прикинте подержку .НЕТ на мобилах! В плане безопасности тоже .НЕТ рулит в плане того что чо попало не напишиш. Это конечно сужает возмжности. Так же зделали те же Макромедия кода не стали включать в свой интерпритатор возможность работы с файлами... Хочеш чото сохранить на винте? Будь добр использовать спецальный метод. Который сам куда нада что нада запишет... А вообще это "Бизнес"! Как продать старую конфету? Правильно... завернуть её в новую обертку. Тут кондитерам(программистам) придеться покупать новые инструменты, а юзерам... ОС. И все счастливы... Все радуються прогрессу : ) |
| Автор: Yama 25.12.2006, 11:46 |
| sgi1981, по моему, Майкрософт решила сделать .нет фреймворк исключительно для того, что бы защитить свою ОС, т.к. постоянно фиксить глюки и баги просто невозможно(на моей памяти более-менее стабильно работала только win2kSP4), они решили придумать "принципиально новую технологию" и еще на этом прилично заработать. При компиляции сразу в native-код можно было сделать многочего как хорошего, так и не совсем с ОС. А под .нет такого просто невозможно сделать - ни хорошего, ни плохого. По сути .нет фреймворком Майкросовт решила свои проблемы за счет энд-юзеров. +1 их маркетинговому отделу . |
| Автор: Deja_Vu 28.9.2007, 21:58 |
| Сколько воды утекло с далекого 2001 года?! .NET растет - цветет. Не так быстро, как хотелось MS, но все же. .NET программисты все больше и больше требуются, а Internet технологии уже полностью переходят под .NET. ASP.NET - загляденье ... используй понравившийся тебе язык. Я за .NET, ведь тогда никто не сможет ничего плохо сделатьмоему компьюторику -)) |
| Автор: Geolog 11.2.2008, 13:40 |
| Здравствуйте. Я пользователь, и мне хочется узнать ответы на следующие вопросы: 1) Vista уже более года как вышла - работает она на платформе NET Framework (эмулируя при этом Win32) или всё работает также как и в WinXP? 2) Какие из NET Framework в Vista уже предустановленны, а какие необходимо ставить? 3) В чем отличия между NET Framework 3.0, NET Framework 2.0, NET Framework 1.1 (аккумулируют ли более новые версии более старые версии )? 4)Почему, если стоит NET Framework 3.0, и пробуешь ставить Google SketchUP (ему нужна NET Framework 1.1), он не ставиться требует установки NET Framework 1.1? (к стати под Vista SketchUP тоже отказался ставить) 5) На сегодняшний день есть удачные проекты по реализации работы приложений .NET на Linux (сама Microsoft в этом направлении работает)? |
| Автор: kemiisto 11.2.2008, 13:59 | ||||||||||||
Скорее так: платформа .NET работает поверх платформы Win32 (ну или Win64). А в самой Win32 по сравнению с XP были сделаны существенные изменения. Все таки как никак новая ОС.
Версии 1.1, 2.0 и 3.0. По поводу 3.5 не уверен, видимо надо ставить.
Отличий много, главное то что новые версиии не аккумулируют старые, и вот поэтому то и
Может банальная несовместимость. Google все таки конкурент 
M$ сотрудничает с Novell, которая разрабатывает платформу http://www.mono-project.com/Main_Page (.NET может устанавливаться только поверх Win32 или Win64? а у Mono - кросплатформенность (Win, Linux, MacOS,...)). Есть даже IDE http://www.monodevelop.com/Main_Page (пока, imho, продукт сыроват). |
| Автор: arilou 11.2.2008, 15:29 | ||
э-э-э, а ссылку на первоисточник? |
| Автор: kemiisto 11.2.2008, 15:44 |
| arilou, их море: http://www.novell.com/linux/microsoft/faq.html (предпоследний вопрос касательно mono) Сделке уже больше года! http://www.nixp.ru/news/7924 |
| Автор: arilou 11.2.2008, 17:57 |
| kemiisto, о я не знал. думал новел это всё сам делает. |
| Автор: kemiisto 11.2.2008, 19:27 |
| arilou, Novell имеет к Mono вообще очень интересное отношение. Была такая компания Ximian - вот она то все и разработала, а потом... Novell ее купила! Сейчас Ximian - часть Novell. http://www.novell.com/linux/ximian.html |
| Автор: Geolog 12.2.2008, 11:54 |
| Спасибо за ответ. Меня смутил тот факт, что в Vista в разделе компоненты системы явно висит только NET Framework 3.0, ну и SketchUP отказался устанавливаться пока я не установил на висту NET Framework 1.1 - обидно всё таки, что даже под висту приходиться ставить пакет обновления многолетней давности. |
