Книга: Системное программирование в среде Windows

Сноски из книги

· #1

Тем не менее, в тех местах книги, где речь идет о средствах, неприменимых в Windows 9х, делаются соответствующие оговорки.

· #2

Автор вовсе не стремится каким-либо образом дополнить существующие коммерческие продукты, а также продукты с открытым исходным кодом, в которых предоставляются полные наборы утилит UNIX. Хотя приводимые примеры и могут найти практическое применение, они предназначены, главным образом, для того, чтобы продемонстрировать возможности функций Windows. Как бы то ни было, читатели, не знакомые с UNIX, не будут испытывать каких-либо трудностей в понимании программ или их функциональности.

· #3

Замечания, сделанные в адрес UNIX, в равной степени относятся также к Linux и некоторым другим системам, поддерживающим POSIX API.

· #4

Иногда, имея в виду в основном серверы, но не исключая и персональные приложения, говорят о возможной угрозе преобладанию Windows со стороны Linux. Хотя сама по себе эта тема является чрезвычайно интересной, размышления о путях будущего развития систем, не имеющие непосредственного отношения к рассмотрению сравнительных достоинств и недостатков Windows и Linux, выходят за рамки данной книги.

· #5

О том, насколько разнообразен круг систем, на которых может быть развернута Windows, говорит хотя бы тот факт, что диапазон компьютеров, использованных для тестирования приведенных в этой книге примеров программ, простирается от давно забытой 486-й модели с 16 Мбайт ОЗУ до четырехпроцессорного (процессоры Xeon с рабочей частотой 2 ГГц) сервера масштаба предприятия, оборудованного ОЗУ емкостью 8 Гбайт.

· #6

Протоколы Windows Sockets и RPC не являются частью самой Windows, что не воспрепятствовало описанию сокетов в данной книге, поскольку они самым непосредственным образом укладываются в рамки интересующей нас общей темы и используемого подхода.

· #7

Несмотря на аналогию между упомянутыми дескрипторами и дескрипторами HWND и HDC, используемыми при написании программ для Windows GUI, между ними существует ряд отличий.

· #8

Такие типы, как PVOID, входят в include-файлы без префикса, но в примерах мы будем придерживаться правил их употребления, принятых во многих книгах и документации Microsoft.

· #9

О том, какими быстрыми темпами улучшаются показатели стоимости и производительности, вы можете судить хотя бы по тому факту, что еще в 1997 году в первом издании этой книги автор, без тени смущения или неловкости, в качестве необходимых требований указывал 16 Мбайт ОЗУ и 256 Мбайт свободного места на жестком диске. Для написания настоящего, третьего издания книги используется лэптоп стоимостью менее $1000, с объемом ОЗУ в более чем 10 раз превышающим прежний (что больше ранее требуемого объема дискового пространства), 100-кратной емкостью жесткого диска и 50-кратным превышением быстродействия процессора по сравнению с аналогичными характеристиками компьютера стоимостью $2500, который использовался при подготовке первого издания.

· #10

В приложении А показано, как исключить ненужные определения для ускорения компиляции и экономии дискового пространства.

· #11

Обратите внимание на то, что логика цикла зависит от принятого в стандарте ANSI С порядка вычисления логических операций "и" (&&) и "или" (||) в направлении слева направо.

· #12

Символ подчеркивания (_) указывает на то, что данная функция или ключевое слово предоставляются компилятором Microsoft С, тогда как буквы t и Т указывают на то, что данная функция предназначена для работы с обобщенными символами, имеющими расширенную форму. Аналогичные возможности предлагаются и другими средами разработки приложений, хотя используемые в них имена функций и ключевые слова могут отличаться от приведенных выше.

· #13

В соответствии со сложившейся практикой для обозначения длинных указателей на параметры, представленные строками символов, используется префикс l.

· #14

Во время написания данной книги даже недорогие системы на базе лэптопов комплектовались жесткими дисками емкостью 40 Гбайт и более, и поэтому даже в случае малых систем средства для работы с файлами, размеры которых превышают 4 Гбайт, является не только желательными, но и необходимыми.

· #15

Сравнение функций SetFilePointer и GetCurrentDirectory демонстрирует непоследовательность стиля программирования Windows. В некоторых случаях для передачи входных и выходных значений применяются только параметры.

· #16

Вместе с тем, рассчитывать на 100-наносекундную точность не следует; точность измерения времени может быть различной в зависимости от характеристик оборудования.

· #17

Гораздо более удобным и последовательным было бы использование для управления реестром дескрипторов типа HANDLE. Существуют также и другие ничем не оправданные отклонения от принятой в Windows практики.

· #18

Заметьте, что суффикс "Ех" следует использовать или опускать в точном соответствии с приведенными именами функций. Функция, в названии которой присутствует этот суффикс, является расширением функции, в названии которой этот суффикс отсутствует.

· #19

Возможно, это дело вкуса, — то ли индивидуального, то ли корпоративного, — но многие программисты никогда не пользуются оператором goto и избегают употребления оператора break, кроме случаев его совместного использования с операторами switch и иногда — в циклах, а также совместного использования с операторами continue. Те, кто мыслит трезво, не спешат определять свою позицию в этом отношении. Обработчики завершения и исключений могут решать многие из тех задач, для решения которых вам хотелось бы привлечь оператор goto и операторы, снабженные метками.

· #20

Этот оператор является специфическим для компилятора Microsoft С и предоставляет эффективный способ выхода из блока try…finally без аварийного завершения выполнения.

· #21

Цены на модули памяти постоянно снижаются, а "типичный" объем доступной памяти увеличивается, поэтому назвать, какой именно объем памяти является типичным, довольно затруднительно. Во время написания данной книги недорогие системы снабжались памятью объемом 128-256 Мбайт. В большинстве случаев такой памяти будет вполне достаточно, но она не является оптимальной для Windows XP. Для систем Windows Server 2003 требуемый объем памяти обычно гораздо больше указанного.

· #22

Понятие потоков вводится в главе 7.

· #23

Обычно для создания объектов типа X используются системные вызовы CreateX. Функция HeapCreate является исключением из этого правила.

· #24

Утверждение относительно согласованности отображенных представлений файлов, видимых разными процессами, неприменимо к сетевым файлам. Файлы должны быть локальными.

· #25

В главе 10 рассказывается о косвенном методе, позволяющем одному потоку возбуждать исключения в другом, причем эта же методика применима и к потокам, принадлежащим разным процессам.

· #26

Рабочий набор — это набор страниц виртуального адресного пространства, которые ОС считает необходимым загрузить в память, прежде чем пытаться запустить любой из потоков процесса. Эта тема освещается в большинстве руководств по ОС.

· #27

Как объясняется в следующей главе, мьютексы — это объекты синхронизации, владельцами которых могут быть потоки.

· #28

Использование в данном случае контрольной суммы, вычисляемой в результате применения операции исключающего "или" к битам сообщения, носит исключительно иллюстративный характер. Существует множество других, более совершенных методик проверки целостности данных, которые и должны использоваться в промышленных приложениях.

· #29

Выбирая необходимый тип объекта, руководствуйтесь следующим правилом: если упоминавшиеся ограничения приемлемы — используйте объекты CRITICAL_SECTION, если же имеется несколько процессов или требуются возможности мьютексов — применяйте мьютексы.

· #30

Как показано в главе 10, в упражнении с семафором (упражнение 10.11), системные службы Windows предоставляют возможность организации взаимодействия между процессами также посредством отображаемых файлов. Дополнительные механизмы IPC включают файлы, сокеты, удаленные вызовы процедур, СОМ и отправку сообщений через почтовые ящики. Сокеты рассматриваются в главе 12.

· #31

Это утверждение нуждается в дополнительных разъяснениях. Для большинства сетевых приложений и высокоуровневых протоколов (http, ftp и так далее) более предпочтительным является интерфейс Windows Sockets API, особенно в тех случаях, когда требуется обеспечить межплатформенное взаимодействие с системами, отличными от Windows, на основе протокола TCP/IP. Многие разработчики предпочитают ограничивать использование именованных каналов лишь случаями IPC в пределах обособленной системы или в сетях Windows.

· #32

Заметьте, что функция TransactNamedPipe не только предлагает более удобный способ использования пары функций WriteFile и ReadFile, но и обеспечивает определенные преимущества в плане производительности. Один из экспериментов продемонстрировал повышение пропускной способности канала в интервале от 57% (небольшие сообщения) до 24% (крупные сообщения).

· #33

Эта терминология может несколько сбивать с толку, поскольку системы Windows предоставляют многочисленные услуги, которые не относятся к услугам, оказываемым службами Windows Services. Однако использование на протяжении всей этой книги термина "Windows" в тех местах, где имеется в виду API, кое-кем также может восприниматься неоднозначно.

· #34

Если служба вызывает функцию MessageBox, то в качестве типа окна сообщения следует указать MB_SERVICE_NOTIFICATION. Тогда сообщения будут отображаться на активном рабочем столе, даже если ни один из пользователей еще не успел войти в систему на данном компьютере.

· #35

В будущем, благодаря развитию платформы Win64 и предоставлению больших объемов физической памяти, острота этой проблемы, по всей видимости, снизится.

· #36

Точнее говоря, "UNIX" означает функции стандарта POSIX, описанные в спецификации The Single UNIX Specification (http://www.opengroup.org/onlinepubs/007908799/). Эта спецификация реализуется в UNIX и Linux. В свою очередь, исторически эта спецификация возникла на основе UNIX. 

----

Оглавление книги

Оглавление статьи/книги

Генерация: 0.046. Запросов К БД/Cache: 0 / 0
поделиться
Вверх Вниз