-
Здравствуйте. Вот на досуге о net размышлял и решил узнать ваше мнение по данному вопросу. Если этот новый windows Vista выйдет в следующем году, то он уже будет содержать в себе .Net, хотя поддержка win32 останется. Скорее всего с новыми версиями операционной системы, Microsoft, будет больше полагаться на .Net, win32 будет поддерживать как что-то старое,ненужное (типа как сейчас win16). Под win32 скомпилировано множество разных громадных программ (возьмем все семейство Abode,Abbyy и т.д.), следовательна потребуется их вся перекомпиляция с учетом новых возможностей. А программисты одиночки потратят много времени на перекомпиляцию своих утилит (что не каждому под силу). Т.е придется изменять некоторые участки кода, чтобы программа нормально компилировалась под .Net (а это время и деньги). За смысл собо не пеняте, т.к. я не очень много знаю.
И еще, правильно, что .Net это всего лишь структура исполняемого файла(призванная быть межплатформенной: в интернет и на мобильных устройстах и просто дома на ПК) и чтобы скомпилировать под .Net нужен компилятор способный код (на паскале, на си, не важно) переводить в .Net-приложение?
-
> еще, правильно, что .Net это всего лишь структура исполняемого > файла
Нет. Это в первую очередь виртуальная машина, в которой этот исполняемый файл будет исполняться. .NET - это аналог Java, только в исполнении Microsoft
-
>win32 будет поддерживать как что-то старое,ненужное (типа как сейчас win16)
Ошибаетесь.
-
> DrPass © (26.10.05 22:36) [1] > > > > еще, правильно, что .Net это всего лишь структура исполняемого > > файла > > Нет. Это в первую очередь виртуальная машина, в которой > этот исполняемый файл будет исполняться. .NET - это аналог > Java, только в исполнении Microsoft
Я бы уточнил - .NET Framework и CLR (которые, кстати, уже стоят перманентно на Win XP и Win 2003 Server) это аналоги Java-машины. Но идеология у CLR другая. Вместо того, чтобы просто интерпретировать код программы в коды, принятые в соответствующей ОС, CLR в будущем будет создавать последовательность кодов для конкретного процессора. Т.е. максимально оптимизироваться под аппаратную часть. Кроме того, MS обещала частую модернизацию Framework. Это значит, что одна и та же старая программа под нее, установленная на одном и том же компе, с одной и той же ОС может заработать быстрее.
-
Это значит, что одна и та же старая программа под нее, установленная на одном и том же компе, с одной и той же ОС может заработать быстрее.
Правда? Откуда ресурсы возьмутся?
-
> Вместо того, чтобы просто интерпретировать код программы > в коды, принятые в соответствующей ОС, CLR в будущем будет > создавать последовательность кодов для конкретного процессора. > Т.е. максимально оптимизироваться под аппаратную часть. >
А почему в будущем? Она же и сейчас компилирует IL в машинный код при первом обращении к методу класса. Или я ошибаюсь? Во всякому случае, в Java такая JIT-компиляция реализована уже много лет назад, с выходом Java 2
-
> Seg (27.10.05 13:01) [4] > Правда? Откуда ресурсы возьмутся?
Сэкономятся за счет более качественного исполнения интерпретатора. Или Вы не видите никакого смысла вообще в апгрэйде ПО?
-
> DrPass © (27.10.05 13:17) [5] > А почему в будущем? Она же и сейчас компилирует IL в машинный > код при первом обращении к методу класса. Или я ошибаюсь?
Я не уверен, что прямо сейчас CLR генерит разную последовательность для разных процессоров, но MS об этом заявляет.
Java-технология этого даже не обещала. Но я не готов доказывать преимущества MS подхода перед Sun. Думаю, что мелкомягкие создали свою именно для подавления последней.
-
Сэкономятся за счет более качественного исполнения интерпретатора.
Как показывает практика, более новые интерпретаторы работают медленнее предыдующих и требуют больше ресурсов.
-
Не интерпретатор, а кодогенератор. MSIL не интерпретируется, а компилируется в native код процессора.
Речь идёт о создании различных оптимизирующих кодогенераторов для разных процессоров. Посмотрите, например, на Optimization Guide от Intel и от AMD. Разницы много. Я уж не говорю про разницу между архитектурами, скажем IA32 и IA64. А промежуточный код может оставаться одним и тем же.
-
Как я понял, о прекращении в будующих нескольких лет поддержки win32 в ОС windows некто точно не может пророчить? А если Java не смогла добиться быть главной на ПК пользователя, то почему это должно получиться у .Net?
Нет. Это в первую очередь виртуальная машина, в которой этот исполняемый файл будет исполняться. .NET - это аналог Java, только в исполнении Microsoft Этим можно сказать, как я понимаю, что программа скомпилированная под win32 там работать не будет, понадобится перекомпиляция.?
-
прекращении в будующих нескольких лет поддержки win32
Это всего лишь легкий шантаж со стороны мелкомягких, чтобы народ побыстрее начал переходить под .NET.
-
Хм.. А если, например, микрософт в будующем виндоусе отменит поддержку win 32? Они потеряют часть пользователей? А куда эти пользователи уйдут? На другие ОС или останутся на старых версиях виндоуса ? Мне кажется оба эти варианта не уместны..
-
> Seg (27.10.05 17:03) [11] > Это всего лишь легкий шантаж со стороны мелкомягких, чтобы > народ побыстрее начал переходить под .NET.
Не это заставит перейти на .NET Я уже перечислял несколько неоспоримых преимуществ. Для меня сейчас наиболее важным является удобство работы с большими проектами.
-
А если, например, микрософт в будующем виндоусе отменит поддержку win 32? Они потеряют часть пользователей?
Кому вообще будет нужна ОС, не поддерживающая win32?
Может только геймерам.
-
Ничего они не собираются отменять. Слухи сильно преувеличины...
-
> Этим можно сказать, как я понимаю, что программа скомпилированная > под win32 там работать не будет, понадобится перекомпиляция. > ?
Не будет, конечно. Но никто не собирается убирать поддержку Win32 в "родном" режиме. Например, 32-битные ОС Microsoft появились в 1992 году, последние 16-битные версии вышли в 1994, а поддержка старых 16-приложений убрана из Windows только в 2005, в WinXP 64-bit Edition. Т.е. совместимость со старым кодом держалась 11 лет, и убрали ее только когда она стала уже на 100% неактуальной
-
> 16-приложений
= 16-битных приложений
-
В Delphi (даже 2005) есть вкладка win 3.1, как я понимаю это для 16 битных приложений. И они есть в ней до сих пор!
-
DrPass © (27.10.05 19:30) [16]
> а поддержка старых 16-приложений убрана из Windows только > в 2005, в WinXP 64-bit Edition
И то поддержка не всех приложений убрана, ряд 16-битных приложений поддерживается подсистемой Wow64.
Shst (28.10.05 19:16) [18]
> В Delphi (даже 2005) есть вкладка win 3.1, как я понимаю > это для 16 битных приложений
Это ты неправильно понимаешь. Это набор компонент из Delphi 1.
|