Помимо исправления ошибок, в SP4 включены все предыдущие Service Pack'и, плюс новые версии таких компонентов, как:
• Microsoft Data Access Objects
• Microsoft HTML Help
• Microsoft Data Access Components (MDAC)
• Microsoft Scripting
• Microsoft OLE Automation
Также внесены исправления, необходимые для новых версий Office, SQL Server и Windows, включая Internet Explorer.
К сожалению, SP4 не включает самые последние заголовки и библиотеки для Internet Explorer5 или Windows 2000. Их нужно загружать отдельно в виде SDK.
Visual Studio Service Pack 4 занимает около 130Мб и доступен для свободного скачивания на сайте Microsoft по адресу http://msdn.microsoft.com/vstudio/sp/vs6sp4 (13 файлов, приблизительно по 10 Мб каждый).
Имеется возможность обновить только некоторые продукты, например Visual Basic. Для Visual C++, однако, придется скачивать полную версию. Или подождать, пока она появится на пиратских CD.
ОБРАТНАЯ СВЯЗЬ Из входящей почты
Публикация "WinAPI: Не запутайтесь в типах", вышедшая в предыдущем выпуске (и которая, кстати, будет продолжена в следующем) вызвала некоторый резонанс из-за допущенных там двух неточностей.
Здравствуйте, Алекс!
Встретил в Вашей рассылке "Программирование на Visual C++" за No.5 следующее утверждение:
"Кстати, имейте в виду, что описатель PASCAL и pascal – это то же самое, что и WINAPI. Но этот описатель является устаревшим, оставлен лишь для совместимости, и Microsoft рекомендует повсеместно использовать вместо него WINAPI."
Это распространенное мнение, которое вызвано переходом Microsoft с pascal на stdcall при переходе с Win16 на Win32. При этом Microsoft в MSDN утверждает, что: "Use WINAPI where you previously used PASCAL or far pascal." Но это означает всего лишь то, что стандартный способ вызова API функций изменился, а не то, что pascal эквивалентен stdcall. Проиллюстрируем это первоисточниками.
MSDN:
"The stdcall calling convention is used to call Win32 API functions. Argument-passing order Right to left. Argument-passing convention By value, unless a pointer or reference type is passed. Stack-maintenance responsibility Called function pops its own arguments from the stack. "
Borland C++ Builder Help:
"In addition, pascal declares Pascal-style parameter-passing conventions when applied to a function header (parameters pushed left to right; the called function cleans up the stack)."
Справка от Борландовского продукта в последнем случае выбрана потому, что MSDN вообще умалчивает о том, кто такой этот pascal, ограничиваясь тем, что он is now obsolete. Из вышеприведенных выдержек мы можем видеть, что stdcall отличается от pascal порядком передачи параметров. И просто так подменять один способ другим нельзя. Это легко продемонстрировать, попытавшись вызвать функцию с модификатором pascal из Visual Basic. Access Violation Вам гарантирован.
Sergey Shapovalov Software Security Belarus
Mea culpa. Действительно, иногда не вредно вспоминать, что кроме MSDN существует кое-что еще. Спасибо, Сергей!
Привет
"Использование соглашения сdecl вместо stdcall иногда оправданно, но приводит к увеличению размера>исполняемого модуля из-за того, что имя функции декорируется в этих соглашениях по-разному."
Не понял я этой фразы… cdecl делает больше код потому что надо стек чистить каждый раз после вызова рутины, а не изза decoration. Names decoration влияет только на представление имён до линкера, в выходной код они не включаются.
Причём, cdecl – стандартный тип вызова для C/C++ изза возможности использования varargs, в то время как в stdcall вызове такое невозможно. Как правило, stdcall юзают в dll (в Win32API в том числе) и для присобачивания чужих lib, собранных с использованием этого типа вызова.
Ivan Nevraev
В самом деле, декорирование имени функции тут не причем. Благодарю Ивана за помощь. В дальнейшем буду стараться публиковать только перепроверенные данные.
А также напоминаю, что в следующем выпуске вас ожидает вторая часть этой публикации.
[…] Чтобы рассылка действительно не превращалась в дискуссионную группу, можно дать еще пару ссылочек. Вы уже упомянули news-группы. Можно посоветовать также еще один, правда англоязычный ресурс: http://codeguru.developer.com. Это один из (если не самый) крупнейших сайтов для разработчиков на C++ и большей своей частью на Visual C++.
Также там есть discussion board: http://codeguru.developer.com/bbs/wt/wwwthreads.pl, где можно задать любой интересующий вопрос (естественно на английском языке). Обычно ответ приходит довольно быстро. Причем это либо исходный код, либо ссылка на что-либо подобное. Короче очень рекомендую.
Andrew, Gromyko ([email protected])
Андрей, кстати, уже не в первый раз пишет. Ссылки хорошие – сам на CodeGuru захожу очень часто. Так что уверен, многим эта информация придется кстати.
Да, если вы знаете какие-нибудь стоящие внимания ресурсы по VC – присылайте ссылочки!
Большое спасибо за рассылку! Большой ее положительной спирали! ;) (Bill Gates "The Road Ahead") [ Может, "ей"?… – AJ]
Как насчет новости от Microsoft? Я имею в виду http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp.
C# (pronounced "C sharp").
В связи с этим:
а) не переименовать ли рассылку сразу в VisualC# ? :)
б) не объявить ли конкурс на лучшее объяснение значка # в новом названии; какова связь # со словом sharp?
Маленькое пожелание напоследок – не забывать, что "VisualC++" != "MFC"; "VisualC++"> "MFC";
Надеюсь еще не раз побеспокоить вас своими письмами.
С уважением,
Александр Тумель.
Ну, первое пожелание я уже выполнил – появилась рубрика "Новости". Она, конечно, будет появляться не в каждом выпуске, но самые важные события в мире VisualC++ будут освещаться именно там.
О VS NextGen я как раз готовлю материал, даже уже был анонс ("Что дядя Билли нам готовит…") – статья выйдет через выпуск, или , в крайнем случае, через два-три.
А вот насчет произношения "C sharp", гадать, увы, не придется ;) Знак "#" в музыке обозначает диез, т.е. повышение звука на полтона (здесь Microsoft, скорее всего, проводит аналогию с операцией инкрементирования "++"). А "диез" по-английски как раз и будет "sharp" (можете посмотреть в словаре). Все-таки 8 лет муз. школы не прошли для меня даром!;) Так что конкурс отменяется.
Про переименование рассылки в Visual C# подумаем, когда a) прочитаем про этот C# – здесь же;) и б) Microsoft выпустит продукт под таким названием.
А по поводу пожелания – так ведь так оно и есть! Рубрика WinAPI на что? А вот ActiveX и СOM действительно рассылкой не освещаются. Про COM/DCOM кажется, есть отдельная рассылка.
На заданные в прошлом выпуске вопросы пришло очень много ответов, так что я, скорее всего, похожие ответы сгруппирую в один, а потом просто укажу, кто такой ответ прислал. Иначе объем выпуска не выдержит ни один почтовый ящик ;) Постараюсь никого не забыть!
Да, и еще. Ради бога, прошу извинить меня тех, кто написал мне и не получил пока ответа. Писем приходит очень много, и я не могу отвечать всем.
На сегодня пока все. Рубрики "WinAPI" и "Вопрос-Ответ" – в следующем выпуске.
Будьте здоровы!
©Алекс Jenter mailto:[email protected] Красноярск, 2000.
Программирование на Visual C++
Выпуск №7 от 06/07/2000
Добрый день!
Сегодня я представляю вам обещанное продолжение публикации о типах WinAPI, а также ответы на заданные в 5-ом выпуске вопросы.
WINAPI WinAPI: НЕ ЗАПУТАЙТЕСЬ В ТИПАХ (Продолжение. Начало см. выпуск No.5)
Очень часто вами будет использоваться тип HANDLE — дескриптор, предназначенный для описания различных объектов. На самом деле этот тип представляет собой ни что иное, как указатель на void, т.е. как бы на любой тип.
Объекты Windows обычно представлены своими дескрипторами. Например, HWND — дескриптор окна. Что он из себя представляет? Давайте посмотрим:
В файле windef.h можно обнаружить такую строчку:
DECLARE_HANDLE(HWND);
Эта строка при определенной опции STRICT разворачивается в
struct HWND__ {int unused;};
typedef struct HWND__ *HWNDж
То есть HWND есть указатель на структуру HWND__. Если же опция STRICT не определена, то HWND везде заменяется на HANDLE.
Идентификатор STRICT указывает на необходимость проводить более строгую проверку типов. Как вы уже убедились, без этой опции все HWND, а также описатели других объектов Windows — HPEN, HBITMAP, HFONT, HMENU, HDC и др. будут фактически представлять собой один тип — HANDLE. Если же вы включите определение STRICT, тогда они будут трактоваться как разные типы (благодаря макросу DECLARE_HANDLE), и при их несоответствии компилятор будет выдавать сообщение об ошибке. Использование STRICT рекомендуется для того, чтобы было легче находить возможные ошибки в программе.
В заключение давайте рассмотрим очень часто используемый тип COLORREF. По сути это unsigned long. Этот тип представляет возможность задать цвет набором его RED, GREEN и BLUE составляющих, для этого используйте макрос RGB:
COLORREF color=RGB(0,255,255);
Результат этого выражения – длинное целое число, самый младший байт которого содержит интенсивность красного, второй – зеленого и третий байт – синего. В этом случае color будет содержать голубой цвет. Сам макрос RGB(r,g,b) при обработке препроцессором расширяется до ((COLORREF)((BYTE)(r) | ((WORD)(g) <<8)) | (((DWORD)(BYTE)(b))<<16))).
