Нюансы в программном коде Win32 API

Здравствуйте, господа профи!
Именно к Вам есть вопросы связанные в программированием в C++ для Win32.
Программированием занимаюсь давно, в основном на Visual Basic и Visual Foxpro. С Visual C++ сначала не подружился, теперь решил восполнить этот пробел. Дело в том, что я занимаюсь еще и 3D-графикой и решил заняться программированием применительно к ней. Для работы выбрал MS VS 2005. Не спрашивайте почему. Так вот знакомство с C++ на уровне простых консольных программ прошло более-менее нормально, но когда добрался до Win32 API начались проблемы, в частности с отличием типов данных в старых версиях и с unicode.
Объясните пожалуйста следующие моменты:
Насколько необходимо использовать ATOM? Я понимаю, что он проверяет не создавалась ли копия приложения, но в более ранних версиях обходились без него, мастер проекта генерит эти строки, а в новой литературе в примерах ATOM часто не используют. Почему? Пишут "по-старинке" или ATOM не обязателен?
Часто возникают проблемы (особенно со старыми примерами программ написанных даже еще по MS VS 6) с использованием символьных или строковых переменных, так называемые "широкие" символы. Зачастую решается добавлением ключа L перед строкой, но в некоторых местах программы это не помогает, приходится методом тыка подбирать или unicode отключать чтобы заработало.
Еще непонятен момент с возвратом значений из процедуры WinMain:
return msg.wParam; - компилятор выдает предупреждение о несоответствии типов данных и возможной потере данных;
Мастер создания проекта генерит:
return (int) msg.wParam; - ну здесь вроде все ясно с приведением типов, но почему в старой литературе этого нет? В ранних версиях компиляторам все равно было какое значение возвращается????
В более новой литературе приводится такое:
return static_cast<int>(msg.wParam); - а вот тут непонятно зачем добавлен static_cast???? Для чего он сам я понимаю, но почему в ранних источниках литературы такого в примерах не наблюдается?
По строковым переменным:
в старых версиях - char szClassName[] = "MyClass";
в новых - static LPCTSTR szAppName = L"MyClass";
или еще такое - wchar_t или TCHAR szWindowClass
Так что из этого "разнообразия" более правильное? Борьба с такими "мелочами" занимает время и отвлекает от процесса изучения. В целом поправки в программах небольшие и сами программы все-таки начинают работать, но на поиск и борьбу с такими нюансами уходит время.
Уважаемые профи, можете ли Вы дать рекомендации относительно того на что следует обращать внимание при использовании ранних кодов программ? Какие изменения нужно внести в используемые типы данных? Потому, что иной раз приходится в настройках проекта отключать опцию использования unicode, но ведь он не красоты ради придуман и игнорировать его все равно нельзя.
Как следует подправить старый код, чтобы он нормально заработал в новых версиях?
Я не прошу по-принципу "сделайте за меня", больше чем уверен, что вы тоже сталкивались с подобным и исходя из своего опыта можете дать дельный совет.
Спасибо.

0

Отвечу на часть вопросов.
Помнится самому поначалу было тяжело привыкнуть, когда переходил с ANSI на UNICODE. А потом ничего, втянулся. По возможности стоит использовать функции модуля tchar.h - это позволит компилировать приложения как в ANSI, так и в UNICODE. Т.е. вы можете написать TCHAR szClassName[] = _T("MyClass"); и включать/отключать UNICODE - проект все равно скомпилируется и не придется ничего править. Эту же строку можно записать и так TCHAR* szClassName = _T("MyClass"), и так LPTSTR szClassName = _T("MyClass"). Если на третье (в данном случае) месте также присутствует символ "С" - значит стока является константой. Более подробно и понятно можно почитать у Румянцева в книге "Азбука программирования". Очень доступно описал все.
Далее. АТОМ, я так понимаю, используется в качестве результата работы функции по регистрации класса основного окна. Ну и шут с ним! Я никогда его не проверяю - процесс регистрации класса практически никогда не завершается с ошибкой. Главное, заполнить минимум необходимых полей структуры.
С приведением типа результата WinMain тоже все просто. Функция объявляется как int, а результат возвращается как dword. В принципе, транслятору все равно - все числовые типы в процессе предварительной обработки исходников приводятся к типу int (кроме, разумеется чисел с плавающей запятой), а если памяти не хватает - к unsigned int. А вы пытаетесь вернуть 32-битное значение с диапазоном 0...4294967295 из функции, которая возвращает значение в диапазоне –2147483648...2147483647. Чувствуете разницу? Поэтому компилятор и ругается...

0

Большое спасибо, GrayWolf. Румянцева я читал, но другие книги "Азбука программирования" у меня тоже есть, но я увидел что речь там идет еще о Windows 95 и NT и не стал читать посчитав что уже устарело. Оказывается зря, даже бегло просматривая материал нахожу ответы на многие вопросы.
Еще раз спасибо.

0