Почему создание является Delphi на 64 бита настолько трудно?
Интернет полон разработчиков, запрашивающих Delphi на 64 бита и пользователей программного обеспечения Delphi, запрашивающего 64 версии.
- Дельфи 32 бита: 1 470 000 страниц
- Дельфи 64 бита: 2 540 000 страниц :-)
Вот почему я задавался вопросом, почему Причал все еще не предлагает такой версии.
Если бы было легко сделать, я уверен, что это давным-давно уже было бы сделано. Таким образом, каковы точно технические трудности, которые должен преодолеть Embarcedero?
- Действительно ли это - компилятор, RTL/VCL или IDE/отладчик?
- Почему переключатель от 32 битов к на 64 бита более сложному, чем это было для Borland для переключения от 16 битов до 32 битов?
- Команда FPC сталкивалась с подобными проблемами, когда они добавили поддержку на 64 бита?
- Я наблюдаю за чем-то важным, когда я думаю, что создание Delphi на 64 бита должно быть легче, чем Kylix или Delphi. Сеть?
8 ответов
Из того, что я читал на форумах, я думаю, что основная задержка была в том, что компилятор для 32-бит не мог быть легко адаптирован для 64-бит, поэтому им пришлось написать новый компилятор со структурой, которая позволяет легко переносить его на новые платформы. Эту задержку довольно легко понять в этой области.
И первое, что должен был сделать новый компилятор, это поддержать текущую 32-битную Windows, прежде чем нацеливать ее на 64-битную, так что эту дополнительную задержку тоже легко понять.
Теперь, на пути к 64-битной поддержке, Embarcadero решила нацелиться на 32-битную MacOSx, и это решение - то, что некоторые люди вообще не понимают. Лично я думаю, что это хорошее маркетинговое решение с точки зрения бизнеса Embarcadero (подождите, я не говорю, что 64-битная поддержка менее важна, читайте внимательно, я говорю не о важности, а о коммерческой целесообразности). Это очень спорная дополнительная задержка на пути к 64-битам (кроме того, Embarcadero говорит, что у них есть команды, работающие параллельно, на самом деле задержка есть, по крайней мере, для вопросов версий - опять маркетинг).
Также стоит помнить, что FPC не является коммерческим продуктом, поэтому они могут добавлять/удалять функции легче, чем Delphi.
Настоящие проблемы не являются техническими. Сначала Borland / CodeGear, а затем Embarcadero показывают, что они не хотят поддерживать более одной версии Delphi для Windows. Они отложили переход на Unicode до тех пор, пока полностью не отказались от поддержки Ansi OS. На самом деле они должны поддерживать как компилятор / библиотеку Win32, так и 64-битный компилятор / библиотеку, потому что используется смесь 32- и 64-битной ОС Windows. Я считаю, что они стараются отложить это как можно дольше, чтобы как можно больше не использовать 32-битные. Компилятор Delphi стал довольно старым и сложным в обслуживании, но они решили переписать его, нацелившись на ОС, отличные от Windows, и я уверен, что драйвер должен был переносить некоторые инструменты базы данных Embarcadero на 32-разрядные платформы, отличные от Windows, игнорируя фактические потребности клиентов Delphi. и снова откладывает 64-битный компилятор и библиотеку в кросс-платформенной попытке, снова пытаясь срезать углы, чтобы доставить ее быстро, и, таким образом, снова обречена на провал. Они упорно не хотят переходить на двухлетний цикл выпуска, потому что им нужны свежие деньги каждый год, несмотря на то, что становится все труднее выпускать действительно хорошо сделанные улучшения за такой короткий цикл - и потребовалось почти четыре года, чтобы исправить проблемы, возникшие с Изменения в Delphi 2005. В свою очередь, они должны заставить разработчиков работать над внесением «незначительных» улучшений, чтобы оправдать обновления, вместо того, чтобы полностью работать над 64-битным материалом.
Я слышал, что они хотели полностью переписать компилятор без потери обратной совместимости. Учитывая, что нет полного описания синтаксиса языка (я спросил, но они не сделали, поэтому я сделал свой собственный доступным для широкой публики). Могу себе представить, что документация не такая полная, как они хотели. Так что они, вероятно, пытаются реконструировать свой собственный код.
Я решительно поддерживаю Delphi и считаю, что 2009 и 2010 годы - отличные релизы (сравнимые с твердым № 7). Но отсутствие поддержки 64-бит в конце концов их убьет.
Возвращаясь к вопросу, самой большой проблемой должен быть компилятор. Переход с 16 на 32 бит был проще, потому что в нем было меньше устаревших (delphi 2 был 32-битным, а язык Object Pascal был намного проще, чем сейчас). Насчет Фри паскаль я не уверен. Может быть, их код было легко перенести. Может они потеряли какую-то обратную совместимость. Конечно, вы можете спросить их.
Уже существует 64-битный Delphi (Object Pascal). Он называется Free Pascal . Так что, хотя я не сомневаюсь, что это сложно, это не «настолько сложно», что это невозможно. Конечно, я не могу строить догадки об Эмбарседеро.
Полагаю, что наиболее близкий к "ответу" на ваш вопрос ответ с точки зрения Embarcadero содержится в этой статье о будущем компилятора Delphi Ника Ходжеса.
Если бы не ограничение на расширения оболочки (у меня есть одно, которое загружается в проводник Windows), я бы, вероятно, никогда не заботился о 64. Но из-за этого ограничения она мне нужна, и нужна сейчас. Поэтому мне, вероятно, придется разрабатывать эту часть на Free Pascal. Жаль, поскольку, кроме этого, есть немного приложений, которые действительно выиграют от 64. ИМО, большинство пользователей либо пьют "прохладную воду", либо злятся, что их обманули, заставив купить что-то, что звучало здорово, но превратилось в головную боль. Я знаю парня, который счастлив работать на Win7/64, чтобы иметь достаточно оперативной памяти для запуска полной копии XP в виртуальной машине, которая ему не нужна, если бы он купил Win7/32, как я ему говорил. :-<
Я думаю, что все были обмануты производителями HW, особенно продавцами RAM, которые в противном случае имели бы очень мягкий рынок.
В любом случае, вернемся к вопросу... Я нахожусь между молотом и наковальней. Мои клиенты предъявляют ко мне требования, связанные с архитектурным решением M$ (запрет на использование 32-битных DLL в Windows Explorer) и проблемами восприятия (64-битные должны быть вдвое лучше 32, или, может быть, 32 должны работать на "штрафном ядре" или что-то в этом роде). Так что я руководствуюсь в значительной степени "искусственной" мотивацией. И поэтому я должен проецировать это на Embarcadero. Но в конечном итоге, необходимость поддержки 64-битной версии в Delphi, IMO, в основном основана на BS. Но им придется реагировать на это, как и мне.
Аллен Бауэр из Embarcadero также недавно сказал, что им пришлось реализовать поддержку исключений совершенно по-другому для 64-битных "из-за различий в ABI исключений в Win64".
Я знаю, что вы спрашиваете о технических проблемах, но я думаю, что отдел маркетинга может быть самой большой проблемой ... Я уверен, что они гораздо больше воодушевлены перспективой появления новых рынков, которые принесут новые Таким образом, клиентам удается сменить приоритеты. Проблема (на мой взгляд) в плохой репутации: в прошлом мы видели kylix и delphi.net, которые оба были ehm kylixed. Я могу представить, что новые клиенты будут ждать и посмотреть, останется ли он поблизости, а это, в свою очередь, может решить, что эмбаркадеро уйдет из него преждевременно.
Тем не менее: безусловно, существуют некоторые проблемы и соображения по дизайну для x64, и я просто надеюсь, что команда Embarcadero поделится своими мыслями о них и обсудит их с сообществом (во избежание разглагольствования, как у нас по поводу изменения Unicode).