До чего бывает неприятно: есть 32-битная библиотека на C++, которую вы уже много лет лицензируете клиентам, а теперь все больше и больше клиентов хочет использовать ее из 64-битных программ. Вы развиваете библиотеку, исправляете ошибки, дорабатываете, холите и лелеете ее, она прекрасно работает, а клиентам это не так и важно – они просто хотят 64 бита. Им даже не важно, будет ли она вся 64-битной, они просто хотят ее использовать.
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
А теперь добро пожаловать в реальный мир.
Кода, например, два миллиона строк, и код сложный (внезапно), так что переписывать егодолго дооолго. Когда вы закончите, у вас будет одна универсальная версия кода на C++, но вы будете компилировать его и на 32, и на 64 бита, т.е. исполняемого кода станет вдвое больше.
Вдвое больше кода →
→ вдвое больше тестирования;
→ вдвое больше отладки;
→ вдвое больше сопровождения.
Намечался WIN, а уже больше похоже на FAIL.
Вторая попытка. Переписываем все на C#. C# компилируется в волшебный байткод, который потом без проблем работает на машине любой разрядности. WIN?
— C++ и C# похожи, но все же различаются, поэтому переписывать много кода – ооочень долго;
— нужно будет заново профилировать весь код;
— нужно будет заново полностью тестировать весь код;
— очень сложно переписывать понемногу – пока не перепишете все, вам нечего лицензировать клиентам;
— все равно есть клиенты, которым неудобно использовать библиотеки на .NET.
Опять FAIL. Если перечисленные проблемы не убедили, что переписывать весь код может выйти слишком дорого, Капитан Очевидность™ раскрывает тему переписывания тут (оригинал) и отчасти тут.
Что делать, если у вас капитализация меньше, чем у Microsoft, а заставить 32-битный код работать из 64-битных программ хочется?
Попробуйте не переписывать. Попробуйте подружить ваш 32-битный код с 64-битным кодом. На Windows для этого есть технология COM – все необходимое для ее работы входит прямо в состав операционной системы.
«Что? Да COM был старьем, когда я в первый класс собирался идти!» – возразиттолстый тролль читатель в теме. На самом деле… Да, COM существует очень давно. Но колесо придумано гораздо раньше, чем COM, и все равно им пользуются. По одной причине: колесо решает возложенные на него задачи. С COM то же самое – это технология, которая работает.
Придется все же немного потрудиться:
— спроектировать интерфейс библиотеки,
— написать кучу вспомогательных механизмов (здесь здорово поможет ATL),
— протестировать вспомогательные механизмы…
… «вот, опять нечеловеческие усилия» – возразит читатель. Да, поначалу разработка COM-компонентов вызывает небольшие затруднения, придется это пережить. Зато на выходе:
— библиотеку можно использовать из широкого спектра языков – C, C++, C#, VB.NET, Delphi, многие скриптовые языки (и это неполный список);
— можно сделать компонент, код которого выполняется в отдельном процессе;
— сам код остается полностью 32-битным;
«В отдельном процессе? Клиентам ведь придется париться – нужно будет, чтобы их программа умела дружить с компонентом в другом процессе.» – возразит читатель и будет неправ. COM включает в себя магию (называется «маршаллинг»), которая позволяет программе вызывать код компонента так, как будто тот выполняется в ее собственном процессе. Клиент по-прежнему может писать что-нибудь в духе:
COM самостоятельно:
— запустит отдельный процесс,
— попросит его создать объект,
— сам организует связь между процессом программы клиента и процессом компонента,
— предоставит программе клиента объект, который с ее точки зрения ведет себя как настоящий COM объект.
Все вызовы, выполняемые программой клиента, будут перенаправляться в тот отдельный процесс совершенно прозрачно.
Как обычно, есть мелкий шрифт. Магия для организации связи требует накладных расходов, поэтому есть смысл проектировать интерфейс так, чтобы методов в нем было поменьше, а полезной работы они делали побольше – тогда доля магии в общем времени работы не будет беспокоить.
Есть еще неприятный момент. Работа компонента в отдельном процессе реально нужна только тем клиентам, у которых программы 64-битные. Клиентам, у которых программы 32-битные, от этого никакого толку, одни накладные расходы. COM позволяет сделать компонент, работающий в том же процессе, но снова две версии компонента – снова больше кода, больше тестирования, больше сопровождения.
Британские ученые™ недавно нашли решение и этой проблемы. Это COM+ – технология, которая среди прочего позволяет заставить компонент, предназначенный для работы в том же процессе, работать в отдельном. COM+ есть во всех версиях Windows, начиная с Windows 2000. Вы делаете компонент для работы в том же процессе и при необходимости кладете его в COM+ (Start→Settings→Control Panel→Administrative Tools→Component Services, там несколько щелчков мышью).
Программа клиента работает как обычно. Если программа 32-битная, компонент создается в том же процессе. Если программа 64-битная, включается магия, COM+ запускает так называемый суррогатный процесс, загружает компонент в него, организует маршаллинг, дальше компонент используется прозрачно из отдельного процесса.
По этому пути мы пошли, когда (внезапно) осознали, что COM-компонент для интеграции с Recognition Server невозможно использовать из 64-битных программ, а очень нужно. Кода там не очень много и мы бы могли его перенести, но оказалось намного проще использовать для решения этой проблемы COM+. Сравните – много не особо полезной кропотливой работы или несколько щелчков мышью.
Не всегда стоит переписывать весь код на 64 бита просто ради переписывания. Освободившееся время можно потратить на троллинг этого поста.
Дмитрий Мещеряков
Руководитель группы разработки Recognition Server
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
А теперь добро пожаловать в реальный мир.
Кода, например, два миллиона строк, и код сложный (внезапно), так что переписывать его
Вдвое больше кода →
→ вдвое больше тестирования;
→ вдвое больше отладки;
→ вдвое больше сопровождения.
Намечался WIN, а уже больше похоже на FAIL.
Вторая попытка. Переписываем все на C#. C# компилируется в волшебный байткод, который потом без проблем работает на машине любой разрядности. WIN?
— C++ и C# похожи, но все же различаются, поэтому переписывать много кода – ооочень долго;
— нужно будет заново профилировать весь код;
— нужно будет заново полностью тестировать весь код;
— очень сложно переписывать понемногу – пока не перепишете все, вам нечего лицензировать клиентам;
— все равно есть клиенты, которым неудобно использовать библиотеки на .NET.
Опять FAIL. Если перечисленные проблемы не убедили, что переписывать весь код может выйти слишком дорого, Капитан Очевидность™ раскрывает тему переписывания тут (оригинал) и отчасти тут.
Что делать, если у вас капитализация меньше, чем у Microsoft, а заставить 32-битный код работать из 64-битных программ хочется?
Попробуйте не переписывать. Попробуйте подружить ваш 32-битный код с 64-битным кодом. На Windows для этого есть технология COM – все необходимое для ее работы входит прямо в состав операционной системы.
«Что? Да COM был старьем, когда я в первый класс собирался идти!» – возразит
Придется все же немного потрудиться:
— спроектировать интерфейс библиотеки,
— написать кучу вспомогательных механизмов (здесь здорово поможет ATL),
— протестировать вспомогательные механизмы…
… «вот, опять нечеловеческие усилия» – возразит читатель. Да, поначалу разработка COM-компонентов вызывает небольшие затруднения, придется это пережить. Зато на выходе:
— библиотеку можно использовать из широкого спектра языков – C, C++, C#, VB.NET, Delphi, многие скриптовые языки (и это неполный список);
— можно сделать компонент, код которого выполняется в отдельном процессе;
— сам код остается полностью 32-битным;
«В отдельном процессе? Клиентам ведь придется париться – нужно будет, чтобы их программа умела дружить с компонентом в другом процессе.» – возразит читатель и будет неправ. COM включает в себя магию (называется «маршаллинг»), которая позволяет программе вызывать код компонента так, как будто тот выполняется в ее собственном процессе. Клиент по-прежнему может писать что-нибудь в духе:
ThatLibrary.Worker worker = new ThatLibrary.WorkerClass();
worker.DoWork();COM самостоятельно:
— запустит отдельный процесс,
— попросит его создать объект,
— сам организует связь между процессом программы клиента и процессом компонента,
— предоставит программе клиента объект, который с ее точки зрения ведет себя как настоящий COM объект.
Все вызовы, выполняемые программой клиента, будут перенаправляться в тот отдельный процесс совершенно прозрачно.
Как обычно, есть мелкий шрифт. Магия для организации связи требует накладных расходов, поэтому есть смысл проектировать интерфейс так, чтобы методов в нем было поменьше, а полезной работы они делали побольше – тогда доля магии в общем времени работы не будет беспокоить.
Есть еще неприятный момент. Работа компонента в отдельном процессе реально нужна только тем клиентам, у которых программы 64-битные. Клиентам, у которых программы 32-битные, от этого никакого толку, одни накладные расходы. COM позволяет сделать компонент, работающий в том же процессе, но снова две версии компонента – снова больше кода, больше тестирования, больше сопровождения.
Британские ученые™ недавно нашли решение и этой проблемы. Это COM+ – технология, которая среди прочего позволяет заставить компонент, предназначенный для работы в том же процессе, работать в отдельном. COM+ есть во всех версиях Windows, начиная с Windows 2000. Вы делаете компонент для работы в том же процессе и при необходимости кладете его в COM+ (Start→Settings→Control Panel→Administrative Tools→Component Services, там несколько щелчков мышью).
Программа клиента работает как обычно. Если программа 32-битная, компонент создается в том же процессе. Если программа 64-битная, включается магия, COM+ запускает так называемый суррогатный процесс, загружает компонент в него, организует маршаллинг, дальше компонент используется прозрачно из отдельного процесса.
По этому пути мы пошли, когда (внезапно) осознали, что COM-компонент для интеграции с Recognition Server невозможно использовать из 64-битных программ, а очень нужно. Кода там не очень много и мы бы могли его перенести, но оказалось намного проще использовать для решения этой проблемы COM+. Сравните – много не особо полезной кропотливой работы или несколько щелчков мышью.
Не всегда стоит переписывать весь код на 64 бита просто ради переписывания. Освободившееся время можно потратить на троллинг этого поста.
Дмитрий Мещеряков
Руководитель группы разработки Recognition Server
