2009 г. Методы обеспечения переносимости ПОД. В. Силаков, А.В. Хорошилов Содержание
Аннотация. Статья посвящена проблеме переносимости приложений между программно-аппаратными платформами. Предлагается обзор подходов к решению этой проблеме, появившихся за время развития ИТ, а также анализ преимуществ и недостатков каждого из них. Рассматриваются области применения существующих решений. ВведениеПроблема переносимости приложений между различными программно-аппаратными платформами ненамного моложе собственно компьютерных программ. Еще в конце шестидесятых годов озабоченность некоторых сотрудников AT&T Labs проблемой переносимости ОС UNIX на новые аппаратные платформы привела к созданию языка Си. Темпы развития компьютерной индустрии таковы, что проблемы сорокалетней давности кажутся достаточно простыми и решаемыми, по сравнению с тем, что мы имеем сегодня. Стремительное развитие связанных с компьютерами отраслей приводит к постоянному появлению новых программно-аппаратных платформ, информационных систем, и т.п., в то время как устаревшие комплексы уходят в небытие. Производители ПО, как правило, заинтересованы в быстром переносе своих продуктов на новые системы, чтобы захватить соответствующую долю рынка. Если приложение изначально проектировалось с оглядкой на возможность портирования, то этот процесс может оказаться существенно дешевле создания нового продукта. Будет проще и конечным пользователям, которые в новой системе увидят то же самое приложение, с которым работали раньше, что также способствует популярности продукта. В некоторых случаях большое внимание переносимости приложений уделяется и производителями платформ, на которых эти приложения выполняются — например, одним из принципиальных аспектов при разработке IBM мэйнфрейма System/S370 в конце 60х-начале 70х годов было сохранение обратной совместимости с System/S360, с целью упростить миграцию приложений своих клиентов [1]. Обратная совместимость с System/S360 сохранялась на протяжении всего жизненного цикла System/S370; более того, сохраняется она и в ее последователях — System/S390 и zSeries. Однако далеко не все производители столь щепетильны, и далеко не все платформы могут похвастаться столь длительным сроком жизни. Нередко с рынка уходят не только сами системы, но и их создатели, так что труднодоступными становятся не только сами системы, но и все сведения об их архитектуре. Исчезновение тех или иных платформ приводит к появлению унаследованного ПО — программных продуктов, необходимых для функционирования той или иной организации, но требующих для работы устаревшей программно-аппаратной платформы. В случае выхода из строя аппаратного обеспечения может оказаться, что найти ему замену очень сложно, дорого, а иногда и попросту невозможно, так как устаревшая ОС не работает на современном оборудовании (либо по причине принципиальных отличий архитектуры, либо по более прозаическим причинам — например, ввиду отсутствия необходимых драйверов). Для многих предприятий задача переноса таких приложений в более современное окружение является крайне актуальной [2,3]. Примеры из современностиНесмотря на то, что о проблеме переносимости известно достаточно давно и ее решению посвящено множество работ и исследований, постоянно возникают ситуации, когда выясняется, что данному вопросу вовремя не было уделено должное внимание и это привело к неприятным последствиям. Рассмотрим несколько реальных примеров таких ситуаций. В начале 2000-х годов компания Borland решила обратить свой взор на ОС Linux и выпустила среду разработки Kylix — аналог Delphi и C++ Builder. Такой шаг был изначально положительно оценен Linux-сообществом (даже несмотря на то, что Kylix не являлся продуктом с открытым исходным кодом, а бесплатной была только базовая версия системы) — в то время в этой ОС не было сравнимых по функциональности аналогов упомянутых программ.. Однако в основе Kylix лежал исходный код соответствующих сред разработки для ОС Windows, а для запуска на Linux использовался эмулятор wine[4]. Как показала практика, такой прямолинейный перенос, как использование эмулятора, не привел к созданию конкурентноспособного продукта — довольно быстро выяснилось, что wine не является достаточно надежным, чтобы гарантировать его стабильность [5]. Разработчикам приходилось иметь дело как с ошибками в своих программах, так и с некорректным поведением эмулятора. Ввиду закрытости проекта сложно оценить, насколько затратен был бы перенос программ на использование «родных» библиотек Linux; но основываясь на том факте, что работа над Kylix была заморожена, можно предположить, что задача оказалась слишком ресурсоемка. Другой пример недальновидного подхода к этому вопросу проявился в ходе организации проекта по разработке пакета свободного программного обеспечения (СПО) для образовательных учреждений России. Практически все программное обеспечение, которое разрабатывалось по заказу Министерства образования РФ в последние годы было предназначено для работы исключительно на платформе Microsoft Windows. Поэтому при внедрении пакета СПО на основе операционной системы Linux большая часть разработанных ранее образовательных программ оказалась недоступна, и только часть из них удавалось запустить с помощью эмулятора wine [4]. Схожие проблемы возникали и в стане разработчиков web-приложений. Известно несколько случаев, когда при разработке интернет-сервисов заказчик ограничивался требованием совместимости с браузером Internet Explorer, а через некоторое время под давлением клиентов был вынужден дорабатывать ПО для поддержки набирающего популярность Mozilla Firefox. Например, на основе опроса пользователей приложения Tasktop о желаемых нововведениях, проведенного в 2008 году, выяснилось, что наиболее востребованными являются поддержка ОС Linux и браузера Firefox. Реализация этих свойств стала приоритетным направлением разработки, и была представлена пользователям уже в ноябре 2008 года, в Tasktop 1.3 [6]. Отметим, что добавление такого нетривиального свойства, как поддержка новой операционной системы, не заняло много времени, поскольку основная часть приложения написана на интерпретируемом языке Java, а виртуальные машины для исполнения этого кода существуют как в Windows, так и в Linux. Более того, разработчики Tasktop планируют портировать свой продукт и на MacOS — ввиду наличия в этой ОС виртуальной машины Java, такая задача также не представляется слишком сложной. Приведенные примеры демонстрируют, что изначальная нацеленность на создание переносимого продукта позволяет достаточно безболезненно портировать его на платформы, поддержка которых изначально не планировалась (либо которых просто не существовало в момент начала разработки). Это позволяет производителям не оставаться в стороне от стремительного развития рынка и своевременно реагировать на запросы пользователей. В то же время невнимание к проблеме переносимости может привести к различным негативным техническим, экономическим и политическим последствиям:
Как мы уже отметили, проблема известна давно, и за время эволюции программного обеспечения появилось достаточно много подходов к созданию приложений, переносимых между различными системами. Рассмотрим те из них, что представляются наиболее популярными. Переиспользование бинарных файловПеренос приложения на новую программно-аппаратную платформу может пройти безболезненно для разработчиков, если старая и новая системы совместимы на бинарном уровне, то есть новая система поддерживает двоичный интерфейс приложений (Application Binary Interface, ABI), что позволяет использовать старые двоичные файлы приложения без каких-либо изменений. Можно выделить две основные составляющие ABI:
Совместимость форматов является критичной для возможности использовать двоичные файлы без изменений. При этом формат файлов достаточно сильно связан с аппаратной частью платформы, на которой функционирует система — в силу технических причин (разный размер указателей, различный порядок нумерации разрядов и т.п.) в общем случае сложно достичь совместимости систем, работающих на различных архитектурах. Что касается наборов библиотек и их функций, то их полной идентичности в различных системах ожидать трудно, однако во многих случаях пересечение множеств предоставляемых функций является достаточно большим. Многие производители операционных систем в настоящее время заботятся об обратной совместимости своих продуктов на бинарном уровне — гарантируется, что приложение, работающее в некоторой версии ОС, будет работать без перекомпиляции в более новых версиях системы на той же аппаратной архитектуре. В ряде случаев поддерживается возможность запуска приложений, написанных для той же системы, но на другой платформе — так, операционная система MacOS X, работающая на компьютерах Apple с процессорами Intel, использует динамический транслятор Rosetta для выполнения программ, предназначенных для машин с процессорами PowerPC [7]. Однако пользоваться такой возможностью следует с осторожностью. Во многих случаях совместимость обеспечивается за счет некоторого дополнительного слоя совместимости между системой и приложением, который может и не гарантировать полной совместимости — так, уже упомянутая Rosetta позволяет исполнять код для процессоров G3, G4 и AltiVec, но не для G5. Кроме того, дополнительный компонент системы является дополнительным потенциальным источником ошибок, а использование посредника в общем случае снижает производительность. Например, процессор Itanium способен выполнять код, созданный для платформы x86, однако производительность его в этом случае может уступать оригинальному x86 процессору с такой же тактовой частотой [8]. Переиспользование исходного кодаК сожалению, в большинстве случаев совместимость на бинарном уровне выполняется в рамках систем одного производителя, однако лишь немногие системы способны загружать исполняемые файлы, предназначенные для выполнения на платформах других поставщиков. Альтернативой использованию одних и тех же бинарных файлов явилось использование одного и того же исходного кода для сборки приложения на различных системах. Исторически, возможность переноса исходного кода между различными платформами появилась не сразу. В те времена, когда программы писались на ассемблере конкретной аппаратной платформы, добиться компиляции приложения на системе с другой архитектурой было практически нереально. Существенной подвижкой в этом направлении стало создание высокоуровневых языков программирования, не привязанных к конкретной архитектуре и позволяющих использовать одни и те же конструкции на различных системах. Например, именно озабоченность некоторых сотрудников AT&T Labs проблемой переносимости ОС UNIX на новые аппаратные платформы привела к созданию языка Си. Для обеспечения возможности использования одного и того же кода целевые системы должны предоставлять компиляторы для соответствующего языка программирования, вместе с необходимыми библиотеками. Естественно, что компиляторы для различных систем создаются различными производителями и могут достаточно сильно отличаться друг от друга. Такие отличия следует учитывать при написании кода. Частично эта задача облегчается следованием международных стандартов, разработанных для многих языков программирования. Однако далеко не все компиляторы поддерживают стандарты в полном объеме (хотя, как правило, не поддерживаются некоторые специфические конструкции языка, в плане же предоставления библиотечных функций ситуация гораздо лучше). Другой проблемой является относительная узость стандартов — несмотря на наличие во многих из них перечня функций, которые должны предоставляться любой удовлетворяющей стандарту средой разработки, эти перечни не описывают существенную часть функциональности, которая могла бы быть полезна при создании приложений — например, функции графического интерфейса, либо функции работы с мультимедиа. Помимо стандартов языков программирования, существуют стандарты, описывающие интерфейс прикладных программ (API, Application Programming Interface) — например, POSIX. Однако такие стандарты также, достаточно узки, и являются недостаточными для написания большинства приложений. В случае, если необходимая приложению функциональность не охватывается ни одним из стандартов, могут быть использованы продукты сторонних разработчиков, существующие на всех целевых системах и предоставляющие необходимые возможности. Такой продукт выступает в роли медиатора между приложением и операционной системой, скрывая от приложения процесс взаимодействия с последней. Характерным примером подобных продуктов являются кросс-платформенные библиотеки графического интерфейса пользователя — такие, как Qt, Gtk или wxWidgets. Реализация этих библиотек присутствует во всех основных операционных системах (FreeBSD, Linux, Windows, MacOS), а функции API, доступные программистам, практически идентичны для всех платформ. Кроме того, либеральность лицензий позволяет использовать эти библиотеки при создании достаточно большого спектра приложений. Если же медиатора, способного удовлетворить нужды разработчиков, не нашлось, то может быть целесообразно создать свой собственный, который можно будет использовать во многих продуктах компании. Такой подход оправдан, если можно четко выделить функциональность, которую должен предоставлять медиатор, и отделить реализацию этой функциональности от остальных частей продукта. Так, разработчики Mozilla в свое время решили создать собственный набор библиотек поддержки различных стандартов безопасности (в результате появился набор Network Security Services, NSS), а также собственную кросс-платформенную библиотеку, реализующую достаточно низкоуровневые функции (работы с потоками, памятью, вводом-выводом и т.п.). Результатом второй инициативы стало создание библиотеки NSPR (NetScape Portable Runtime). Отметим, что поскольку и NSS, и NSPR, являются продуктами с открытым исходным кодом, их использование в настоящее время не ограничивается проектами, разрабатываемыми Mozilla Foundation. Использование интерпретируемого кодаЕще одним подходом к обеспечению переносимости приложений является написание программного кода на интерпретируемых языках, использование которых не подразумевает создания исполняемых файлов в формате целевой операционной системы. Вместо этого интерпретатор последовательно считывает и выполняет инструкции непосредственно из текста программы. Прямолинейная интерпретация достаточно неэффективна — у интерпретатора практически нет возможностей для оптимизации кода. Для повышения эффективности во многих языках (Java, Perl, Python, семейство .NET) исходный код сначала транслируется в некоторое промежуточное представление (байт-код), который уже подается на вход интерпретатору. Стадия получения байт-кода фактически является разновидностью компиляции, и при ее осуществлении могут выполняться различные оптимизирующие преобразования. Однако и в этом случае зачастую не удается достигнуть производительности, присущей «родным» для системы приложениям, поскольку определенная часть времени тратится на разбор байт-кода и транслирование его в вид, подходящий для исполнения в целевой среде. Большей производительности удается достигнуть при использовании компиляции “на лету” (Just In Time compilation), когда байт-код транслируется в машинный код во время работы программы. Однако разработчикам JIT-компиляторов также приходится идти на компромисс между временем, уходящим на оптимизацию, и эффективностью получаемого кода, в результате чего производительность приложений может уступать коду, создаваемому “обычными” компиляторами. Кроме того, использование данной технологии увеличивает потребление памяти приложением, поскольку оттранслированный код также хранится в оперативной памяти. Также следует иметь в виду, что эффективность реализации интерпретаторов, также как и JIT-компиляторов, на различных платформах может отличаться. Использование эмуляторов ABIГоворя о бинарной переносимости, мы уже упомянули, что в ряде случаев операционная система может обеспечивать бинарную совместимость с другой системой за счет дополнительного слоя совместимости. При этом большинство существующих реализаций ограничивается обеспечением совместимости в рамках систем одного производителя. Из других примеров можно выделить поддержку запуска исполнимых файлов Linux в системе FreeBSD. Сам Linux также имел поддержку запуска исполнимых файлов других UNIX-систем, хотя эта функциональность не оказалась востребованной. В то же время существует много продуктов сторонних разработчиков, позволяющих загружать файлы других операционных систем путем использования транслятора, способного загружать файлы требуемого формата, преобразуя вызовы функций, осуществляемые внутри файла, в соответствующие вызовы текущей ОС (фактически, такой транслятор реализует ABI старой системы в новой системе). В качестве примера можно привести wine [4], предназначенный для запуска Windows-приложений в Linux, а также cygwin [9], обеспечивающий переносимость в обратную сторону. При этом, например wine достаточно легко использовать как часть приложения, не полагаясь на его доступность в целевой системе. Недостатком использования такого рода эмуляторов является потенциальная неполнота реализации интерфейса, необходимого приложению. Так, разработчики того же wine ориентируются на публично доступную информацию об API Windows (например, стандарт ECMA-234); так что если приложение использует какие-то недокументированные возможности этой ОС, то попытка его запуска в wine может оказаться неудачной. Отметим, что для достижения высокой производительности программы-эмуляторы зачастую используют достаточно низкоуровневые способы взаимодействия с системой, что, в свою очередь, ограничивает их собственную переносимость. Так, тот же wine содержит достаточно много кода на языке ассемблера архитектуры x86. Соответственно, использование этого эмулятора возможно либо в непосредственно x86 системах, либо в системах, предоставляющих возможность запуска x86 приложений. Поэтому при стремлении охватить большое число различных программно-аппаратных платформ, может возникнуть необходимость разных эмуляторов на различных системах. Кроме того, в определенных ситуациях прямолинейное использование эмуляторов по определению дает менее эффективные продукты, чем те, что используют «родные» средства целевой системы. В качестве примера можно привести уже упоминавшуюся ранее среду разработки Borland Kylix для Linux, основанную на использовании эмулятора wine. Косвенно использование эмулятора в этом случае означает использование тех же методик создания программ, которые применяются в исходной системе — ОС Windows. Однако, как показала практика, эмуляция этих методик не выдерживает конкуренции с аналогичными средствами ОС Linux — в частности, с компилятором GCC (прежде всего, в плане производительности программ, получаемых с помощью среды Kylix). ВиртуализацияАльтернативой эмуляции ABI некоторой системы является запуск копии такой системы внутри основной ОС, с использованием программ, эмулирующих аппаратное обеспечение — виртуальных машин. На такой машине устанавливается операционная система и другое окружение, необходимое приложению, а само приложение запускается уже в родной для него среде. Возможность запуска приложения на виртуальной машине зависит, в основном, от возможностей самой машины, нежели от разработчиков приложения. Тем не менее, программы, работающие с аппаратурой напрямую, могут встретить определенные трудности, поскольку им будет предоставлен доступ к устройствам виртуальной машины, а не непосредственно компьютера. Такая особенность ограничивает, например, возможность работы с графическими ускорителями изнутри виртуальных машин. В общем случае использование виртуальной машины достаточно ресурсоемко — ведь помимо собственно приложения, ресурсы компьютера потребляются самой машиной, а также работающими внутри нее программами, необходимыми для функционирования приложения (например, операционной системой). Поэтому выигрыш в производительности достигается, как правило, только в случае запуска машин, эмулирующих достаточно маломощные платформы на более производительных системах. Проблеме производительности виртуальных машин уделялось много внимания еще в 70е годы. Впервые требования, которым должна удовлетворять аппаратная архитектура машины, чтобы на ней можно было эффективно реализовать виртуализацию, были сформулированы Попеком и Голдбергом в 1974 году [10]. Основное требование сводится к разделению всех инструкций по разным уровням привилегий; при этом все инструкции, способные изменить состояние ресурсов виртуальной машины, а также инструкции, поведение которых зависит от конфигурации этих ресурсов, должны быть привилегированными. Монитор виртуальных машин (Virtual Machine Monitor, VMM — программная прослойка, занимающаяся распределением физических ресурсов между работающими виртуальными машинами), сам работая с наивысшими привилегиями, может перехватывать эти инструкции и эмулировать их поведение в соответствии со своими потребностями. Все непривилегированные инструкции должны выполняться непосредственно на аппаратуре. Поскольку доля привилегированных инструкций, как правило, невелика, то и затраты на их эмуляцию будут малы. Несмотря на то, что работа Голдберга и Попека посвящена машинам третьего поколения (IBM 360, Honeywell 6000, DEC PDP-10), сформулированные в ней требования справедливы и сегодня. Однако, для большинства современных архитектур приведенное выше требование не выполняется — существуют непривилегированные инструкции, влияющие на конфигурацию ресурсов либо зависящие от нее. В частности, для «классической» архитектуры x86 к числу таких инструкций относятся такие популярные инструкции, как push/pop, call, jmp и другие (более подробно данная проблема рассмотрена в [11]). Безусловно, построение виртуальной машины возможно и при наличии таких инструкций. Существуют подходы по определению и перехвату необходимых инструкций в процессе работы программы; по такому принципу работают популярные продукты типа VirtualBox [12] и VMWare [13], старающиеся напрямую выполнять все инструкции, для которых это возможно. Тем не менее, необходимость дополнительного отслеживания выполняемых инструкций может замедлить производительность программ внутри виртуальной машины по сравнению с «живой» системой. Отметим, что осознание разработчиками важности виртуализации привело к появлению расширений от Intel (Intel Virtualization Technology [14]) и AMD (AMD Virtualization [15]) для ее поддержки на платформах x86 и x86-64, которые позволяют либо вовсе избавится, либо существенно снизить число перехватываемых и эмулируемых инструкций. Альтернативным методом борьбы с «вредоносными» инструкциями является паравиртуализация, основанная на внесении изменений в гостевую операционную систему перед ее запуском в виртуальной среде; известным примером машин, работающих по принципу паравиртуализации, является Xen [16]. Однако в реальной жизни такая модификация не всегда доступна конечным пользователям. Существуют и гибридные подходы — например, проект vBlades для Itanium [17]. Стоит обратить внимание и на экономическую составляющую использования виртуальной машины конечным пользователям — в ряде случаев стоимость операционной системы и компонентов окружения, которые необходимо установить, может быть довольна значительна. Поэтому достаточно редки ситуации, когда производители сами советуют использовать виртуальные машины для запуска своих программ в системах, не поддерживаемых напрямую. Примерами исключений являются различные специфические системы, безопасное функционирование которых требует запуска в изолированной среде. Например, обучающая система Linuxgym [18] распространяет клиентскую часть в виде образа VMware, содержащего Ubuntu Linux с предустановленными необходимыми компонентами. Использование Web-технологийСтановящиеся с каждым годом все популярнее web-технологии также могут быть использованы для повышения переносимости программных продуктов. Можно выделить два основных способа построения приложений, использующих эти технологии:
Такое разделение довольно условно, поскольку в первом случае приложение также, как правило, имеет серверную и клиентскую части, и может допускать подключение клиентов с других машин. Например, подобным образом устроен Web-интерфейс сервера печати CUPS (Common Unix Printing System), который может быть использован для настройки принтеров как на локальной, так и удаленных машинах. В любом случае, использование web-браузера и сопутствующих инструментов облегчает задачу разработки графического интерфейса пользователя. Программа может либо создавать HTML-представление интерфейса, непосредственно интерпретируемое браузером, либо использовать технологии типа Flash, Silverlight и JavaFX, позволяющие создавать интерактивные файлы, для воспроизведения которых достаточно наличия соответствующего проигрывателя на целевой платформе. Зачастую такой проигрыватель встраивается в браузер как расширение. Однако хотелось бы подчеркнуть, что во многих ситуациях требования к среде, где функционирует серверная части приложения, существенно более строгие, чем требования к клиентской системе. Последние зачастую сводятся к требованию наличия браузера, поддерживающего определенные возможности. Для серверной же части может требоваться вполне конкретная программно-аппаратная платформа. Использование web-браузера для отрисовки графического интерфейса имеет как преимущества, так и недостатки. К преимуществам, помимо упомянутого выше снижения затрат на разработку, стоит отнести возможность настройки интерфейса пользователем по своему вкусу — изменением шрифтов, масштаба страницы и т.п. Основной недостаток подхода является следствием его достоинств — в разных браузерах одна и та же страница может отображаться по-разному — как вследствие пользовательских настроек, так и из-за особенностей конкретного браузера. Безусловно, существуют различные стандарты на HTML, CSS, JavaScript и прочие элементы, используемые при отображении web-документов, однако разные браузеры соответствуют этим стандартам в разной степени [19]. Поэтому разработчикам приходится либо проводить тестирование на различных браузерах [20], либо ограничиваться поддержкой только некоторых из них. Для автоматизации процесса тестирования существуют различные свободно доступные инструменты — например, сервис BrowserShots [21] позволяет получить снимки экрана с видом заданной страницы в различных браузерах (на данный момент доступно более 80) в Linux, Mac OS и Windows. Также отметим, необходимость создания больших распределенных систем привела к созданию архитектур, более сложных, чем клиент-серверная, и подразумевающих взаимодействие множества компонентов различной структуры. Исследования проблем разработки сложных программных комплексов привели к разработке парадигм, подразумевающих разбиение системы на отдельные компоненты, которые взаимодействуют друг с другом по строго определенным протоколам. При таком подходе каждый компонент не только может работать на отдельной машине, но также разрабатываться независимо от других. При этом (в идеале) процесс переноса компонента на другую платформу либо замена его на альтернативную реализацию никак не затрагивает других частей системы. К одной из первых попыток описания механизма взаимодействия компонентов распределенной системы можно отнести спецификацию CORBA (Common Object Request Broker Architecture), разработанную консорциумом OMG [22]. Однако CORBA в силу ряда причин не снискала большой популярности, и в настоящее время гораздо больший интерес проявляется к web-сервисам, использующим протоколы обмена сообщениями на базе XML. При проектировании сложных распределенных программных комплексов используется парадигма сервисно-ориентированной архитектуры (Service-oriented architecture, SOA [23]); при этом программные комплексы часто реализуются как набор web-сервисов. ЗаключениеЕсли невнимание к проблеме переносимости приводит к негативным последствиям и существует множество путей по ее решению, то возникает вопрос: так почему же ИТ индустрия не переориентируется на разработку переносимого ПО? Несложно догадаться, что разработка переносимого ПО имеет свои недостатки. Среди рассмотренных видов переносимости приложений очень привлекательным с точки зрения разработчиков является перенос непосредственно бинарных файлов на новую систему, позволяющий при относительно небольших затратах (в основном уходящих на тестирование) получить на новой системе приложение, имеющее всю необходимую функциональность. При этом потери в производительности если и возникают, то совсем небольшие. Однако для любой ОС число платформ, совместимых с ней на бинарном уровне, достаточно невелико. Использование эмуляторов может расширить их круг, но эмулятор — дополнительный потенциальный источник ошибок, который при этом может и не предоставлять всех необходимых функций. Потенциально больший охват дает переносимость исходного кода. Сложность портирования в этом случае может варьироваться в зависимости от того, насколько такая возможность учитывалась при разработке приложения; полезной с этой точки зрения является ориентация на различные интерфейсные стандарты, регламентирующие взаимодействие приложения с окружающей средой. Но существующие стандарты охватывают достаточно небольшую функциональность; в ряде случаев может помочь использование кросс-платформенных библиотек, другой же альтернативой является использование интерпретируемых языков. Спецификации таких языков не привязаны к конкретной платформе и можно полагаться на то, что интерпретаторы на разных системах поддерживают один и тот же набор функций. Среди недостатков подхода можно выделить меньшую производительность по сравнению с бинарным кодом. Архитектура SOA затрагивает более сложную проблему организации сложных программных комплексов, предлагая строить их в виде набора достаточно изолированных компонентов, каждый из которых может работать на своей собственной платформе и в случае необходимости может быть перенесен на другую (либо заменен на альтернативную реализацию).
Таблица 1. Примеры использования различных подходов к обеспечению функционирования приложений как в Windows, так и в Linux. Использование виртуальных машин также не требует больших усилий со стороны разработчиков ПО, хотя этот способ достаточно накладен, как в смысле производительности, так и ввиду необходимости иметь лицензии на все используемые операционные системы. Применение виртуализации оправдано в тех случаях, когда перенос приложения каким-то другим способом представляется экономически неэффективным. В частности, это относится ко многим унаследованным системам, для которых портирование на новую платформу означало бы практически полное переписывание приложения. В таблице 1 приведены примеры использования различных подходов к обеспечению переносимости ПО, которые используются разработчикам для создания программ, функционирующих как в Windows, так и в Linux. Интересно отметить подход Google, который не побоялся положиться на слой эмуляции wine для запуска Google Picasa в ОС Linux, несмотря на практически полное отсутствие успешных примеров крупных приложений, официально использующих такой метод. Подход с использованием библиотек-медиаторов более традиционен и применяется не один десяток лет. Вопрос обеспечения переносимости следует рассматривать в самом начале проекта, на стадии проектирования и выбора технологий и инструментов, которые будут использованы при его реализации. К сожалению, вряд ли можно сформулировать универсальное правило выбора средств для увеличения переносимости – такой выбор сильно зависит от конкретных требований, предъявляемых к приложению. На взгляд авторов, в настоящее время потенциально наибольший охват дает использование интерпретируемых языков – многие интерпретаторы работают на достаточно большом числе программно-аппаратных платформ. Естественно, использование таких языков имеет свои недостатки, и для ряда приложений может оказаться неприемлемым. Следующим по масштабу «охвата», на наш взгляд, идет использование кросс-платформенных библиотек и других медиаторов. Однако медиаторов, реализующих нужную функциональность, может и не существовать, а разработка собственных – оказаться достаточно трудоемким процессом. Тем не менее, даже при отказе от поддержки нескольких систем ввиду отсутствия средств и при ориентации на одну конкретную платформу, стоит строить архитектуру приложения таким образом, чтобы по возможности отделить части, использующие специфические для данной платформы интерфейсы и сервисы. Подводя итоги, отметим, что возможны ситуации, когда отказ от обеспечения переносимости разрабатываемого ПО оправдан; например, с достаточно большой долей вероятности такой выбор будет выгоден в краткосрочной перспективе. Однако при создании продуктов, которые планируется поддерживать в течении достаточно длительного периода, обеспечение переносимости может оказаться одним из ключевых факторов успеха. Повышение мобильности приложения в общем случае всегда связано с увеличением расходов на его разработку; однако чем раньше об этой проблеме задумаются разработчики и архитекторы, тем меньше будет стоимость переноса приложения на новую платформу. Литература
|
|
Содержание
- Введение
- Что такое средство переноса данных Windows?
- Что можно перенести на новый компьютер?
- Можно ли перенести программы?
- Какой метод переноса следует использовать?
- Сколько потребуется времени?
- Может ли перенос данных повлечь за собой и перенос программ-шпионов, вирусов и других типов вредоносного программного обеспечения?
- Какие версии ОС Windows совместимы со средством переноса данных Windows?
Введение
Средство переноса данных Windows помогает перенести многочисленные файлы, папки и параметры программ с одного компьютера на другой за один раз. После завершения переноса средство переноса данных Windows отображает сведения о перенесенных данных и предоставляет список программ, которые потребуется установить на новом компьютере, а также ссылки на другие программы, которые можно загрузить. Средство переноса данных Windows упрощает адаптацию пользователя к работе с новым компьютером, поскольку после переноса на новом компьютере будут находиться те же файлы, папки и параметры программ
Здесь приведены ответы на некоторые распространенные вопросы о переносе файлов и параметров
Средство переноса данных Windows реализует пошаговое руководство по переносу файлов и параметров с одного компьютера, работающего под управлением Windows, на другой. С помощью средства переноса данных Windows можно выбрать, что переносить на новый компьютер, и каким способом.
Как открыть средство переноса данных Windows.
- Для этого нажмите кнопку Пуск. В поле поиска введите Средство переноса данных, а затем в списке результатов выберите пункт Средство переноса данных Windows.
- Нажмите клавишу Win+R и введите команду migwiz
При появлении запроса пароля администратора или подтверждения введите пароль или предоставьте подтверждение.
Что можно перенести на новый компьютер?
Можно перенести большую часть файлов и параметров программ. А именно:
- Файлы и папки. Все, что находится в папках «Документы», «Музыка», «Изображения» и «Общие документы». С помощью дополнительных параметров можно выбрать дополнительные файлы и папки для переноса из других расположений
- Параметры электронной почты, список контактов и сообщения электронной почты
- Параметры программ. Параметры программ, настроенные на старом компьютере. С помощью средства переноса данных Windows нельзя перенести сами программы. Некоторые программы могут не работать в данной версии ОС Windows, включая программы для обеспечения защиты компьютера, антивирусные программы, брандмауэры (для обеспечения безопасности переноса данных на новом компьютере рекомендуется запустить брандмауэр до начала переноса) и программные драйверы
- Учетные записи пользователей и параметры. Фоновые рисунки рабочего стола, сетевые подключения, заставки, шрифты, параметры меню «Пуск», параметры панели задач, папки, определенные файлы, сетевые принтеры и диски, а также параметры специальных возможностей.
- Параметры подключения к Интернету и избранное. Параметры подключения к Интернету, избранное и куки-файлы.
- Музыка. Электронные музыкальные файлы, списки воспроизведения и обложки альбомов
- Изображения и видео. Изображения во всех форматах (например JPG, BMP, GIF) и личные видеозаписи
Можно ли перенести программы?
Нет. Средство переноса данных Windows переносит только параметры программ, но не сами программы. Чтобы использовать программы, установленные на старом компьютере, установите их на новом компьютере и затем перенесите файлы и параметры этих программ. Возможно, некоторые программы, например, программы для обеспечения безопасности компьютера и антивирусные программы, не будут работать в этой версии ОС Windows.
Какой метод переноса следует использовать?
Возможно несколько вариантов. Выберите вариант, подходящий для обоих компьютеров. Например, если компьютер не подключен к сети, невозможно перенести файлы и параметры на новый компьютер по сети
- Кабель для переноса данных. Что вам потребуется. Кабель средства переноса данных и USB-порт на каждом компьютере. Кабель средства переноса данных — это специальный USB-кабель, который подключается к двум компьютерам и взаимодействует со средством переноса данных Windows для передачи информации с одного компьютера на другой. Это один из самых простых способов переноса файлов и параметров на новый компьютер. Подключать кабель средства переноса данных следует только после запуска средства переноса данных Windows на новом компьютере и получения от последнего явной инструкции о подключении. Перед подключением кабеля к старому компьютеру необходимо вставить компакт-диск, поставляемый с этим кабелем, чтобы установить средство переноса данных Windows и продолжить процесс переноса.
Где его взять. Если кабель средства переноса данных не был включен в поставку компьютера, его можно заказать в Интернете или у изготовителя компьютера, либо купить в магазине по продаже электронного оборудования.Кабель средства переноса данных можно купить в интернет-магазине, у поставщика компьютера или в магазине по продаже электронного оборудования. Использование кабеля средства переноса данных позволяет упростить перенос файлов и параметров со старого компьютера на новый. Кабель средства переноса данных создан специально для работы со средством переноса данных Windows. При подключении кабеля к обоим компьютерам на экране появятся инструкции по использованию данного кабеля
- Сеть. Что потребуется. Сеть, к которой подключены оба компьютера, имеющие доступ к одним и тем же сетевым папкам или ресурсам.
Убедитесь, что оба компьютера подключены к одной сети. Запустите средство переноса данных Windows на новом компьютере (компьютер, на который нужно перенести файлы и параметры) и следуйте инструкциям. Ключ средства переноса данных Windows выполняет функцию пароля, защищая файлы и параметры при переносе их по сети - USB-устройство флэш-памяти или внешний жесткий диск
Что потребуется. USB-устройство флэш-памяти (для подключения которого требуется USB-порт на обоих компьютерах) или внешний жесткий диск, совместимый с обоими компьютерами.
Запустите средство переноса данных Windows на новом компьютере (компьютер, на который нужно перенести файлы и параметры) и следуйте инструкциям по использованию USB-устройства флэш-памяти или внешнего жесткого диска. В ходе переноса средство переноса данных Windows выдает примерную оценку дискового пространства, необходимого для переноса выбранных данных. Если перенос осуществляется с помощью USB-устройства флэш-памяти, желательно воспользоваться устройством, на котором достаточно свободного места для переноса всех данных за один раз.
Сколько потребуется времени?
На скорость переноса файлов и параметров влияет несколько факторов
- Количество и размер переносимых файлов и параметров
- Скорость работы компьютеров
- Выбранный способ переноса: кабель для переноса данных, USB-устройство флэш-памяти, внешний жесткий диск или сеть
Обычно чем больший объем переносится, тем больше времени занимает процесс. Чем быстрее работают компьютеры и выше скорость выбранного способа (например, кабель для переноса данных или сеть для большого количества файлов, USB-устройство флэш-памяти для нескольких файлов), тем быстрее произойдет перенос данных. Но вне зависимости от того, занимает перенос полчаса или несколько часов, использование средства переноса данных Windows обычно делает его более эффективным, чем копирование вручную
Может ли перенос данных повлечь за собой и перенос программ-шпионов, вирусов и других типов вредоносного программного обеспечения?
Да. При переносе со старого компьютера файлов, содержащих вредоносное программное обеспечение, оно будет также перенесено на новый компьютер. Настоятельно рекомендуется всегда запускать антивирусные программы и программы защиты от программ-шпионов (особенно на старом компьютере) перед выбором файлов для переноса. После переноса файлов на новый компьютер следует запустить эти программы, чтобы убедиться в отсутствии вредоносного программного обеспечения
Какие версии ОС Windows совместимы со средством переноса данных Windows?
С помощью средства переноса данных Windows можно осуществить перенос файлов и параметров программ с компьютера, работающего под управлением ОС Windows XP, Windows Vista или Windows 7 на другой компьютер, работающий под управлением Windows 7
Покупка нового ПК — это всегда волнительное событие, но омрачить его может осознание того, что на него придётся перенести все важные данные, а также заново установить программы. К счастью, Microsoft уже работает над тем, чтобы упростить настройку нового ПК — компания разрабатывает инструмент для экспорта файлов, приложений, настроек и данных для входа на другой компьютер под управлением Windows.
Первым этот инструмент в последней сборке Windows 11 Dev (26200.5600) обнаружил пользователь с ником PhantomOfEarth — большой поклонник операционной системы Microsoft, который довольно часто находит новые и скрытые функции в тестовых сборках Windows 11. На этот раз он продемонстрировал приложение Windows Backup с функцией переноса данных на новый компьютер. Судя по скриншоту, это будет действительно простой и удобный инструмент. Всё, что потребуется от пользователя, — это подключить оба компьютера к одной сети Wi-Fi, запустить приложение и выбрать «Перенести файлы на новый ПК», а на новом устройстве ввести указанный код.
Остаётся неясным, будет ли работать эта функция в Windows 10. С приближением даты окончания поддержки этой операционной системы многие пользователи, скорее всего, будут переходить на Windows 11, и этот инструмент оказался бы им весьма полезным.
Источник
Содержание статьи:
- Несколько заметок по поводу «переноса файлов и ПО»
- По поводу документов и файлов
- По поводу папки для загрузок по умолчанию
- По поводу переноса программ из старой ОС в новую
- По поводу удаления одной из копий ОС Windows
- Вопросы и ответы: 0
Вопрос от пользователя (типовой)
Здравствуйте.
У меня слетела Windows, никак не восстанавливалась. По вашему совету создал еще дин том через LiveCD, и установил на него новую ОС. Всё отлично, все работает, но есть несколько вопросов:
- как мне теперь перенести файлы и документы в новую систему (через поиск теперь не могу найти «старые» файлы);
- на предыдущей системе было установлено множество программ, которые не открываются здесь (даже если нажимать на файл «exe»). Как их перенести?
- все с интернета по умолчанию грузится на тот же раздел, на котором новая Windows, как это исправить?
- старая Windows занимает много места, как безопасно ее удалить?
Очень надеюсь, что сможете подсказать по этой теме…
Роман.
Здравствуйте.
Интересный «сборник» вопросов, на который нельзя дать однозначную инструкцию (т.к. некоторые моменты просто «неразрешимые», другие же — имеют несколько путей… 👀).
Тем не менее, ниже постараюсь привести обобщенный план действий, который будет под силу большинству пользователей (разумеется, есть ряд моментов, которые можно решить более искусно, но рекомендовать их для всех — нет смысла…).
*
Несколько заметок по поводу «переноса файлов и ПО»
По поводу документов и файлов
Как правило с этим типом «контента» не возникает никаких проблем: достаточно скопировать эти файлы в новые папки (разделы дисков), и ими можно будет пользоваться, как и ранее…
Вообще, по умолчанию, все пользовательские папки находятся по следующему пути «C:\Users\alex\» (где вместо «alex» — будет имя вашей учетной записи).
Для примера:
- C:\Users\alex\Documents — папка с документами (важно: обычно именно в этой папке лежат все сохранения (сейвы) из игр 😉);
- C:\Users\alex\Pictures — папка с картинками;
- C:\Users\alex\Music — музыка;
- C:\Users\alex\Desktop — рабочий стол (здесь хранятся не только ярлыки, которые были на рабочем столе, но и также все файлы).
Папки пользователя — Windows 10
👉 Кстати, если вас не устраивает текущее расположение системных папок (например, той же «Документы») — то им можно задать новое расположение. Для этого необходимо открыть свойства нужной папки (см. пример ниже 👇), и во вкладке «Расположение» задать новое место.
Свойства каталога с документами
Задать новое расположение папки с документами
*
По поводу папки для загрузок по умолчанию
В Windows 10 есть папка для загрузок по умолчанию (актуальна для подавляющего большинства программ). Чтобы ее найти — достаточно запустить проводник (сочетание Win+E) и обратить внимание на быстрые ссылки в верхнем меню. 👇
Если открыть свойства этого каталога — можно задать произвольное расположение этой папки (например, на другом разделе диска).
Куда загружаются файлы по умолчанию
Что касается загрузок программ и файлов в браузере — то практически в любом из них есть опции для задания нужного каталога. Например, в Chrome для этого достаточно открыть доп. настройки (страничка: chrome://settings/) и найти подраздел «Скачанные файлы». См. скрин ниже. 👇
Chrome — доп. настройки
С торрент-клиентами — аналогично. Мне в этом плане импонирует qBittorrent — в его настройках можно указать не только каталог загрузок, но и создать различные «правила» при скачивании (например, сериалы можно загружать по шагам — по серии).
Папка для загрузки торрентов // qBittorrent
*
По поводу переноса программ из старой ОС в новую
Пожалуй, это один из самых «больных» вопросов…
👉 Дело в том, что ряд программ в принципе нельзя перенести (по крайней мере я не представляю как сделать это 100%-корректно, чтобы всё и у всех работало). Речь идет:
- о антивирусах и защитном ПО (например, Avast, ключи с крипто-защитой и пр.);
- о ряде драйверов (особенно, если у вас версия «новой» ОС Windows отличная от «старой»);
- о больших программных пакетах (AutoCAD, 3ds Max Design, полный MS Office с надстройками, и пр.);
- о эмуляторах (например, для создания виртуальных CD/DVD-приводов и пр.);
- о некоторых играх и т.д.
Чтобы перенести их все в работоспособном виде — необходимо 👉 сделать полную копию системы (но этот вариант может не подойти, если ОС Windows начала сбоить…). Да и то, если вы эту копию собираетесь использовать на другом ПК — могут возникнуть «проблемы» с некоторым ПО…
***
Остальные программы можно попробовать перенести. Сделать это можно несколькими способами.
👉 Вариант 1 (ручной)
1) Зайти в папку с установленной программой (например, в «C:\Program Files» или «C:\Program Files (x86)) и скопировать каталог в аналогичную системную папку в новой ОС.
2) Далее проверить, чтобы 👉 имя учетной записи было одинаковым (т.е. и в «старой» ОС, и в «новой» оно должно быть точь-в-точь!).
3) Перенести также всю папку «Мои документы» (в ней могут быть сохранения из программ / игр). Выше в этой заметке показывал, как это сделать.
4) После, зайти в нижеперечисленные папки (в «старой» системе Windows) и скопировать каталоги нужной программы в аналогичные расположения в «новой» ОС Windows.
- C:\Users\alex\AppData\Local
- C:\Users\alex\AppData\LocalLow
- C:\Users\alex\AppData\Roaming
Где вместо «alex» — будет имя вашей учетной записи.
Способ мной неоднократно проверен. Использую для многих программ: Firefox, FileZilla, uTorrent и пр. (разумеется, все закладки, торренты, сохранения — остаются на месте!).
*
👉 Вариант 2 (авто)
Есть спец. утилиты для переноса программ из одной ОС Windows в другую. Речь идет о PickMeApp, PCmover и пр.
Как правило, их достаточно запустить в «старой» ОС Windows, затем выбрать из списка установленного ПО то, что нужно перенести, и запустить операцию архивации. А затем, уже в «новой» ОС Windows, разархивировать…
Скриншот из программы PickMeApp
*
👉 Вариант 3
Если у вас и «старая» Windows, и «новая» расположены на одном ПК — возможно и не стоит чего-то куда-то переносить?.. 😉 Если нет проблемы со свободным местом — достаточно найти нужные «EXE» файлы и запускать их из «старого» месторасположения…
*
По поводу удаления одной из копий ОС Windows
Совет: не торопитесь этого делать. Часто, многие вспоминают о каких-то нужных файлах (настройках) спустя неделю-две-три…
Допустим, у нас на диске «С:» установлена «новая» Windows 10, а на «F:» — «старая». Файлы и программы мы уже перенесли, и теперь «старую» ОС нам нужно удалить. Как это лучше сделать?.. 😉
1) Создайте точку восстановления в текущей ОС, и проверьте, что у вас есть установочная флешка (этот шаг не обязателен, но если пойдет что-то не так — быстро восстановить ОС не получится…).
2) Нажмите Win+R, и в окне «выполнить» используйте команду msconfig — в открывшемся окне перейдите во вкладку «Загрузка», и:
- выделите нужную копию ОС Windows (на диске «C:» в моем случае) и нажмите по кнопке «Использовать по умолчанию»;
- после, выделите ненужную копию ОС, и нажмите «Удалить». См. пример ниже. 👇
Конфигурация системы — загрузка
3) Теперь на диске «F:» (со старой Windows в моем случае) есть ненужные нам каталоги с файлами. Речь о:
- Program Files и Program Files (x86);
- Windows;
- Пользователи;
- ProgramData.
Чтобы их удалить можно пойти следующими путями:
- создать на диске «F:» новую папку и переименовать ее в «Windows.old». Затем перенести в нее всё ненужное (обозначенные выше папки). После откройте свойства этого диска «F:» и запустите очистку. См. пример ниже. 👇
Очистка диска
- можно загрузиться с LiveCD-флешки и удалить любые папки с любого диска (но этот способ достаточно «опасный» для начинающих пользователей…);
- отформатировать этот раздел диска (достаточно зайти в «Мой компьютер» и нажать ПКМ на нужном диске).
*
Если у вас есть иные сподручные решения и рекомендации — возможно, они кому-то помогут. Поделитесь в комментариях. Заранее благодарю!
Успехов!
👋
Содержание
Очень часто (и это стало обыденной практикой) программы, написанные для одной машины, необходимо перенести на другой компьютер, оснащенный другим процессором или другой операционной системой, а зачастую и тем и другим одновременно. Этот процесс носит название перенос, или перенесение (porting), и в одних случаях он может оказаться очень простым, а в других — предельно трудным. Это зависит от того, каким образом была первоначально написана программа. Поэтому, программа, которая легко поддается переносу, называется переносимой, мобильной, или машинонезависимой[1](portable). Если программа не относится к разряду переносимых, как правило, это объясняется тем, что она содержит большое количество элементов, зависящих от типа машины, — то есть, она имеет фрагменты кода, которые будут выполняться только в одной определенной операционной системе или на одном конкретном процессоре. Язык С позволяет создавать переносимый код, но для достижения этой цели необходимо проявлять особую тщательность и внимание к деталям. В данном разделе рассматриваются несколько конкретных проблем, возникающих при создании машинонезависимых программ и предлагается ряд решений таких проблем.
Использование #define
Возможно, самый простой и эффективный способ сделать программы переносимыми состоит в том, чтобы представить каждое зависящее от типа системы или процессора «магическое число» макросом #define. Магическими эти числа были названы потому, что они представляют собой такие параметры системы, как размер буфера, используемого для обращения к диску, специальные команды управления экраном и клавиатурой, а также информацию о распределении памяти, иными словами, все то, что может измениться при переносе программы. Такие #define-определения не только делают все магические числа очевидными для программиста, выполняющего перенос, но к тому же упрощают выполнение всей работы. Ведь поскольку их значения необходимо будет изменить только однажды и в одном месте, следовательно, не придется «перетряхивать» всю программу.
Например, рассмотрим оператор fread(), который по своей природе является непереносимым:
fread(buf, 128, 1, fp);
В данном случае проблема заключается в том, что размер буфера (число 128) является жестко запрограммированным параметром функции fread(). Это значение может вполне подходить для одной операционной системе, но окажется меньше оптимальной величины для другой. А вот более удачный способ кодирования этой же функции:
#define BUF_SIZE 128
fread(buf, BUF_SIZE, 1, fp);
В последнем варианте при переносе на другую систему понадобится всего лишь изменить определение #define — и все ссылки на BUF_SIZE будут исправлены автоматически. Это не только облегчает процесс внесения изменений, но и вдобавок уберегает от массы ошибок при редактировании. Помните, что в реальной программе может присутствовать бездна ссылок на BUF_SIZE, поэтому переносимость программы возрастает многократно.
Зависимость от операционной системы
Код практически всех коммерческих программ адаптирован для конкретной операционной системы, под управлением которой предполагается их работа. К примеру, программа, написанная для Windows 2000, может использовать многопотоковую многозадачность, тогда как программа, написанная для 16-разрядной Windows 3.1, не может. Дело в том, что определенная привязка к особенностям конкретной операционной системы совершенно необходима, чтобы получить по-настоящему хорошие, быстродействующие и по-коммерчески жизнеспособные программы. Однако с другой стороны, зависимость от операционной системы усложняет процесс переноса программ.
Хотя и не существует жестких правил, следуя которым можно было бы минимизировать зависимость разрабатываемых программ от типа операционной системы, позвольте предложить маленький совет. Отделяйте в разрабатываемой программе те части, которые относятся непосредственно к приложению от тех фрагментов, которые осуществляют взаимодействие с операционной системой. Тогда при переносе программы в новую среду потребуется изменить только модули интерфейса.
Различия в размерах данных
Если вы хотите написать переносимый код, никогда не следует полагаться на ожидаемые размеры данных. Например, надо всегда учитывать отличия между 16-разрядной и 32-разрядной средами. Размер слова в 16-разрядном процессоре равен 16 битам, а в 32-разрядном процессоре — 32 битам. Поскольку размер слова часто совпадает с размером данных типа int, то код, созданный в предположении, что переменные типа int являются, к примеру, 16-разрядными, не будет корректно работать после переноса его в 32-разрядную среду. Чтобы избежать жесткой привязки к размеру, там, где программе понадобятся сведения о количестве байтов, составляющих какую-нибудь величину, обязательно используйте оператор sizeof. Например, следующее выражение заносит значение типа int в дисковый файл и будет работать в любой среде:
fwrite(&i, sizof(int), 1, stream);
[1]Термины портабильность и портабильный к настоящему времени несколько утратили свою первоначальную популярность.