WinAPI + MSDN + MS SDK + MS DDK

← →
iva (2002-05-08 11:17) [0]

Все время вижу эти ссылки. Скажите, где это все можно посмотреть?

← →
Song (2002-05-08 11:20) [1]

В инете и в хэлпе.

← →
iva (2002-05-08 11:24) [2]

А со ссылками не поможете?

← →
Александр Спелицин (2002-05-08 11:44) [3]

http://www.microsoft.com/msdn/

← →
eSKey (2002-05-08 12:51) [4]

А реально скачать онлайновый MSDN чем-нибудь вроде Teleport"а ?

← →
Дмитрий Баранов (2002-05-08 13:08) [5]

>>eSKey
Во-первых, нам неск. гигов, во-вторых, вся навигация построена на всяких JScript`ах, т.е. ссылок, по которым можно построить алгоритм рекурсивного скачивания, как таковых там нет - так что - нет, не реально :))

← →
cypher (2002-05-08 21:58) [6]

Реально купить... дисков шесть или около того весит

← →
ION T (2002-05-08 22:02) [7]

У меня на трех (за второй квартал прошлого года).

← →
IronHawk (2002-05-08 23:01) [8]

> eSKey (08.05.02 12:51)
> А реально скачать онлайновый MSDN чем-нибудь вроде Teleport"а
> ?

Offline Explorer-oм этот вест MSDN скачиваеться за две ночи, потом реально на локальной машине работает!

← →
iZEN (2002-05-08 23:58) [9]

MDSN -- это целая структурированная система справочной базы по всем(почти) разработкам Microsoft, касающихся Windows и API в той или иной степени. Изучение MSDN может занять всю жизнь.:)

После тесной работы с Windows как пользователь, администратор, программист лично для себя я сделал вывод, что не стоит всей душой и телом (и деньгой) поддерживать такого "непознаваемого" монолитного монстра как Windows. Уж конечно я не буду покупать комплект MSDN и/или годовую подписку на него (даже на пиратских дисках) -- это убивает время, которое можно посвятить альтернативным разработкам, которые гибче, мощнее, и, что удивительно, их API в десятки раз меньше по объёму -- времени на изучение требуется, соответственно, во столько же раз меньше.

Конечно, если человек, вопрошающий о MSDN, хочет в будущем (именно в будущем) писать только под Windows прикладные приложения и драйвера и это ему будет приносить пользу, что ж, пусть "качает"-достаёт MSDN -- будет ещё один MS-ориентированный разработчик, который не смотрит по сторонам.:)) Хех...

← →
Suntechnic (2002-05-09 01:23) [10]

>iZEN (08.05.02 23:58)
...лично для себя я сделал вывод, что не стоит всей душой и телом (и деньгой) поддерживать такого "непознаваемого" монолитного монстра как Windows.

Ты конечно волен для себя какие угодно выводы делать :), но если 80-90% всех ОС в мире для ПК под Windows работают, то вывод напрашивается сам собой и без твоего участия :). А в Windows без MSDN никуда...

← →
Malder (2002-05-09 01:31) [11]

Suntechnic, ну прям уж и некуда ! Все мы используем Дельфи и чистым АПИ там мало пахнет.

И вообще, Win32 SDK от Борланд мне больше нравится, чем MSDN...

← →
Suntechnic (2002-05-09 07:24) [12]

>Malder © (09.05.02 01:31)

Все мы используем Дельфи и чистым АПИ там мало пахнет.

Прально... там им не пахнет... там им воняет :) Если вы хотите написать хоть мало-мальски существенный проект, то в MSDN залезть вам придётся.

Win32 SDK сам частенько пользуюсь. Там кое-что искать удобнее, но сами понимаете 4 диска MSDN не идут ни в какое сравнение с одним диском с 3 весриями делфей и в каждом по своему Win32 SDK.

P.S.
Кстати Win32 SDK это часть MSDN. Это на тот случай, если вы скажите, что вы и одним Win32 SDK прекрасно обходитесь без MSDN :)

← →
Malder (2002-05-09 12:01) [13]

>Suntechnic

Если вы хотите написать хоть мало-мальски существенный проект, то в MSDN залезть вам придётся.

Да ? Смотря что называть существенным проектом. Троянского коня? Тогда несомненно - нужен маленький размер. И нужно чтобы процесс не показывался. Что еще ? =) Весь WinAPI нужен для маленьких хитростей, которых в существенном проекте нету. Зачем винапи ?
Писал я тут прогу - типа троянца. Использовал API.
А вот писал базу данны сетевую - и почему то не потребовалось. Можно конечно было использовать API interbase, но что-то не хотелось.

Правильно тут сказали, можете всю жизнь потратить на изучение MSDN, а потом этим хвалиться - у меня есть такие друзья. Так вот что. Ничего серьезного они не написали. И, имхо, не напишут. Зато как ходячие справочники по WinAPI - просто золотые ребята...

← →
Delirium (2002-05-09 14:00) [14]

> Malder

Ну причём здесь трояны? Я всю жизнь занимаюсь разработкой прикладных приложений для работы с БД и тем не менее только для пользовательского интерфейса зачастую приходится прибегать к API, так что MSDN нужен, хотя я всегда пользуюсь on-line-овым (никогда не устаревает :) ).

← →
Malder (2002-05-09 14:50) [15]

Delirium, ну не знаю. Приведи пример, когда для пользовательского интерфейса нужно использование WinAPI ?!

← →
Delirium (2002-05-09 15:02) [16]

SetWindowPos, например, - гораздо удобнее, нежели операции с TForm. А вот ещё - как обойтись без PostMessage, когда это необходимо, пользовать TTimer :) ?

← →
Malder (2002-05-09 15:44) [17]

Delirium.

1) Чем SetWindowPos удобнее ?

2) Не понял насчет PostMessage и TTimer. Как это вообще связано?

← →
Suntechnic (2002-05-09 21:32) [18]

>Malder © (09.05.02 12:01)

Да ? Смотря что называть существенным проектом. Троянского коня? Тогда несомненно - нужен маленький размер. И нужно чтобы процесс не показывался. Что еще ? =) Весь WinAPI нужен для маленьких хитростей, которых в существенном проекте нету. Зачем винапи ?

Ну расскажите мне, например, как вы будете реализовывать межпроцессорную синхронизацию средствами VCL? Или это только в троянах используется?

Правильно тут сказали, можете всю жизнь потратить на изучение MSDN, а потом этим хвалиться - у меня есть такие друзья. Так вот что. Ничего серьезного они не написали. И, имхо, не напишут. Зато как ходячие справочники по WinAPI - просто золотые ребята...

Вы тут слегка цели и средства напутали. Цель это программа, а средство MSDN, но никак не наоборот.

← →
Anatoly Podgoretsky (2002-05-09 22:04) [19]

Malder © (09.05.02 14:50)

Для начала ShellExecute

← →
limon (2002-05-10 10:59) [20]

> Malder
MSDN - это тот же help, только по WinAPI.
И если работать только со стандартной формочкой от VCL, ессно, он не потребуется. Как только приходится копнуть чуть глубже - все, нужен доступ к системе.

← →
Delirium (2002-05-10 11:28) [21]

> Malder

"Не понял насчет PostMessage и TTimer. Как это вообще связано?"

Да оч.просто связано, допустим мне необходимо осуществить асинхронный вызов процедуры, для этого и создана функция PostMessage см. Help - You can post a message to a message queue by using the PostMessage function. PostMessage places a message at the end of a thread"s message queue and returns immediately, without waiting for the thread to process the message. Если же я пользуюсь исключительно VCL мне придётся пойти на такое извращение как: в основной процедуре включаю TTimer c задержкой 1мс, а в OnTimer выключаю его и делаю то, что мне надо. Согласись, это довльно кривой подход, может знаешь лучше ?

← →
iZEN (2002-05-10 12:14) [22]

/**Suntechnic © (09.05.02 21:32):
<...>Ну расскажите мне, например, как вы будете реализовывать межпроцессорную синхронизацию средствами VCL?<...>
*/

Нужно различать, на каком уровне всё надо делать: ПРИКЛАДНОМ или СИСТЕМНОМ. В первом случае лучше использовать асинхронную службу сообщений(MS Message Queue Service), а во втором случае API межпроцессного взаимодействия(IPC). Опять же, приходится выбирать между двумя почти равнозначными API, которые прикованы к API Win32, а из Delphi виден хорошо только краешек MS MQS (COM+).

← →
esu (2002-05-10 13:04) [23]

Я вот только не понимаю зачем его изучать ? Главное знать что ищешь и как и где это искать. Да и говорить что пишем мы на чистом VCL, API не признаем... Все равно от API никто и никуда далеко не уйдет - дельфи только красивая обертка.

← →
iZEN (2002-05-10 15:23) [24]

/**esu © (10.05.02 13:04):
<...>Все равно от API никто и никуда далеко не уйдет - дельфи только красивая обертка.
*/

В точку!
Delphi предназначена для разработки прикладных задач, а не системного программирования. Delphi "обёртывает" системно-ориентироанное API Windows в простую библиотеку VCL/RTL для большего абстрагирования от системы в прикладных проектах. Такова идеология Pascal.

← →
Malder (2002-05-11 13:41) [25]

Я не буду спорить ни с кем. Знаю одно - при разработке серьезных приложений (не для себя) WinAPI НЕ использую. Delphi может и просто обертка - но мне ее вполне хватает (VCL в смысле).
Это просто мои приложения и в них вызовов API непосредственно нет.

P.S. Наверное руки кривые...

← →
Malder (2002-05-11 16:18) [26]

Delirium, а все таки я не понял твой пример. Какой смысл запускать процедуру таким диком образом ?!

← →
ZZ (2002-05-11 16:35) [27]

Malder
при разработке серьезных приложений (не для себя) WinAPI НЕ использую
Ты ооооооооооочень узко понимаешь, что такое WinAPI!! Или я не понимаю , что за программы ты пишешь... :)

← →
Suntechnic (2002-05-11 17:31) [28]

Точно так же как знание анатомии делает киллера более профессиональным, Win API делает более профессиональным программиста. А решать конечно каждому индивидуально....

← →
iZEN (2002-05-11 17:43) [29]

Для ZZ © (11.05.02 16:35).
Например, серверы приложений НЕ должны использовать API опреационной системы, иначе это приведёт к очень печальным результатам в ходе функционирования. Мало кто из программистов-прикладников может грамотно распоряжаться системными ресурсами: отсюда утечки памяти, повисшие указатели и ссылки и т.д.)

← →
ZZ (2002-05-11 17:49) [30]

iZEN
Про серверы - не понял почему ?

Мало кто из программистов-прикладников может грамотно распоряжаться системными ресурсами:
Это про WinAPI или в общем?

← →
ZZ (2002-05-11 17:57) [31]

iZEN
Да, проги бывают разные.. СУБД всякие наверное без WinAPI обойдутся.
Прошу учесть, что (11.05.02 17:49) было сказано в ответ на Знаю одно - при разработке серьезных приложений (не для себя) WinAPI НЕ использую. Delphi может и просто обертка - но мне ее вполне хватает (VCL в смысле).
Серверы с использованием VCL наверное тоже не пишут.

← →
iZEN (2002-05-11 20:10) [32]

Для ZZ.
Серверы приложений и приложения для серверов приложений очень критичны в плане обеспечения "качества сервиса". Что это значит?
Есть такое понятие как "24x7" -- это обеспечение отказоустойчивости 24 часа в сутки и 7 дней в неделю, это есть параметры качества обслуживания клиентов, которые так или иначе работают с программным обеспечением сервера приложений по трёх- и четырёх-звенной системе уровня предприятий (B2B) и/или предприятие-потребитель (B2C).
Так вот, создание серверных приложений и самих серверов приложений с прямым использованием API операционной системы даже с "локализацией" вызовов в конкретном модуле себя не оправдывает (с экономической точки зрения) по причине слабой отказоустойчивости прикладного кода, использующего напрямую низкоуровневое API.
Конечно, можно возразить, что "всё будет отлажено", но кто поручится за "правильность" кода, который фактически становится частью операционной системы и тесно взаимодействует с ней? Как долго сможет "продержаться" запущенное приложение, если к нему будут обращаться тысячи пользователей ежеминутно?

Сколько раз на дню серверы Microsoft перезагружаются никто не знает? Интересная статистика выходит :), хотя вроде бы COM+, ASP работают под IIS...

Поэтому и создаются высокоуровневые библиотеки-фреймворки типа VCL для Delphi, JSP/EJB для Java и т.д. И всё только для того, чтобы программист-прикладник не лез в дебри ОС, но решал свои задачи средствами высокоуровневых API максимально просто и эффективно.

← →
Malder (2002-05-11 23:36) [33]

iZEN, полностью поддерживаю. Не думаю, что я смогу обеспечить ту надежность и безгрешность кода, какая реализована в VCL.

ZZ Ты ооооооооооочень узко понимаешь, что такое WinAPI!!
Ну за дурака меня тоже не держи. Я, конечно, понимаю что VCL использует WinAPI. Я же написал Это просто мои приложения и в них вызовов API непосредственно нет.

Suntechnic, пример просто замечательый. В точку. В общем, килеру лучше знать анатомию. Но намного ли это упростит так сказать работу ? Ему лучше знать устройство оружия, но поможет ли ему это по настоящему ? В чем то да, но не более того.

На самом деле, я не пытаюсь доказать, что WinAPI использовать не нужно. Как правильно заметил Anatoly Podgoretsky Для начала ShellExecute - я тоже не знаю чем бы заменить эту функцию из VCL. Спор то из ничего возник. Я просто хотел опровергнуть утверждение Если вы хотите написать хоть мало-мальски существенный проект, то в MSDN залезть вам придётся. - это имхо неверно. Хотя не говорит, что MSDN и WinAPI пользоваться не надо.

← →
ZZ (2002-05-12 17:12) [34]

Malder ©
Ну за дурака меня тоже не держи. Я, конечно, понимаю что VCL использует WinAPI.

Повторю : ZZ © (11.05.02 16:35)
Или я не понимаю , что за программы ты пишешь
Хотя это я погорячился - программы бывают разные....

Поросто судя по твоим высказываниям ты считаешь, что WinAPI это только CreateWindow и все, что с ним связано (одним словом окошки).

iZEN (11.05.02 20:10)
Извени, но до меня просто не доходит, что ты пытаешся объяснить:
1. Использовать WinAPI - это плохо. Лучше продублируем код функций WinAPI на С (асме, Java и т.д.).
2. Использовать WinAPI - это плохо. Лучше будем использовать VCL (JSP и т.д.) - доверимся разработчикам этих библиотек/компонент. Они то знают, что нам нужно.
Более похоже, что второе. Но откуда тут надежность?

Сколько раз на дню серверы Microsoft перезагружаются никто не знает.
Может годами стоят без перезагрузки.

← →
VuDZ (2002-05-12 18:00) [35]

Мой мааааленький вклад в вашу дискусию - купить МСДН на дисках - и параллельно просматривать в инете с случае траблов - многие вещи описаны типа - look in Platform SDK, приходиться просматривать SDK"шные хедеры, правда всё это лучше скачать отдельно, а если на одной и той же странице противоричивые сведения - например о поддерживаемых платформах - не часто, но бывает - приходиться смотреть в инете.
Ну и ещё там есть немеренная куча доки, в частности переодика, весьма интересные статью Under the Hood...
DDK и SDK - пости одинавые вещи, но в DDK есть ещё куча неописанных ф-ий, полезных не только дровосекам.

> Так вот, создание серверных приложений и самих серверов
> приложений с прямым использованием API операционной системы
> даже с "локализацией" вызовов в конкретном модуле себя не
> оправдывает (с экономической точки зрения) по причине слабой
> отказоустойчивости прикладного кода, использующего напрямую
> низкоуровневое API.

Ню-ню - чтение - запись мы то же будет делать через стандартные ф-ии Паскаля/С, не обращая внимания что это просто абстрагирование над API, как и большая часть ф-ий - от работы с консолью и временем, до файлового ввода-вывода.

> Конечно, можно возразить, что "всё будет отлажено", но кто
> поручится за "правильность" кода, который фактически становится
> частью операционной системы и тесно взаимодействует с ней?
> Как долго сможет "продержаться" запущенное приложение, если
> к нему будут обращаться тысячи пользователей ежеминутно?

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

> Сколько раз на дню серверы Microsoft перезагружаются никто
> не знает? Интересная статистика выходит :), хотя вроде бы
> COM+, ASP работают под IIS...

1. Мой рабочий сервер, который насилуется весьма жестоко - SQL, FileServer, и куча всего прочего - уже почти год без перезагрузок.
2. Как СОМ+ и АСП свзаны с первым?

> Поэтому и создаются высокоуровневые библиотеки-фреймворки
> типа VCL для Delphi, JSP/EJB для Java и т.д. И всё только
> для того, чтобы программист-прикладник не лез в дебри ОС,
> но решал свои задачи средствами высокоуровневых API максимально
> просто и эффективно.

Мда.... прямотаки парадайз какой-то... Позвольте вернуть Вас на грешную Землю - мир, в частности компьютерный, не добрая фея, и всё предусмотреть в библиотеках нереально. У меня куча кода, который ввыполняет много разных "фич" - от элементарной абстракции, до весьма "продвинутых" простых действий, типа загрузка либы, проверка версии, поиск нужной и пр., но если я буду всё оборацивать в такие ф-ии, то большая часть моего времени уйдёт на написание таких обёрток.
По этому поводу советую почитать Лу Гринзоу - Философия программирования для Win95/NT

> Мало кто из программистов-прикладников может грамотно распоряжаться
> системными ресурсами: отсюда утечки памяти, повисшие указатели
> и ссылки и т.д.)

Э... вообщето память, она, того, несколько не системный ресурс, в полном понятие этого слова - когда софт убивается, винда просматривает всю таблицу указателей и освобождает память сама.
А про ссылки - это вообще что-то странное (если я правильно понял, а этот термин может иметь разное толкование в С++ и пр. языках)

> Да оч.просто связано, допустим мне необходимо осуществить
> асинхронный вызов процедуры, для этого и создана функция
> PostMessage см. Help - You can post a message to a message
> queue by using the PostMessage function. PostMessage places
> a message at the end of a thread"s message queue and returns
> immediately, without waiting for the thread to process the
> message. Если же я пользуюсь исключительно VCL мне придётся
> пойти на такое извращение как: в основной процедуре включаю
> TTimer c задержкой 1мс, а в OnTimer выключаю его и делаю
> то, что мне надо. Согласись, это довльно кривой подход,
> может знаешь лучше ?

Может я не правильно понял - а как на счёт потоков и/или объектов синхронизации?

← →
KilkennyCat (2002-05-13 04:57) [36]

А я частенько использую апи. Чтобы кто ни говорил.
Мои основания:
1) проще
2) надежней
3) меньше размер (ненавижу большие программы, хоть винт у меня не из хилых...)
4) четкое представление того, чего я хочу и как это будет работать, что позволяет в дальнейшем работать с исходниками где угодно, с++, VBA и т.д.

← →
Malder (2002-05-13 18:14) [37]

ZZ
Поросто судя по твоим высказываниям ты считаешь, что WinAPI это только CreateWindow и все, что с ним связано (одним словом окошки).

Я так не считаю. Я считаю, что все, что делается в Windows Реализовано так или иначе через WinAPI...

WinAPI + MSDN + MS SDK + MS DDK Найти похожие ветки