IMO a PE исполняемый файл не может работать на всех платформах.Каков принцип установки в окнах?
Я предполагаю, что установщик упаковывает исполняемые файлы для различных архитектур процессора и выбирает правильный после некоторой работы по обнаружению.
Но так ли, как крупные компании, такие как MS, выпускают свои продукты?
Microsoft выпускает только два настольных процессора, x86 и x86-64. Обычно они используют отдельные исполняемые файлы для каждого. Например, vcredist_x86.exe (x86) и vcredist_x64.exe (x86-64).
Однако в некоторых случаях они используют комбинированные установщики, такие как dotNetFx40_Full_x86_x64.exe.
Похоже, есть две школы мысли здесь:
Это самый простой подход, так как вам не нужно ничего делать в своем установщике. Многие из утилит Microsoft (в частности, все инструменты отладки) входят в отдельные пакеты x86/amd64/ia64; Однако я не уверен в их розничных продуктах.
Здесь у вас есть один монолитный 32-разрядный установщик, который будет работать на всех поддерживаемых в настоящее время платформах Windows; инсталлятор содержит двоичные файлы для каждой платформы. В установщике вы устанавливаете соответствующие бинарные файлы в зависимости от того, на какой платформе вы работаете. Я бы рекомендовал против этого, поскольку он требует много «магии» (пользовательский код, хаки и т. Д.), А также раздувает ваш установщик.
В настоящее время мы распространяем наш продукт, используя второй метод, но он оказался довольно головной болью, поэтому в будущем мы перейдем к первому методу. Единственным недостатком первого метода является то, что вы требуете от клиента использовать соответствующий установщик, хотя вы можете обернуть его в простой 32-разрядной оболочке, которая запускает соответствующий установщик.
О втором методе, это комбинированный инсталлятор 32-битный или 64-битный? – COMer
Он должен быть 32-разрядным, так как 32-разрядная операционная система не может запускать 64-разрядный исполняемый файл. – Luke
Если 32-разрядная версия может работать на x86-64, зачем мне нужны отдельные дистрибутивы для разных платформ? – COMer
Это на самом деле довольно сложная дискуссия, касающаяся битности ваших компонентов и их зависимостей, и ни один размер не подходит для подхода развертывания. Некоторые продукты являются собственными/неуправляемыми (не .NET), скомпилированными для x86 и распространяются как x86-пакет на x86 и x64. Некоторые из них будут чисто управляемыми (.NET) приложениями, которые упакованы как x86, но на самом деле будут работать как x64, если это возможно. Некоторым из них будут управляться приложения с неуправляемыми зависимостями и, возможно, придется использовать гибридный подход, такой как установка x86 DLL на WinSXS на 32-битных машинах и x64 DLL на WinSXS на 64-битных машинах. Другие не имеют прямых зависимостей за один раз, но могут потребоваться зарегистрироваться в качестве добавлений/плагинов/расширений для других приложений, таких как Office или Internet Explorer.
Некоторые пакеты распространяются как отдельные инсталляторы, некоторые из них используют гибридный подход, а некоторые будут разделены на несколько пакетов, завернутых через загрузчик. Некоторые попытаются скрыть раздувание с помощью загрузки веб-страниц, а некоторые предоставят вам все, что нужно для автономной установки.
Ответ очень много: он зависит.
Если 32-разрядная версия может работать на x86-64, зачем мне нужны отдельные дистрибутивы для разных платформ? – COMer
Вы не можете.Вам понадобится 64-разрядная версия, если вам требуется более 4 ГБ памяти (физическое расширение адреса еще ограничено 4 ГБ в Windows), чтобы использовать 64-разрядные инструкции только для драйверов для подключения к существующим 64-битным -битная программа и несколько других причин. В противном случае 32-разрядный должен быть точным. –
В дополнение к этим причинам 32-разрядная программа работает в эмулированной среде в 64-разрядных операционных системах. Иногда уровень эмуляции может мешать тому, что вы пытаетесь сделать; в этом случае лучшим решением является просто перекомпилировать его как 64-битную программу (http://blogs.msdn.com/b/oldnewthing/archive/2008/12/22/9244582.aspx). – Luke