Як запустити програму в 64 бітному режимі

Ваш комп'ютер, швидше за все, працює на 64-розрядній версії Windows. Але якщо відкрити «Диспетчер завдань», то Ви побачите, що більшість програм у Вашій системі досі 32-розрядні. Чи справді це проблема?

Є багато відмінностей між 64-розрядними та 32-розрядними версіями Windows. 64-розрядні версії Windows можуть виконувати 32-розрядні програмне забезпечення, але 32-розрядні версії Windows не можуть виконати 64-розрядне програмне забезпечення.

Як дізнатися про розрядність програми?

Давайте скористаємося диспетчером завдань, щоб побачити, які ваші програми є 64-розрядними, а які 32-розрядними. Клацніть правою кнопкою миші на панелі завдань і виберіть пункт «Диспетчер завдань» або натисніть комбінацію клавіш Ctrl+Shift+Esc, щоб відкрити його.

Подивіться на стовпець із назвами процесів. Якщо ви будете використовувати 64-розрядну версію Windows 8.1 або 8, ви побачите слово «(32-bit)» після кожного імені 32-розрядної версії програми. Якщо Ви будете використовувати 64-розрядну версію Windows 7, то Ви побачите натомість «*32».

32-розрядні програми зазвичай встановлюються в папку C:\Program Files (x86)\ на 64-розрядних версіях Windows, в той час як 64-розрядні програми зазвичай встановлюються в папку C: Program Files.
Це просто правило. Але ніхто не говорить, що немає іншого правила, в якому забороняється встановлювати 64-розрядні програми в папку C: Program Files (x86). Наприклад, Steam - 32-розрядна програма, таким чином, вона встановлюється в "C: Program Files (x86)" за замовчуванням. Ігри, які Ви встановлюєте в Steam, встановлені в папку C: Program Files (x86) Steam за замовчуванням, в т.ч. навіть 64-розрядні версії ігор.

Якщо ви порівняєте дві різні папки Program Files, то Ви знайдете, що більшість Ваших програм, найімовірніше, встановлені в папку C:\Program Files (x86). І, ці програми здебільшого є 32-розрядними.


Робота 32-розрядного програмного забезпечення на 64-розрядній операційній системі

На перший погляд, це здається жахливим, що більшість ваших програм Windows, не користуються 64-бітною архітектурою операційної системи Ви можете подумати, що є втрати в продуктивності для запуску 32-розрядних програм у 64-розрядній операційній системі, але це не так.

Windows виконує 32-розрядні програми через рівень сумісності WoW64 на 64-розрядних версіях Windows. Однак 64-розрядні процесори Intelта AMD назад сумісні та можуть безпосередньо виконувати 32-розрядне програмне забезпечення. Усі ваші 32-розрядні Windows-програми працюватимуть так само, як вони працювали б на 32-розрядній версії Windows. Таким чином, немає жодних перешкод до виконання цих програм на 64-розрядній операційній системі.

Навіть якщо кожна програма, яку Ви використовуєте, є все ще 32-розрядною, то Ви матимете вигоду, тому що Ваша операційна система сама працюватиме в 64-розрядному режимі. А, 64-розрядна версія Windows є безпечнішою.

64-бітові програми та 32-бітові програми: що краще?

32-бітові програми запускаються без проблем на 64-бітових версіях операційних систем Windows. Але чи було б краще, якби всі ваші програми були б 64-бітними?

Є безперечно переваги у 64-бітових програм. 32-розрядні програми можуть використовувати лише 2 ГБ пам'яті, тоді як 64-бітові програми можуть використовувати набагато більше. Якщо програма, швидше за все, потрапила під атаку, додаткові функціїбезпеки, які застосовуються до 64-бітових програм, можуть допомогти. Google Chromeв даний час є 32-бітним додатком навіть на 64-бітних версіях Windows, але вже з'явилася 64-бітна версія цієї програми. І Google обіцяє, що 64-бітна версія Chrome буде швидше, безпечнішою і стабільнішою.


Деякі програми пропонують 64-розрядні версії. Наприклад: Photoshop, Itunes, Microsoft Office, і деякі з найпопулярніших програм для Windows, і всі вони доступні у 64-бітному вигляді. Останні ігритакож часто є 64-розрядними, щоб вони могли використовувати більше 2 ГБ пам'яті.


Багато програм не зробили перехід на 64-біти, і більшість ніколи його не зроблять. Ви все ще можете запускати сьогодні більшість 32-бітних програм Windows, навіть ті, які були випущені десять років тому, на 64-бітній версії Windows, навіть якщо їх розробники вже оновлюють.

Розробник, який хоче забезпечити 64-розрядну версію своєї програми, має виконувати багато додаткової роботи. Він повинен переконатися, що існуючий код компілюється та правильно працює як 64-бітове програмне забезпечення. Він повинен забезпечити і підтримувати дві окремі версії програми, оскільки користувачі під керуванням 32-розрядної версії Windows не можуть використовувати 64-розрядну версію.

Давайте візьмемо, як приклад програму Evernote для настільна версія Windows. Навіть якби вони випустили б 64-розрядну версію Evernote, користувачі, найімовірніше, не помітили б різниці взагалі. 32-розрядна програма може чудово працювати і на 64-розрядній версії Windows, і якщо немає помітних переваг, то немає сенсу в 64-бітній версії.

Де знайти 64-розрядні програми

Ви, як правило, не будете здатні вибирати між 32-бітної та 64-бітної версій програмного забезпечення. Наприклад, під час встановлення Itunes для Windows, веб-сайт Apple автоматично направляє вас до 32-розрядної або 64-розрядної версії інсталятора в залежності від версії Windows. При інсталяції Photoshop для Windows зазвичай встановлюються і 32-розрядні, і 64-розрядні виконувані файли. Photoshop автоматично вибирає їх. Іноді можна побачити окремі посилання для завантаження 32-бітних і 64-бітних версій програм, але це не так поширене.

Важливо не займатися пошуком 64-бітових програм, а знайти програми, які працюють добре для вас. Для більшості програм, насправді немає значення 64-бітна версія або 32-бітна.


Легко поставити запитання, чому так багато додатків все ще 32-бітні, коли ви відкриваєте ваш менеджер завдань. Але це не дуже велика проблема, і ось чому. Тому що більшість програм ні чого не виграють під час переходу на 64-бітові редакції версії програм. Навіть якщо розробники зробили всю роботу і випустили 64-бітові версії всіх маленьких настільних програм та утиліт, які ви використовуєте у Windows, то ви не змогли б помітити різницю для більшості з них.

Поява 64-розрядних Windows викликала чимало запитань. Підтримка 32-бітових програм, драйверів і всього того, що розраховано на архітектуру x86. Встановлення та особливості використання програм. Введені обмеження для 32-розрядних програм. Підтримка старих режимів та багато іншого. Все це ніяк не могло залишитися осторонь. Адже пласт 32-розрядної спадщини занадто великий, і в 64-бітовому середовищі його мало чим можна замінити, навіть зараз.

У цій статті наводиться огляд підсистеми Windows на Windows 64 (WOW64) та її методів, які дозволяють Windows підтримувати 32-бітові програми на 64-бітній системі.

Примітка: Перша спроба впровадити 64-розрядні системи була досить провальною Жорсткі обмеження та відсутність реальних переваг давалося взнаки. На той момент навіть драйвера під 64-розрядні системи було досить складно знайти. Не кажучи вже про програми, на яких хоч якось була б помітна різниця. Зняття обмеження на 3Гб оперативної пам'яті, Безумовно, сьогодні сильна перевага, але на той момент це більше нагадувало гарний слоган.

Пристрій підтримки 32-бітових програм у 64-розрядній Windows

Windows 32 на Windows 64 (WOW64)

WOW64 емулює 32-бітну Windows

У Windows 64 32-бітові програми виконуються в емульованій 32-розрядній операційній системі, яка називається Windows 32 на Windows 64, або WOW64 для стислості. Основним завданням WOW64 є перехоплення та обробка всіх системних викликів від 32-розрядних програм.

Для кожного перехопленого системного виклику, WOW64 створює 64-розрядний системний виклик, перетворюючи 32-бітові структури даних на відповідні 64-бітові. Надалі 64-бітовий системний виклик передається ядру операційної системи для обробки. Усі отримані вихідні дані 64-бітового виклику будуть перетворені та передані у тому форматі, на який програма розраховувала. Іншими словами, реальні запити до ядра системи завжди 64-бітові. Підсистема WOW64 лише виступає як посередник, притворюючи дані у відповідні формати.

Як і 32-бітові програми, WOW64 виконується від імені користувача, тому помилки, які можуть відбуватися під час перетворення системних викликів, будуть відбуватися на рівні користувача. І ніяк не торкнуться 64-бітове ядро ​​операційної системи.

Той факт, що WOW64, як і 32-бітна програма, виконується в режимі користувача, пояснює причину відсутності підтримки 32-бітових драйверів. Якщо говорити іншими словами, то для коректного запуску драйверам потрібен режим ядра, який не може забезпечити WOW64. Тому, якщо у вас 64-розрядна Windows, всі драйвера повинні бути 64-бітними.

Емулятор WOW64 складається з наступних 64-розрядних бібліотек:

Примітка: Це єдині 64-розрядні бібліотеки, які завантажуються в 32-розрядний процес

  • Wow64.dll – ядро ​​інфраструктури системи емуляції. Лінкує дзвінки в точки входу Ntoskrnl.exe
  • Wow64Win.dll - лінкує виклики в точки входу Win32k.sys
  • Wow64Cpu.dll - перемикає процесор між 32-бітним та 64-бітним режимом
  • Ntdll.dll – 64-бітна версія Wow64.

Wow64.dll завантажує 32-бітну версію (x86) Ntdll.dll і всі необхідні 32-бітові бібліотеки, які в основному залишилися без змін. Однак, деякі з цих 32-розрядних бібліотек все ж таки були змінені, щоб коректно виконуватися в WOW64. Як правило, такі зміни були зроблені через те, що вони використовують оперативну пам'ять разом із 64-розрядними компонентами системи.

Керування файлами та налаштуваннями реєстру в WOW64

На додаток до функцій перехоплення та обробки системних викликів, інтерфейс WOW64 також повинен гарантувати, що файли та параметри реєстру 32-бітових програм зберігатимуться окремо від файлів і ключів реєстру 64-розрядних програм. Для досягнення цієї мети WOW64 використовує два механізми. Перенаправлення файлів і реєстру, а також дублювання ключів реєстру. Перенаправлення підтримує логічне представлення даних і відображає їх так, якби програма запускалася в 32-розрядній Windows. Дублювання ключів реєстру гарантує, що зміна ряду параметрів, які не залежать від розрядності, будуть доступні як 32-розрядним, так і 64-розрядним додаткам.

Перенаправлення файлів

Перенаправлення файлів дозволяє гарантувати, що файли та каталоги 32- та 64-бітових програм зберігатимуться окремо і не заважатимуть один одному.

Файли 32-розрядних програм за замовчуванням встановлюються в:

  • C:\Program Files(x86)

32-розрядні системні файли встановлюються в:

  • C:\WINDOWS\SysWOW64

Для 64-розрядних програм, файли встановлюються в:

  • C:\Program Files
  • C:WINDOWSSYSTEM32

Механізм перенаправлення WOW64 гарантує, що запити від 32-розрядних додатків до каталогів "C:Program Files" і "C:WINDOWS\SYSTEM32" будуть перенаправлені на відповідні каталоги для 32-бітних версій.

Однак існує одна проблема з перенаправленням файлів. Користувачі та розробники повинні бути в курсі цієї особливості.

Багато 64-розрядних програм все ще використовують 32-бітовий режим і процедури. І не враховують це при створенні інсталятора. Для того, щоб програма була встановлена ​​правильно. тобто. в "C: Program Files", програма установки повинна зробити системний виклик до операційної системи, щоб система призупинила механізм перенаправлення файлів Wow64. А після встановлення зробити інший системний виклик, щоб знову увімкнути перенаправлення. Якщо виконувати установку без зупинки перенаправлення, програма буде встановлена ​​в "C:\Program Files (x86)". Класичним прикладомданої помилки є 64-розрядна версія FireFox 3.5 під кодовою назвою "Shiretoko", яка встановлюється в "C: Program Files (x86) Shiretoko". Звичайно, Firefox, як і раніше, буде нормально функціонувати. Єдине, що ви не зможете зробити, так це змінити значок програми .

Примітка: Можливо, зараз цю помилку в Shiretoko вже виправили Проте у ранніх версіях було саме так.

Перенаправлення реєстру

Ключі реєстру, специфічні для 32-розрядних додатків, будуть перенаправлені з гілки:

  • HKEY_LOCAL_MACHINE\Software
  • HKEY_LOCAL_MACHINE\Software\WOW6432Node

Так само іноді можна зустріти записи реєстру в іншій гілці (хоча це незвичайно):

  • HKEY_CURRENT_USER\Software\WOW6432Node

Такий підхід дозволяє 32- та 64-бітним додаткам нормально співіснувати, без проблем із перезаписом налаштувань один одного.

Дублювання реєстру

Деякі перенаправлені ключі та значення реєстру необхідно дублювати. Це означає, що якщо 32-розрядна програма вносить зміни в перенаправленому розділі реєстру, то ці зміни необхідно також застосовувати і для гілок 64-розрядних додатків. В даному випадку діє принцип "хто останній, той і правий". Наприклад, якщо ви встановите три додатки, що прив'язують себе до того самого розширення файлу, то асоціація з розширенням файлу повинні бути з останнім додатком.

  1. Встановіть 32-бітну програму, яка асоціює себе з розширенням XYZ
  2. Встановіть 64-розрядну версію програми, яка пов'язує себе з розширенням файлу XYZ
  3. Встановіть іншу 32-бітну програму, яка асоціює розширення XYZ із собою

В результаті цих дій, по подвійному клацанню на файлі з розширення XYZ у провіднику Windows має відкритися програма, яка була встановлена ​​на 3-му кроці. Адже саме воно останнім асоціювало себе з розширенням.

Все це відбувається прозоро для 32-бітових додатків у Wow64, яка самостійно перехоплює звернення та дублює необхідні параметри та ключі реєстру. Іншими словами, 32-розрядні програми можуть виконуватися стандартним чином, необхідні зміни за них внесе Wow64.

Існує низка обмежень підсистеми WOW64

Деякі, але не всі, 64-бітові функції доступні 32-розрядним програмам

Wow64 дозволяє 32-розрядним додаткам використовувати деякі функції та можливості 64-бітових систем. Наприклад, при правильному налаштуванні, такі програми зможуть використовувати до 4Гб оперативної пам'яті. Доступ до інших функцій обмежений через особливості пристрою 64-бітових систем. Наприклад, 64-бітна Windows підтримує 64-бітові логічні операції. Тим не менш, 32-бітові програми не матимуть доступу до них, вони зможуть використовувати лише 32-бітові логічні операції.

Примітка: Основною причиною обмежень служить різниця в поданні даних 32- та 64-бітних додатків. 32-розрядний додаток просто не розрахований на 64-розрядні типи даних.

Не можна змішувати між собою код (Code Injection) 32-бітних та 64-бітних додатків

У 64-бітній ОС Windows не можна запускати 32-бітний код у 64-розрядному процесі, як і не можна запускати 64-бітний код у 32-розрядному процесі. Програми, що використовують ін'єкції коду (Code Injection) для додавання функціональності до існуючих програм, як правило, будуть видавати помилки.

Цей факт пояснює, чому більшість 32-бітових розширень оболонки Windows не запускаються під 64-розрядною Windows. Більшість таких розширень використовують ін'єкцію коду (Code Injection) для вбудовування у провідник Windows

WOW64 не підтримує 16-розрядні інсталятори

WOW64 забезпечує підтримку 16-бітних інсталяторів Microsoft шляхом заміни інсталятора на сумісну 32-бітну версію. Проте ця підтримка не поширюється на інші продукти. Так що якщо вам потрібно використовувати стару програму, то, швидше за все, доведеться шукати емулятор або портативну версію.


Додаткові можливості для запуску 32-бітових програм у Windows 64

Windows Virtual PC

Windows Virtual PC - це безкоштовне програмне забезпечення, яке дозволяє запускати кілька операційних систем на одному комп'ютері. Virtual PC забезпечує спеціальне середовище виконання, яке підтримує застаріле обладнання та програмне забезпечення, яке не визначатиметься і не запускатиметься у Windows 7. Усі запущені операційні системи під Virtual PC виконуватимуться у віртуальній машині. Це означає, що запущені операційні системи не знатимуть про те, що вони запущені в іншій системі.

Системні вимоги та набір функціональності суттєво різняться між версіями Virtual PC та версіями Windows. Так що, перш ніж намагатися використовувати Virtual PC, необхідно перевірити, що програма підтримує як вашу операційну систему, так і ОС, які будуть на ній запущені. Наприклад, одна з останніх версій вже не підтримує версії Windows нижче Windows XP SP3.

Режим Windows XP (XPM)

Режим Windows XP це конкретна та урізана реалізація Windows Virtual PC, яка постачається з попередньо встановленою копією Windows XP Professional SP3. Цей режим доступний лише у версіях Enterprise, Ultimate та Professional Windows 7 64-біт.

Незважаючи на те, які можливості повинен був би представляти цей режим, багато хто, хто використовував XPM, настійно радить використовувати цей режим тільки як останній засіб. У порівнянні з іншими продуктами віртуалізації, продуктивність розчаровує, а стандартна конфігурація викликає ряд питань безпеки.

Примітка: До деяких більш давніх налаштувань режиму сумісності можна звернутися. Більш детальну інформацію можна знайти в огляді Як запустити старі програми на Windows 7 / Vista? (Див. Microsoft Application Compatibility Toolkit).

Мультизавантаження Windows

Ви можете інсталювати більше однієї версії Windows на одному комп'ютері за допомогою мультизавантажувача. Наприклад, встановити 32-розрядну та 64-розрядну версії Windows поруч один з одним. Кожна операційна система встановлюється на окремий розділ диска, а менеджер завантаження встановлюється на стандартному розділі. Менеджер завантаження дозволяє вибрати та запустити операційну систему, яку ви хочете використовувати зараз.

Хоча ви і не можете одночасно використовувати більше однієї операційної системи, ця функціональність є досить корисною. У порівнянні з віртуальними машинами, такий спосіб не має жодних проблем із сумісністю і такі системи набагато легше налаштовувати та обслуговувати. Крім того, встановивши 32-розрядну версію поруч із 64-бітною, ви збережете можливість запускати 16-бітові програми.

Підсумовуючи сказане про підтримку 32-біт у 64-розрядній Windows

Більшість 32-розрядних програм будуть цілком щасливо почуватися в Windows 64. Основними винятками будуть:

  1. 32-розрядні драйвери пристроїв
  2. Програми, які не можуть функціонувати без 32-розрядних драйверів пристроїв, які вони використовують. Яскравими прикладами є антивіруси та інші програми безпеки.
  3. Розширення, які використовують ін'єкцію коду (Code injection). Наприклад, оболонки для провідника Windows

Деякі програми можуть запускатися з обмеженнями. Це також стосується деінсталяторів, програм для очищення реєстру та програм для тюнінгу, оскільки вони мають доступ тільки до тієї частини реєстру, яку їм показує Wow64.

Якщо ви не можете запустити 32-бітну програму, то розгляньте варіант з віртуалізацією або мультизавантаженням декількох операційних систем.

Які програми швидше за 32-бітові або 64-бітові?

Це питання звучить досить часто. Але, немає ніякого загального правилачи коефіцієнта множення, оскільки це залежить від завдань і використовуваних функцій процесора.

Якщо порівнювати 32- і 64-розрядні програми у своїх рідних середовищах, то 32-бітний додаток, як правило, використовує менше пам'яті, ніж еквівалентний 64-розрядний додаток. Це тому, що 64-бітові версії використовують 64-бітові структури даних, які займають удвічі більше місця. Додатковий розмір безпосередньо впливає на час запуску та закриття програми, а також на інші види операцій, пов'язаних з доступом до дискових накопичувачів. Зазвичай це означає, що 32-розрядні програми будуть виконуватися швидше. Тим не менш, використання 64-бітними програмами особливостей 64-розрядного процесора потенційно дозволяє програмі виконуватися на 25% швидше, порівняно з 32-бітними програмами.

Крім того, необхідно пам'ятати, що запуск 32-бітної програми на 64-розрядній Windows означає запуск Wow64, тому аналіз продуктивності на 32-бітному процесорі можна відкласти убік. Запуск Wow64 означає не тільки витрати на перетворення викликів, а й облік механізмів перенаправлення та дублювання, яким потрібні не лише процесорний час, а й оперативна пам'ять. Тому, можливо, 32-розрядний додаток буде виконуватися швидше за 64-бітного, але він однозначно буде виконуватися повільніше, ніж при еквівалентному запуску на 32-бітному процесорі.

Рейтинг 5.00 (2 Голосів)



Почати освоєння 64-бітових систем слід із запитання «Чи потрібно нам перезбирати свій проект для 64-бітної системи?». На це запитання треба обов'язково відповісти, але не поспішаючи, подумавши. З одного боку, можна відстати від своїх конкурентів, вчасно не запропонувавши 64-бітні рішення. З іншого - можна даремно витратити час на 64-бітний додаток, який не дасть жодних конкурентних переваг.
Перерахуємо основні фактори, які допоможуть вам зробити вибір.

2.1. Тривалість життєвого циклу додатків

Не слід створювати 64-бітну версію програми з коротким життєвим циклом. Завдяки підсистемі WOW64 старі 32-бітові програми досить добре працюють на 64-бітних Windows системахі тому робити програму 64-бітної, яка через 2 роки перестане підтримуватися, сенсу немає. Більше того, практика показала, що перехід на 64-бітові версії Windows затягнувся і, можливо, більшість ваших користувачів у короткостроковій перспективі будуть використовувати лише 32-бітний варіант вашого програмного рішення.
Якщо планується тривалий розвиток та тривала підтримка програмного продукту, слід починати працювати над 64-бітним варіантом вашого рішення. Це можна робити неспішно, але врахуйте, що чим довше у вас не буде повноцінного 64-бітного варіанта, тим більше складнощів може виникати за допомогою такої програми, яка встановлюється на 64-бітові версії Windows.

2.2. Ресурсоємність програми

Перекомпіляція програми для 64-бітної системи дозволить їй використовувати величезні обсяги оперативної пам'яті, а також прискорить швидкість роботи на 5-15%. Прискорення на 5-10% відбудеться за рахунок використання архітектурних можливостей 64-бітного процесора, наприклад більшої кількостірегістрів. Ще 1%-5% приросту швидкості обумовлюється відсутністю прошарку WOW64, який транслює виклики API між 32-бітними додатками та 64-бітною операційною системою.
Якщо ваша програма не працює з більшими обсягами даних (більше 2GB) і швидкість її роботи не критична, то перехід на 64-бітну найближчим часом систему не настільки актуальний.
До речі, навіть прості 32-бітові програми можуть отримати перевагу від їх запуску в 64-бітовому середовищі. Ви, напевно, знаєте, що програма, зібрана з ключем /LARGEADDRESSAWARE:YES, може виділяти до 3-х гігабайт пам'яті, якщо 32-бітна операційна система Windows запущена з ключем /3gb. Ця ж 32-бітна програма, запущена на 64-бітній системі, може виділити майже 4 GB пам'яті (на практиці близько 3.5 GB).

2.3. Розробка бібліотек

Якщо ви розробляєте бібліотеки, компоненти або інші елементи, за допомогою яких сторонні розробники створюють своє програмне забезпечення, ви повинні проявити оперативність у створенні 64-бітного варіанта своєї продукції. Інакше ваші клієнти, зацікавлені у випуску 64-бітних версій, будуть змушені шукати альтернативні рішення. Наприклад, деякі розробники програмно-апаратного захисту відгукнулися з великою затримкою на появу 64-бітових програм, що змусило низку клієнтів шукати інші інструменти захисту своїх програм.
Додатковою перевагою від випуску 64-бітної версії бібліотеки є те, що ви можете її продавати як окремий продукт. Таким чином, ваші клієнти, які бажають створювати як 32-бітові, так і 64-бітові програми будуть змушені купувати 2 різні ліцензії. Наприклад, така політика використовується компанією Spatial Corporation для продажу бібліотеки Spatial ACIS.

2.4. Залежність вашого продукту від сторонніх бібліотек

Перш ніж планувати роботу над створенням 64-бітної версії вашого продукту, з'ясуйте, чи є 64-бітні варіанти бібліотек і компонентів, які в ньому використовуються. Також дізнайтеся, яка цінова політика щодо 64-бітного варіанта бібліотеки. Все це можна з'ясувати, відвідавши веб-сайт розробника бібліотеки. Якщо підтримка відсутня, заздалегідь пошукайте альтернативні рішення, що підтримують 64-бітові системи.

2.5. Наявність 16-бітових програм

Якщо у ваших рішеннях все ще присутні 16-бітові модулі, то час їх позбутися. Робота 16-розрядних програм у 64-розрядних версіях Windows не підтримується.
Тут слід пояснити один момент, пов'язаний із використанням 16-бітових інсталяторів. Вони досі використовуються для встановлення деяких 32-бітових програм. Створено спеціальний механізм, який на льоту підміняє низку найбільш популярних 16-бітних інсталяторів на нові версії. Це може викликати невірну думку, що 16-бітові програми, як і раніше, працюють у 64-бітовому середовищі. Пам'ятайте, що це не так.

2.6. Наявність коду на асемблері

Не забувайте, що використання великого обсягу коду на асемблері може істотно підвищити вартість створення 64-бітної версії програми.
Зваживши всі перелічені факти, всі за і проти, ухваліть рішення, чи варто вам переносити ваш проект на 64-бітові системи. І якщо це так, то давайте підемо далі.

3. Крок третій. Інструментарій

Якщо ви вирішили розробити 64-бітну версію вашого продукту і готові витратити на цей час, це ще не гарантує успіху. Справа в тому, що ви повинні мати весь необхідний інструментарій і тут можуть бути неприємні казуси.
Найпростішою, але й непереборною, може стати проблема відсутності 64-бітного компілятора. Стаття пишеться в 2009 році, але ще немає 64-бітного компілятора C++ Builder від Codegear . Його випуск очікується лише до кінця цього року. Неможливо обійти подібну проблему, якщо звичайно переписати весь проект, наприклад, з використанням Visual Studio. Але якщо з відсутністю 64-бітного компілятора все зрозуміло, інші аналогічні проблеми можуть виявитися більш потайливими і вилізти вже на етапі робіт з перенесення проекту на нову архітектуру. Тому хочеться порадити заздалегідь провести дослідження, чи існують усі необхідні компоненти, які будуть потрібні для реалізації 64-бітної версії вашого продукту. На вас можуть чекати неприємні сюрпризи.
Звичайно, перерахувати все, що може знадобитися для проекту, тут неможливо, але все-таки запропоную список, який допоможе вам соорентуватися і можна згадати про інші моменти, які необхідні для реалізації вашого 64-бітного проекту:

3.1. Наявність 64-бітного компілятора

Складно ще щось сказати про важливість наявності 64-бітного компілятора. Він просто має бути.
Якщо ви плануєте розробляти 64-бітові програми з використанням останньої версії(на момент написання статті) Visual Studio 2008, наступна таблиця N2 допоможе допомогти визначити, яка з редакцій Visual Studio вам необхідна.



Таблиця №2. Можливості різних редакцій Visual Studio 2008

3.2. Наявність 64-бітових комп'ютерів під керуванням 64-бітових операційних систем

Можна звичайно використовувати віртуальні машинидля запуску 64-бітових додатків на 32-бітовій техніці, але це вкрай незручно і не забезпечить необхідного рівня тестових випробувань. Бажано, щоб у машинах було встановлено щонайменше 4-8 гігабайт оперативної пам'яті.

3.3. Наявність 64-бітних варіантів усіх бібліотек

Якщо бібліотеки представлені у вихідних кодах, то має бути присутня 64-бітна конфігурація проекту. Самостійно займатися модернізацією бібліотеки для її збирання під 64-бітну систему може бути невдячним і складним заняттям, а результат може виявитися ненадійним і таким, що містить помилки. Також ви можете порушити ліцензійні угоди. Якщо ви використовуєте бібліотеки у вигляді бінарних модулів, ви також повинні дізнатися, чи існують 64-бітові модулі. Ви не зможете використовувати 32-бітові DLL всередині 64-бітного додатку. Можна створити спеціальну обв'язку через COM, але це буде окремим великим, складним завданням. Також врахуйте, що придбання 64-бітної версії бібліотеки може коштувати додаткові гроші.

3.4. Відсутність вбудованого коду на асемблері

Visual C++ не підтримує 64-бітний вбудований асемблер. Ви повинні використовувати або зовнішній 64-бітний асемблер (наприклад, MASM) або мати реалізацію тієї ж функціональності мовою Сі/Сі++.

3.5. Модернізація методології тестування

Істотна переробка методології тестування, модернізація юніт-тестів, використання нових інструментальних засобів. Докладніше про це буде сказано нижче, але не забувайте врахувати це на етапі оцінки тимчасових витрат на міграцію програми на нову систему.

3.6. Нові дані для тестування

Якщо ви розробляєте ресурсомісткі додатки, що споживають великий обсяг оперативної пам'яті, вам необхідно подбати про поповнення бази тестових вхідних даних. При навантажувальному тестуванні 64-бітних додатків бажано виходити за межі 4 гігабайт пам'яті, що споживається. Багато помилок можуть проявитися лише за таких умов.

3.7. Наявність 64-бітових систем захисту

Система захисту, що використовується, повинна підтримувати 64-бітові системи в повному необхідному вам обсязі. Наприклад, компанія Aladdin досить швидко випустила 64-бітові драйвери для підтримки апаратних ключів Hasp. Але дуже довго була відсутня система автоматичного захисту 64-бітних бінарних файлів (програма Hasp Envelop). Таким чином, механізм захисту доводилося реалізовувати самостійно всередині. програмного коду, що було додатковим складним завданням, що потребує кваліфікації та часу. Не забувайте про подібні моменти, пов'язані із забезпеченням захисту, системою оновлень тощо.

3.8. Інсталятор

Необхідна наявність нового інсталятора, здатного повноцінно встановлювати 64-бітові програми. Хочеться тут одразу застерегти про одну традиційну помилку. Це створення 64-бітних інсталяторів для встановлення 32/64-бітних програмних продуктів. Підготовляючи 64-бітну версію програми, розробники часто хочуть довести "64-бітність" в ньому до абсолюту. І створюють 64-бітний інсталятор, забуваючи про те, що у користувачів 32-бітної операційної системи такий інсталяційний пакет просто не запуститься. Звернемо увагу, що не запуститься не 32-бітний додаток включений до дистрибутиву поряд з 64-бітним, а саме сам установник. Адже якщо дистрибутив є 64-бітним додатком, то на 32-бітній операційній системі він, звичайно ж, не запуститься. Найприкріше в цьому те, що користувач ніяк не зможе здогадатися, що відбувається. Він просто побачить інсталяційний пакет, який неможливо запустити.

4. Крок четвертий. Налаштування проекту у Visual Studio 2005/2008

Створення 64-бітної конфігурації проекту Visual Studio 2005/2008 виглядає досить просто. Складнощі будуть підстерігати вас на етапі складання нової конфігурації та пошуку в ній помилок. Для створення 64-бітної конфігурації достатньо виконати наступні 4 кроки:
Запускаємо менеджер конфігурацій, як показано на малюнку N1:



Рисунок 1. Запуск менеджера конфігурацій

У менеджері конфігурацій вибираємо підтримку новій платформі (рисунок N2):



Малюнок 2. Створення нової конфігурації

Вибираємо 64-бітну платформу (x64), а як основу вибираємо налаштування від 32-бітної версії (рисунок N3). Ті параметри, які впливають на режим збирання середовище Visual Studio скоригує сама.



Рисунок 3. Вибираємо x64 як платформу і беремо за основу конфігурацію Win32

Додавання нової конфігурації завершено, і ми можемо вибрати 64-бітний варіант конфігурації та приступити до компіляції 64-бітного додатка. Вибір 64-бітної конфігурації для складання показаний малюнку N4.



Рисунок 4. Тепер доступна 32-бітна та 64-бітова конфігурація

Якщо вам пощастить, додатково займатися налаштуванням 64-бітного проекту необхідності не буде. Але це сильно залежить від проекту, його складності та кількості бібліотек, що використовуються. Єдине, що варто одразу змінити, це розмір стеку. Якщо у вашому проекті використовується стек розміром за замовчуванням, тобто в 1 мегабайт, тобто сенс задати його розміром в 2 мегабайти для 64-бітної версії. Це не обов'язково, але краще заздалегідь підстрахуватися. Якщо у вас використовується розмір стека, відмінний від розміру за замовчуванням, це означає зробити його для 64-бітної версії в 2 рази більше. Для цього в налаштуваннях проекту знайдіть та змініть параметри Stack Reserve Size та Stack Commit Size.

5. Крок п'ятий. Компіляція програми

Тут було б добре розповісти про типові проблеми, що виникають на етапі компіляції 64-бітної конфігурації. Розглянути, які проблеми виникають із сторонніми бібліотеками, розповісти, що компілятор у коді, пов'язаному з функціями WInAPI, більше не допустить приміщення покажчика в тип LONG і вам буде необхідно модернізувати свій код і використовувати тип LONG_PTG. І багато багато іншого. На жаль цього так багато і помилки такі різноманітні, що немає можливості викласти це в рамках однієї статті і навіть, мабуть, книги. Вам доведеться самим переглянути всі помилки, які видасть компілятор та нові попередження, яких раніше не було і в кожному окремому випадку розібратися, як модернізувати код.
Частково полегшити життя може колекція посилань на ресурси, присвячені розробці 64-бітних програм: http://www.viva64.com/links/64-bit-development/ . Колекція постійно поповнюється і автор буде вдячний читачам, якщо вони надішлють йому посилання на ресурси, які, на їхню думку, заслуговують на увагу.
Зупинимося тут лише на типах, які можуть становити інтерес для розробників під час міграції додатків. Ці типи представлені Таблиці N3. Більшість помилок при компіляції пов'язані з використання саме цих типів.
Тип Розмірність типу на платформі x32 / x64 Примітка
int 32 / 32 Основний тип. На 64-бітових системах залишився 32-бітовим.
long 32 / 32 Основний тип. На 64-розрядних Windows системах залишився 32-розрядним. Врахуйте, що у 64-бітних Linux системахцей тип було розширено до 64-біт. Не забувайте про це, якщо розробляєте код, який повинен працювати компілюватися для Windows та Linux систем.
size_t 32 / 64 Базовий беззнаковий тип. Розмір типу вибирається так, щоб у нього можна було записати максимальний розміртеоретично можливий масив. Тип size_t може бути безпечно поміщений покажчик (виняток становлять покажчики на функції класів, але це особливий випадок).
ptrdiff_t 32 / 64 Аналогічний типу size_t але є знаковим. Результат виразу, де один покажчик віднімається з іншого (ptr1-ptr2), якраз матиме тип ptrdiff_t.
Покажчик 32 / 64 Розмір покажчика залежить від розрядності платформи. Будьте обережні під час приведення укзателів до інших типів.
__int64 64 / 64 Знаковий 64-бітний тип.
DWORD 32 / 32 32-бітний беззнаковий тип. Оголошено WinDef.h як:typedef unsigned long DWORD;
DWORDLONG 64 / 64 64-бітний беззнаковий тип. Оголошено у WinNT.h як:typedef ULONGLONG DWORDLONG;
DWORD_PTR 32 / 64 Беззнаковий тип, який можна поміщати покажчик. Оголошено BaseTsd.h як:typedef ULONG_PTR DWORD_PTR;
DWORD32 32 / 32 32-бітний беззнаковий тип. Оголошено BaseTsd.h як:typedef unsigned int DWORD32;
DWORD64 64 / 64 64-бітний беззнаковий тип. Оголошено BaseTsd.h як:typedef unsigned __int64 DWORD64;
HALF_PTR 16 / 32 Половина вказівника. Оголошено Basetsd.h як:#ifdef _WIN64 typedef int HALF_PTR;#else typedef short HALF_PTR;#endif
INT_PTR 32 / 64 Знаковий тип, який можна поміщати покажчик. Оголошено BaseTsd.h як:#if defined(_WIN64) typedef __int64 INT_PTR; #else typedef int INT_PTR;#endif
LONG 32 / 32 Знаковий тип, що залишився 32-бітовим. Тому в багатьох випадках слід використовувати LONG_PTR. Оголошено WinNT.h як:typedef long LONG;
LONG_PTR 32 / 64 Знаковий тип, який можна поміщати покажчик. Оголошено BaseTsd.h як:#if defined(_WIN64) typedef __int64 LONG_PTR; #else typedef long LONG_PTR;#endif
LPARAM 32 / 64 Параметр для надсилання повідомлень. Оголошено у WinNT.h як:typedef LONG_PTR LPARAM;
SIZE_T 32 / 64 Аналог типу size_t. Оголошено BaseTsd.h як:typedef ULONG_PTR SIZE_T;
SSIZE_T 32 / 64 Аналог типу ptrdiff_t. Оголошено BaseTsd.h як:typedef LONG_PTR SSIZE_T;
ULONG_PTR 32 / 64 Беззнаковий тип, який можна поміщати покажчик. Оголошено BaseTsd.h як:#if defined(_WIN64) typedef unsigned __int64 ULONG_PTR;#else typedef unsigned long ULONG_PTR;#endif
WORD 16 / 16 Беззнаковий 16-бітний тип. Оголошено у WinDef.h як:typedef unsigned short WORD;
WPARAM 32 / 64 Параметр для надсилання повідомлень. Оголошено WinDef.h як:typedef UINT_PTR WPARAM;

Таблиця №3. Типи представляють інтерес при перенесенні 32-бітових програм на 64-біті Windows системи.

6. Діагностика прихованих помилок

Якщо ви думаєте, що після виправлення всіх помилок компіляції буде отримано довгоочікувану 64-бітну програму, то доведеться вас розчарувати. Найскладніше попереду. На етапі компіляції вами будуть виправлені явні помилки, які зміг виявити компілятор, які в основному пов'язані з неможливістю неявного приведення типів. Але це верхівка айсбергу. Основна частина помилок прихована. Ці помилки з погляду абстрактної мови Сі++ виглядають безпечно чи замасковані явними приведеннями типів. Таких помилок у кілька разів більше, ніж кількість помилок, виявлених на етапі компіляції.
На ключ /Wp64 надії не слід покладати. Цей ключ часто подається як чудовий засіб пошуку 64-бітових помилок. Насправді ключ /Wp64 лише дає можливість при компіляції 32-бітного коду отримати деякі попередження, що в 64-бітному режимі певні ділянки коду будуть некоректні. При компіляції 64-бітного коду ці попередження будуть видані компілятором у будь-якому випадку. І тому при компіляції 64-бітної програми ключ / Wp64 ігнорується. І тим більше цей ключ не допоможе в пошуку прихованих помилок.
Розглянемо кілька прикладів прихованих помилок.

6.1. Явне приведення типів

Найпростіший, але зовсім не найлегший для виявлення, клас помилок пов'язаний з явним приведенням типів, при яких відбувається обрізання. значних біт.
Найпоширенішим прикладом є приведення покажчиків до 32-бітових типів при передачі їх у функції, такі як SendMessage:
MyObj* pObj = ... ::SendMessage(hwnd, msg, (WORD)x, (DWORD)pObj);

Тут явне приведення типу використовується для перетворення покажчика на числовий тип. Для 32-бітної архітектури наведений приклад коректний, оскільки останній параметр функції SendMessage має тип LPARAM, який на 32-бітовій архітектурі збігається з DWORD. Для 64-бітної архітектури використання DWORD є помилковим і має бути замінено на LPARAM. Тип LPARAM має залежно від архітектури розмір 32 чи 64 біта.
Це простий випадок, але часто приведення типу виглядає більш вишукано і виявити його, використовуючи попередження компілятора або пошуком тексту програми неможливо. Явні приведення типів пригнічують діагностику компілятора, оскільки вони і призначені, щоб сказати компілятору що приведення типів коректно і програміст взяв він відповідальність за безпеку коду. Явний пошук також не допоможе. Типи можуть бути не стандартні імена (задані програмістом через typedef), а способів здійснити явне приведення типів теж не мало. Для надійної діагностики подібних помилок необхідно використовувати лише спеціальний інструментарій, такий як аналізатори Viva64 або PC-Lint.

6.2. Неявне наведення типів

Наступний приклад пов'язаний з неявним приведенням типу , у якому також відбувається втрата значних біт. Код функції fread здійснює читання файлу, але некоректний при спробі читання більше 2 гігабайт даних на 64-бітній системі.
size_t __fread(void * __restrict buf, size_t size, size_t count, FILE * __restrict fp); size_t fread(void * __restrict buf, size_t size, size_t count, FILE * __restrict fp) ( int ret; FLOCKFILE(fp); ret = __fread(buf, size, count, fp); FUNLOCKFILE(fp); return (ret) ; )

Функція __fread повертає тип size_t, але зберігання кількості прочитаних байт використовується тип int. В результаті при великих обсягах даних функція може повернути не ту кількість байт, яке насправді буде прочитано.
Ви можете сказати, що це безграмотний код початківців, що про таке наведення типу повідомить компілятор і взагалі такий код легко знайти і поправити. Це теоретично. А практично в реального життяз великими проектамивсе може бути інакше. Цей приклад взятий із вихідного коду FreeBSD. Помилка була виправлена ​​лише у грудні 2008 року! Це при тому, що перша (експериментальна) 64-бітна версія FreeBSD вийшла ще у червні 2003 року.
Ось вихідний код до виправлення:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.14
А ось виправлений варіант (грудень 2008) року:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.15

6.3. Робота з бітами, зрушення

Легко зробити помилку в коді працюючому з окремими бітами. Наступний тип помилки пов'язані з операціями зсуву. Розглянемо приклад:
ptrdiff_t SetBitN(ptrdiff_t value, unsigned bitNum) ( ptrdiff_t mask = 1<< bitNum; return value | mask; }

Наведений код працездатний на 32-бітовій архітектурі та дозволяє виставляти біт із номерами від 0 до 31 в одиницю. Після перенесення програми на 64-бітну платформу виникне необхідність виставляти біти від 0 до 63. Але код ніколи не виставить біти, з номерами 32-63. Зверніть увагу, що «1» має тип int і при зрушенні на 32 позиції відбудеться переповнення, як показано на малюнку 5. Отримаємо в результаті 0 (рисунок 5-B) або 1 (рисунок 5-C) залежить від реалізації компілятора.



Малюнок 5. A - Коректна установка 31-го біта в 32-бітному коді; B,C - Помилка установки 32-го біта на 64-бітній системі (два варіанти поведінки)

Для виправлення коду необхідно зробити константу «1» того ж типу, що змінна mask:

ptrdiff_t mask = ptrdiff_t(1)<< bitNum;

Зауважимо також, що невиправлений код спричинить ще одну цікаву помилку. При виставленні 31 біта на 64-бітовій системі результатом роботи функції буде значення 0xffffffff80000000 (див. рисунок 6). Результатом виразу 1<< 31 является отрицательное число -2147483648. Это число представляется в 64-битной целой переменной как 0xffffffff80000000.



Малюнок 6. Помилка установки тридцять першого біта на 64-бітній системі

6.4. Магічні числа

Багато неприємностей можуть завдати магічні константи, тобто числа, за допомогою яких задається розмір того чи іншого типу. Правильним рішенням є використання для таких цілей операторів sizeof(), але у великій програмі цілком може загубитися старий шматочок коду, де твердо були впевнені, що розмір покажчика був 4 байти, а тип size_t завжди 32 біта. Зазвичай такі помилки виглядають так:
size_t ArraySize = N * 4; size_t *Array = (size_t *)malloc(ArraySize);

Основними числами, яких слід поставитися з обережністю під час переходу на 64-битную платформу наведені у таблиці N4.



Таблиця №4. Основні магічні значення, небезпечні при перенесенні додатків з 32-бітної на 64-бітну платформу

6.5. Помилки використання 32-бітових змінних як індекси

У програмах, що обробляють великі обсяги даних, можуть зустрітися помилки пов'язані з індексацією великих масивів або виникнути вічні цикли. Наступний приклад містить відразу дві помилки:
const size_t size = ...; char *array = ...; char * end = array + size; for (unsigned i = 0; i != size; ++i) (const int one = 1; end[-i - one] = 0; )

Перша помилка полягає в тому, що якщо розмір даних перевищить 4 гігабайти (0xFFFFFFFF), то можливе виникнення вічного циклу, оскільки змінна "i" має тип "unsigned" і ніколи не досягне значення 0xFFFFFFFF. Я спеціально пишу, що виникнення можливе, але не обов'язково воно станеться. Це залежить від того, який код збудує компілятор. Наприклад, у налагоджувальному (debug) режимі вічний цикл буде присутній, а в release-коді зациклювання зникне, так компілятор ухвалить рішення оптимізувати код, використовуючи для лічильника 64-бітний регістр і цикл буде коректним. Все це додає плутанини, і код, який працював учора, несподівано може перестати працювати наступного дня.
Друга помилка пов'язана з проходом масивом від кінця до початку для чого використовуються негативні значення індексів. Наведений код працездатний у 32-бітному режимі, але при його запуску на 64-бітній машині на першій же ітерації циклу відбудеться доступ за межі масиву і програма аварійно завершиться. Розглянемо причину такої поведінки.

Згідно з правилом мови Сі++ на 32-бітній системі вираз "-i - one" обчислюватиметься наступним чином (на першому кроці i = 0):

  1. Вираз "-i" має тип unsigned і має значення 0x00000000u.
  2. Змінна "one" буде розширена від типу "int" до типу unsigned і дорівнюватиме 0x00000001u. Примітка: Тип int розширюється (згідно зі стандартом мови Сі++) до типу "unsigned", якщо він бере участь в операції, де другий аргумент має тип unsigned.
  3. Відбувайся операція віднімання, в якому беруть участь два значення типу unsigned і результат виконання операції дорівнює 0x00000000u - 0x00000001u = 0xFFFFFFFFu. Зауважте, що результат має беззнаковий тип.
  4. На 32-бітовій системі звернення до масиву за індексом 0xFFFFFFFFu еквівалентне використанню індексу -1. Тобто end є аналогом end[-1]. В результаті відбувається коректне оброблення елемента масиву.
У 64-бітній системі в останньому пункті картина буде іншою. Відбудеться розширення типу unsigned до знакового ptrdiff_t і індекс масиву дорівнюватиме 0x00000000FFFFFFFFi64. В результаті відбудеться вихід за межі масиву.
Для виправлення коду необхідно використовувати такі типи, як ptrdiff_t та size_t.

6.6. Помилки, пов'язані зі зміною типів використовуваних функцій

Бувають помилки, в яких, загалом, ніхто не винен, але вони від цього не перестають бути помилками. Уявіть, що давно в далекій галактиці (в Visual Studio 6.0) був розроблений проект, в якому присутній клас CSampleApp, що є спадкоємцем від CWinApp. У базовому класі є віртуальна функція WinHelp. Спадкоємець перекриває цю функцію та виконує необхідні дії. Візуально це представлено малюнку 7.



Рисунок 7. Працездатний коректний код, створений у Visual Studio 6.0

Потім проект переноситься на Visual Studio 2005, де прототип функції WinHelp змінився, але цього ніхто не помічає, тому що в 32-бітному режимі типи DWORD і DWORD_PTR збігаються і програма продовжує працювати коректно (рисунок 8).



Малюнок 8. Не коректний, але працездатний 32-бітний код

Помилка чекає, щоб проявити себе у 64-бітній системі, де розмір типів DWORD та DWORD_PTR різний (рисунок 9). Виходить, що в 64-бітному режимі класи містять дві різні функції WinHelp, що природно некоректно. Зверніть увагу, що подібні пастки можуть ховатися не тільки в MFC, де частина функцій змінили типи своїх аргументів, але і в коді ваших програм і сторонніх бібліотек.



Малюнок 9. Помилка виявляє себе в 64-бітному коді

6.7. Діагностика прихованих помилок

Приклади подібних 64-бітових помилок можна наводити та наводити. Тим, хто зацікавився подібними помилками і хоче подібніше дізнатися про них буде цікава стаття «20 пасток перенесення Сі++ - коду на 64-бітну платформу».
Як бачите, етап пошуку прихованих помилок є нетривіальним завданням, тим більше що багато з них будуть проявлятися нерегулярно або тільки на великих вхідних обсягах даних. Для діагностики подібних помилок добре підходять статичні аналізатори коду, оскільки вони можуть перевіряти весь код програми, незалежно від вхідних даних і частоти виконання його ділянок в реальних умовах. Використовувати статичний аналіз є сенс як на етапі перенесення додатка на 64-бітові платформи, щоб знайти більшість помилок на початковому етапі, так і в подальшій розробці 64-бітових рішень. Статичний аналіз попередить і навчить програміста краще розуміти особливості помилок пов'язаних із 64-бітною архітектурою та писати більш ефективний код. Автор статті є розробником одного з таких спеціалізованих аналізаторів коду, що має назву Viva64. Більш детально познайомитися з інструментом та завантажити демонстраційну версію можна з сайту компанії ТОВ «Системи програмної верифікації».
Як справедливість слід сказати, що у таких аналізаторах коду як Gimpel PC-Lint і Parasoft C++Test є набори правил для діагностики 64-бітних помилок. Але, по-перше, це аналізатори загального призначення та правила діагностики 64-бітних помилок у них представлені слабо. По-друге, вони більше орієнтовані на модель даних LP64, що використовується в сімействі операційних систем Linux, що знижує їх користь для Windows програм, де використовується модель даних LLP64.

7. Крок сьомий. Модернізація процесу тестування

Описаний у попередньому розділі крок пошуку помилок у програмному коді необхідний, але недостатній крок. Жоден метод, у тому числі статичного аналізу коду, не дає повної гарантії виявлення всіх помилок і найкращий результат може бути досягнутий лише при комбінації різних методик.
Якщо ваша 64-бітна програма обробляє більший обсяг даних, ніж 32-бітна версія, то необхідно розширити тести, щоб включити в них обробку даних об'ємом більше 4 гігабайт. Ця та межа, за якою починають проявляти себе багато 64-бітових помилок. Часу такі тести можуть займати набагато більше і до цього треба бути заздалегідь готовим. Зазвичай тести пишуть так, щоб обробляти у кожному тесті невелику кількість елементів і тим самим мати можливість проходити всі внутрішні юніт-тести, наприклад? за кілька хвилин, а автоматичні тести (наприклад, за допомогою AutomatedQA TestComplete) за кілька годин. Функція сортування на 32-бітній системі, якщо вона сортує 100 елементів, майже з повною гарантією буде коректна поводитися на 100000 елементах. Але та сама функція на 64-бітній системі може підвести при спробі обробити 5 мільярдів елементів. Швидкість виконання юніт-тесту може знизитися в мільйони разів. Не забудьте закласти вартість адаптації тестів під час освоєння 64-бітових систем. Одним із рішень є поділ юніт-тестів на швидкі (працюючі з малим об'ємом пам'яті) і повільні, що обробляють гігабайти та запускаються, наприклад, уночі. Автоматизоване тестування ресурсомістких 64-бітових програм можна побудувати на основі розподілених обчислень.

Мітки:

Додати теги
Поділіться з друзями або збережіть для себе:

Завантаження...