Форум StopLinux

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

Но.

Готовые программы можно разделить на три вида:

Нескомпилированные, их ещё называют скриптами, то есть распостраняемые и исполняемые в виде открытого текста на некотором языке программирования. Эти программы выполняются с помощью сторонней программы - интерпретатора или JIT -компилятора.

Скомпилированные в байткод - промежуточный, похожий на машинный код вид, который оптимизирован на задачи дальнейшей трансляции для таргет -  архитектуры . Наиболее яркие и известные примеры - приложения для JVM и .NET

И наконец третий тип - он составляет большинство написанных для персональных компьютеров и рабочих станций программ - программы, скомпилированные в нативный (машинный код конкретной архитектуры процессора) код. И вот с ними то и основная проблема. Какие бы библиотеки или языки данная прграмма не использовала она всё равно содержит в  себе исполняемый код предназначенный ТОЛЬКО для процессора x86. Для запуска на других архитектурах необходима программная имитация (эмуляция) устройства с процессором x86. И библиотеки, которые вы упоминаете к данному вопросу совершенно ортогональны.

Таким образом - единственный выход из сложившейся ситуации - полный отказ от программ третьего типа в пользу первых двух. Вопрос стоит лишь в том, что преимущество по быстродействию сохраняется как раз у программ третьего типа. Незначительно, но в силу понятных причин отстают программы второго типа. С развитием средств поддержки программ первого и второго типа, в будущем, возможно необходимость в программах третьего типа и отпадёт. И к этому делаются определённые шаги. Например для мобильной операционной системы  "Андроид" разработка нативных приложений и компонентов приложений очень не приветствуется. Для мобильной операционной  системы Windows Phone 7 разработка нативных приложений или их компонентов не поддерживается вообще. Только байткод сборки для .NET.

По сути нативные зубры пока держатся на основном островке - ресурсо-зависимые приложения, критичные к производительности, словом там , где необходимы тяжлые  математические расчёты - в основном программы для тяжёлых математических расчётов и для обработки всяческой мультимедии - трёхмерная графика, видео, дорогие компьютерные игрушки, словом, везде где нужно считать много и в масштабе реального времени. Но с развитием современного аппаратного обеспечения, а так же средств для обьединения нескольких раздельных обьектов аппаратного обеспечения в один, можно пренебречь производительностью ценой железа, которая кстати сейчас дешевеет. Кроме того, строго нативные приложения не позволяют реализовать многие сложные вещи из языков высокого уровня - сборку мусора, рефлексию, динамическую типизацию., функциональщину. Поэтому, основные языки для нативной компиляции - с и c++ сейчас упираются в предел количества строк, при котором дальнейшая разработка, сопровождение и масштабирование продукта сильно затрудняется из за скудности этих языков по сравнению с теми же C# и Java.

Так что перед выпуском операционной системы виндовс 8 на арм должно произойти вымирание нативных приложений.

Редактировался apexcds (20-05-10 02:01:24)

Ну и подскажите, что может дать винда для устройств на ARMе? Тормоза и глюки?

Если взять самый простой случай -- телефоны, то Windows Phone -- ничто по сравнению с Android-фонами или даже (упаси боже) iPhone.

Вариант для встраиваемых устройств -- это (конечно же, на что ещё способна MS?) внедрение C#'а и прочего дотнета, но не представляю себе, как дотнет будет жить на ВСТРАИВАЕМЫХ устройствах.

Все равно главного преимущества винды на x86 -- огромного набора софта -- нет, эту территорию уже захватил линух.

Редактировался usr_share (23-07-10 20:06:27)