Здравствуйте. Вот на досуге о 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.

> > В Delphi (даже 2005) есть вкладка win 3.1, как я понимаю
>
> > это для 16 битных приложений
>
>
> Это ты неправильно понимаешь. Это набор компонент из Delphi
> 1.

Так вроде Delphi 1 пишет 16-битные же приложение?

>  [20] Shst   (29.10.05 21:39)
> Так вроде Delphi 1 пишет 16-битные же приложение?

Так точно :) Да только компоненты эти, установленные в Делфи, скажем, 3-ей, не сделают приложение 16-битным.

А понятно... Они остались для совместимости с Delphi 1, но компилироваться будут уже под win32.

Что есть поддержка Win16 и ДОС в Win32
Это всего лишь запуск виртуальной машины, тоже самое будет и для .NET ОС
То есть никакой поддержки как таковой просто нет. Не работают 16 битные приложения в 32 битном режиме, она как работали в 16 битном, так и работают, но только в виртуальной машине.

Значит win32 запускается не в виртуальной машине? А как бы "вживую"?