Почему мы не можем создавать программы кросс-платформенные в наши дни? - PullRequest
3 голосов
/ 13 февраля 2009

Мне просто интересно, если все компиляторы на любом языке преобразуют код в единственный язык, на котором «говорят» в компьютерных системах (машинный код - нули и единицы), почему так трудно передать приложение Windows .NET в Mac приложение?

Не должен ли кто-то прийти с блестящей идеей (у меня нет блестящих идей с тех пор, как я женился 3 года назад!) И иметь ... я не знаю ... структуру машинного кода, так что вместо Компилятор преобразует в машинный код, он будет преобразован в ту платформу, которая будет установлена ​​на любой платформе (SuSE, FSB, Ubuntu, AIX, SCO, OS X, Windows 9x, Vista, 7 и т. д. и т. д.).

Интересно, почему мы не можем делать все так просто, в наши дни ...

Есть мысли?

Ответы [ 9 ]

13 голосов
/ 13 февраля 2009

На самом деле, это уже сделано. В определенной степени, по крайней мере.

Одна из работ называется Java, которая является кроссплатформенным языком. Компилятор Java компилирует исходный код в нечто, называемое «байт-кодом», которое является не более чем машинно-независимым «языком ассемблера». Этот «исполняемый файл» впоследствии выполняется виртуальной машиной Java (JVM), которая отличается от платформы к платформе (то есть Windows JVM, очевидно, отличается от MacOS JVM).

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

11 голосов
/ 13 февраля 2009

Эта проблема более глубока, чем предполагает большинство людей, Java все еще не зависит от платформы, поскольку она не будет работать на всех операционных системах x86 или x64, вам все еще нужна виртуальная машина для запуска поверх операционной системы. Это даже не близко к тому, что вы предлагаете, поскольку вам все еще требуется зависящая от ОС среда выполнения для выполнения «независимого» байт-кода.

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

Существует также проблема с тем, что такое исполняемый файл: в Windows у вас есть PE , тогда как в большинстве операционных систем Linux у вас есть ELF . Они имеют разные структуры и разные стили загрузки. Как они загружаются и выполняются, зависит от ОС и не зависит от исполняемого файла.

Вы можете увидеть разницу между двумя форматами на этом изображении (взято из здесь : http://software.intel.com/file/9800

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

5 голосов
/ 13 февраля 2009

Приложения зависят от операционной системы для предоставления услуг.

Вы можете создать приложение с минимальной зависимостью от ОС. Но даже если (с некоторыми серьезными Фу, Волшебством и рукопожатием) вы заставите его работать на «каждом компьютере», это не то, что мы хотим.

Языки Script и Script-like (такие как Python и Perl, как уже упоминалось) идут по этому пути: они используют минимальные возможности ОС и создают все, что предоставляют, на ее основе. Это отлично подходит для приложений командной строки, потому что все, что вам нужно (более или менее) - это чтение и запись файлов и пользовательская консоль.

Богатым приложениям сегодня нужно гораздо больше сервисов, хотя они должны «работать в ОС», а не «только на процессоре»: мы ожидаем, что они будут интегрированы с ОС, пользовательский интерфейс должен выглядеть нативно, вы хотите использовать буфер обмена, диалог «открыть файл» должен предоставлять все функции, которые предоставляют другие диалоги открытия файла.

Среда, подобная Java, пытается обеспечить это портативным способом, используя более высокий уровень абстракции: есть окна, виджеты и все красивые вещи. Но у этого есть свои проблемы:

Во-первых, вы всегда должны балансировать между «согласованностью платформы виртуализации» (т. Е. Приложение работает одинаково независимо от того, где вы ее запускаете) и «согласованностью платформы хоста» (т.е. приложение работает как нативное приложение).

Вы можете попытаться полностью избавиться от «нативных вещей», чтобы избежать этой проблемы, но тогда вы стремитесь к пересечению функциональности, которую предоставляют все платформы. Вы работаете на Apple? Покончить со второй кнопкой мыши. и т. д. Кроме того, ваша платформа абстракции всегда будет отставать от инноваций на хост-платформах.


Суть в том, что серебряной пули нет: всегда есть компромисс. На рынке существуют разные успешные компромиссы.
3 голосов
/ 13 февраля 2009

Проблема всегда в том, что вы получите приложение ниже номинала.

Если приложение должно работать на всех платформах, вы получаете графический интерфейс, который не подходит ни для одной платформы, и приложение, которое не соответствует ожидаемым функциональным возможностям на платформе. то есть функциональность, которая существует только на одной платформе - в OS X вы ожидаете интеграции со всеми последними функциями, а smae подходит для Windows и * nix

Самое близкое, что вы можете получить, я думаю, это иметь кроссплатформенную базовую функциональность, а затем построить GUI и любые дополнительные функции, специфичные для платформы.

3 голосов
/ 13 февраля 2009

Мы можем это сделать, см. Java для примера. Будет ли Microsoft делать это другой вопрос. Они сохраняют конкурентное преимущество для Windows, не делая этого.

Другими примерами являются Perl и Python. Недостаточно просто иметь язык, вам нужны библиотеки, чтобы облегчить жизнь программистам. Java, Python и Perl, кажется, достигли этого относительно хорошо, и я уверен, что у Microsoft есть все силы, чтобы сделать то же самое для .NET. Но остается вопрос: с чего бы они?

Отойдя от виртуальных машин типа байт-кода, у вас также есть такие вещи, как VMWare, Virtual PC и т. Д., Которые могут запускать код на виртуальном процессоре аппаратного уровня. Некоторым из них нужен один и тот же процессор под крышками, другие (например, VirtualBox и Bochs) используют виртуальный процессор поверх другого процессора.

Чего я не видел, так это полной интеграции между хостом и виртуальными средами. Перетаскивание VMWare между двумя - это хорошо, но было бы намного лучше иметь возможность размещать среду SPARC поверх x86, и в основном приложения SPARC выглядели бы точно так же, как и приложения x86 (аналогично тому, как Cygwin X-windows) приложения на базе просто выглядят как обычные окна Windows.

2 голосов
/ 13 февраля 2009

Как уже упоминалось, это возможно (особенно языки на основе JVM и Python), и многие люди создают кроссплатформенные приложения. Что меня удивляет, так это количество людей, которые придерживаются платформозависимых фреймворков. Очевидно, они продавались лучше.

Эти вещи больше связаны с политическими, чем с техническими вопросами. На практике наиболее сложные технические проблемы с кроссплатформенной разработкой возникают из-за низкоуровневой аппаратной связи (драйверы для конкретных устройств и т. Д.), Но типичным приложениям в любом случае не требуется напрямую взаимодействовать с аппаратным обеспечением.

1 голос
/ 13 февраля 2009

почему так сложно пройти .NET windows приложение в приложение Mac?

.NET предназначен для программистов при создании windows программ. полная реализация .NET (как сделано MS) доступна только для Windows. Кажется, что надежды на то, что это изменится, не так много.

Для лучшей межплатформенной поддержки вы можете взглянуть на другие языки, такие как Java 1 :

Java-приложения обычно скомпилирован в байт-код, который может работать на любая виртуальная машина Java (JVM)

... что очень похоже на то, что делает Python 2 :

CPython компилирует программу Python в промежуточный байт-код, который затем выполняется виртуальной машиной.

и хотя .NET делает то же самое 3 :

Также является частью .NET Framework, это среда выполнения известна как Common Language Runtime (CLR). CLR обеспечивает видимость виртуальная машина приложения

проблема в том, что "виртуальная машина" - как определено и построено MS - просто доступна только в Windows:

.NET в его полной форме доступен только на Платформы Windows

1 голос
/ 13 февраля 2009

Microsoft внедрила .NET только в Windows. Поэтому для запуска приложений .NET на других платформах необходима новая реализация. Mono предпринимает шаги, чтобы сделать это возможным. Текущая версия работает с большинством сборок .NET 2.0 и поддерживает многие специфичные для Windows интерфейсы.

Что касается остальной части вашего вопроса: переопределить все API, которые все остальные используют, сложно, а существующие проекты не завершены. Wine поддерживает большинство приложений Windows, но только просто. GNUstep реализует большую часть спецификации OpenStep и имеет некоторую совместимость с API-интерфейсом Mac OS для какао, но, к сожалению, он неполон и будет долгое время.

Если бы все использовали один стандартный API, возможно, он был бы другим. Но, честно говоря, все существующие API в некотором роде отстой.

0 голосов
/ 13 февраля 2009

Ну, ты вроде как можешь с Silverlight. Что касается того, выходит ли Silverlight из браузера в нативные приложения, это политическое решение Microsoft, а не техническая проблема. Ребята из Mono также проделали работу по созданию .net для создания бинарных файлов для iPhone, поэтому в будущем, несомненно, будет больше кроссплатформенности.

Adobe Air, Java и другие подобные вещи также делают кроссплатформенные приложения на стороне клиента - черт, вы даже можете сделать кроссплатформенность в C ++, если вы действительно хотите: -)

...