Давним-давно, Windows була 16-ти розрядної. Кожне повідомлення могло нести з собою дві частини даних, звані WPARAM і LPARAM.
Перший параметр в 16-ти розрядної Windows був 16-ти бітовим значенням ( "словом", "word"), тому він називався W. Другий був 32-х бітовим ( "довгим", "long"), тому він називався L.
Параметр W використовувався для передачі чисел і дескрипторів, а параметр L - для передачі покажчиків.
Коли Windows стала 32-х бітної, параметр WPARAM підріс до 32-х бітного значення. Тому, хоча "W" і означає "word" ( "слово"), але тепер уже це більше не слово (а в 64-х бітних Windows обидва параметри взагалі стали 64-х бітними!).
Це корисно, щоб зрозуміти походження цього терміна. Якщо ви подивіться на дизайн віконних повідомлень, то ви побачите наступне: якщо повідомлення приймає покажчик, то цей покажчик, як правило, передається в LPARAM. А якщо повідомлення приймає описатель або просто число, то воно передається в WPARAM. Якщо ж повідомлення приймає обидва параметри, то ціле йде в WPARAM, а покажчик - в LPARAM.
Розуміння цього факту дозволить вам легше запам'ятовувати параметри для віконних повідомлень. І навпаки, якщо правило порушено повідомленням, то ваш мозок тут же зреагує: "немає, тут щось не так".
Хм, залишився неосвітленим момент)
Скажімо, в зв'язці Delphi XE (x32) і Win 7 (x64) прототипи функцій повинні все одно мати параметри wParam / lParam розрядності 32. Зазвичай прототипи рекомендується визначати як
Proc (.; WParam, lParam: LongInt).
можливо, більш завбачливим було б писати
Proc (.; WParam: WPARAM; lParam: LPARAM).
як страховку на перехід до 64bit компілятору. Начебто LongInt і повинен відповідати розрядності компілятора, але.
Олександр, я прав?
Ну, очевидно, що Windows.pas буде виправлений в x64. Тому що, дійсно, зараз оголошено як LongInt, але в дійсності там повинен стояти тип плаваючою розмірності - WPARAM і LPARAM.
Але це в Delphi. А, наприклад, в джедаевскіх заголовочніках всі типи вже зараз вказані точно, як є, один-до-одного.
Виходить, що зараз Win x64 передає для нас все-таки 32bit параметри (замість рідних для системи 64bit) з допомогою деяких методів віртуалізації?
Ми про які зараз додатках говоримо: 32 або 64 бітних?
64 бітові додатки, зрозуміло, використовують 8-ми байтниє аргументи. Будь-який додаток має бути перекомпіліровать, щоб стати 64 розрядним. Ось в цей момент (момент пересборки) 4-х байтниє параметри в ньому змінюються на 8 байтниє.
32 бітові додатки, зрозуміло, використовують 4-х байтниє аргументи. Як вони можуть використовувати 8 байтниє, якщо вони були скомпільовані з 4 байтними? Від того, що ви запускаєте 32 байтное додаток в 64 Батна середовищі, воно чарівним чином не пересобран (перекомпіліровать) як 64 розрядне і використовувати 8 байтниє аргументи. Це треба розуміти. Воно залишиться таким же, яким і було (ми ж про Native говоримо, а не про .NET).
Адже і покажчики для 32 разрябного додатки будуть 4 байтовими навіть на 64 розрядної системі.
У 64 розрядної середовищі все 32 бітові додатки запускаються в режимі емуляції через механізм WOW64 (Windows-on-Windows) - приблизно так само як в 95-му році всі 16 бітові додатки запускалися в режимі емуляції WOW32 на 32 розрядної системі.