Здравствуйте, DKM_MSFT, Вы писали:
DKM>Здравствуйте, Roman Odaisky, Вы писали:
RO>>В случае обнаружения проблемы с MS PowerPoint в ppчтототам.dll у меня уже есть все бинарники, я только хочу пересобрать эту DLL. DKM>У тебя нет необходимых бинарников. Чтобы ppчтототам.dll могла, например, использовать MSO.dll, ее нужно слинковать с mso.lib. Где ты возьмешь mso.lib? Это промежуточный файл, получающийся при билде проекта MSO. Он не шипится пользователям, потому что он им не нужен.
system("dumpbin /EXPORTS /OUT:vv_lg_db_tmp.txt #{ARGV[0]}")
aFile = File.new("vv_lg_db_tmp.txt")
aFileOut = File.new("vv_lg_db_tmp.def","w+")
aFileOut.print("LIBRARY \"vvlg\"\nEXPORTS\n")
aFile.each_line{ |line|
if line =~ /\s+[0-9a-fA-F]+\s+[0-9a-fA-F]+\s+[0-9a-fA-F]+\s+([0-9a-zA-Z\?@_]+)/ then
aFileOut.print "#{$1}\n"end
}
aFileOut.close
aFile.close
system("lib /DEF:vv_lg_db_tmp.def /OUT:#{ARGV[1]}")
File.delete("vv_lg_db_tmp.txt");
где-то так. требует студию, руби и исходную длл
Разве что офисные длл-ли экспортируют функции по ординалам
Ну, хорошо, давай по пунктам. От подготовки к разработке до чекина.
1) Вот у тебя есть чистая система (линукс без установленных средств разработки итп.) и у меня есть чистая система (виндовс без установленных средств разработки итп.)
Сколько у тебя времени займет подготовить полный build environment (с системой контроля версий, юнит тестами, багтрекером и всеми остальными тулзами, которые тебе в будущем понадобятся)?
У меня займет полчаса. Большую часть времени будет устанавливаться вижуал студио
2) Сколько команд ты введешь, чтобы настроить все вышеперечисленное?
Я введу одну и уйду пить кофе.
3) Теперь нам надо синхронизировать проекты с одинаковым количеством строк кода (скажем 5-6 миллионов) с последним рабочим билдом, на котором прошли все критические тесты. Более новые билды меня не интересуют. Сколько у тебя это займет времени выяснить, какой был последний такой билд и синхронизировать исходники?
У меня займет 5 минут.
4) А сколько команд это у тебя займет?
У меня одну.
5) Допустим, теперь я хочу установить синхронизированный проект без компиляции. Ну, например, чтобы его отдебажить. Сколько времени у тебя это займет?
У меня 4-5 минут.
6) А сколько команд это у тебя займет?
У меня одну.
7) Теперь я хочу внести изменения в проект. Изменения предполагают поиск определения и имплементации нескольких функций, которые ты собираешься использовать/менять. Функции находятся в разных файлах проекта, и ты не знаешь в каких. Сколько времени у тебя займет поиск нужной информации? У меня секунд 5 (порядка времени копирования/вставки).
8)Теперь я изменил 3-4 файла и хочу перебилдить проект. Сколько времени это у тебя займет? У меня меньше 1 минуты.
9) А сколько команд это у тебя займет?
У меня одну.
10) Теперь я хочу прогнать базовые тесты, чтобы проверить свои изменения. В опен офисе вообще есть такое понятие? И сколько команд это у тебя займет? У меня одну.
11) Отлично, теперь я хочу прогнать серьезные тесты, дабы проверить, что я ничего не сломал. Сколько команд у тебя это займет? У меня одну. И времени на моей машине это не займет нисколько, поскольку тесты будут выполняться удаленно. А у тебя?
12) То же, что и пункт 10, только для профилировки производительности.
13) Оказалось, что тесты не прошли. Как ты будешь их отлаживать? Я получу по e-mail сообщение о том, какой тест провалился, почему и в какой именно функции. Я запущу этот тест на удаленной машине еще раз (1 команда) и произведу отладку.
14) Я хочу создать инсталляционный пакет для своего тестера, дабы он протестировал мои изменения вручную. Сколько времени это у тебя займет? У меня 5 минут. А сколько команд? У меня одну.
15) У тестера на тестовой машине программа дает сбои. Сколько времени у тебя займет настройка удаленной тестерской машины для нормальной отладки (с символами, исходниками итп). У меня 30 секунд. А сколько команд? У меня одну.
16) Ну все, допустим, я отладил код. Теперь я хочу послать его на ревью. Для этого я введу одну команду, и все мои изменения будут упакованы и отправлены в удобочитаемой форме тем людям, которым я укажу. А что будешь делать ты?
17) Мой менеджер решил протестировать мои изменения у себя. К сожалению, у него стоит другой билд проекта, но он все равно хочет их проверить. Сколько времени у него это займет? 2 минуты. И две команды. А у твоего менеджера?
18) Мой менеджер решил, что изменения можно чекинить. Допустим, это баг фикс. Сколько времени у тебя займет зачекинить изменения, обновить статус бага и разослать письма всем людям, заинтересованным в отслеживании изменений в соответствующих местах проекта. У меня 30 секунд.
Здравствуйте, DKM_MSFT, Вы писали:
RO>>Э, не путай горячее с холодным. dpkg проверяет подпись только при установке, а MS Windows — всё время. Если кто-то имеет достаточно прав для того, чтобы заменить системный файл, то можно уже надевать белые тапки. System File Protection — такой же идиотизм.
DKM>Если вирус или троян теоретически может что-то сделать, то это не значит, что он это сделает. Большинство вирусов не могут заразить системные файлы именно благодаря System File Protection, хотя казалось бы, под администратором ничего не мешает им это сделать. Просто писатель вируса не удосужился написать обход этой системы, либо не знал как.
Последнее предложение — ключевое. Где-то в rsdn.humour была фотография шлагбаума и хорошо наезженных колей вокруг него. Примерно так же и в MS Windows.
RO>>В MS Windows параноидальная и неэффективная система безопасности. (Неэффективная в том смысле, что половина тамошних фич только парит мозги админам, не добавляя защищенности.) Там есть куча способов защитить систему от процессов с администраторскими правами, хотя это невозможно даже теоретически.
DKM>Теоретически это невозможно, зато хорошо работает против большинства тупых вирусов на практике.
Пару тупых вирусов оно поймает, и испортит жизнь многим админам.
Причина понятна — очень неудобно работать неадминской учетной записью, соответственно, вирусы исполняются из-под админа. И более 10 лет борются со следствием, а не с причиной.
RO>>Например, юниксы (пока не понаставили PAM/NSS) держат пароли в /etc/shadow. Где их держит MS Windows? Как их поменять вручную? Кому надо, всё равно знает, а администратору в экстремальных случаях проблемы.
DKM>Что значит "поменять вручную"? Файл с паролем отредактировать? Ну тогда это явный маразм. Или под "вручную" ты понимаешь "из консоли"? В виндовс это можно сделать.
А что тут такого? Если сильно нужно, можно и отредактировать.
Как из консоли MS Windows (а особенно в случае (частичной) неработоспособности системы) поменять кому-нибудь пароль?
RO>>Еще в Linux, если есть доступ к загрузчику, можно дописать в командную строку ядра init=/bin/sh и получить доступ root без пароля. Это уязвимость? А как загрузить MS Windows без пароля? Например, их recovery console (при загрузке с установочного CD!) просит пароль пользователя «Администратор». Зачем?!
DKM>Во первых, это настраивается в групповых политиках безопасности. И сделано это примерно затем, чтобы когда ты пойдешь пить чай, я не смог на пару минут сесть к тебе за компьютер с установочным CD, и накопировать тебе троянов.
С установочным не сможешь. А с любым LiveCD сможешь. И кого от кого защитили?
RO>>Один администратор не может прочитать документы другого. Причем у него всё равно есть SeTakeOwnership, так что если он захочет, то получит доступ к ним. Это защита чего от чего? (Юниксовый root даже не обременяет себя определением прав доступа на запрашиваемый объект.)
DKM>Есть. Ты знаешь много вирусов, которые это делают?
Что «есть»? И всё-таки, защита чего от чего?
DKM>Короче, был бы линукс более популярной системой, под которую выгодно писать вирусы, думаю ты бы сильно пересмотрел свое отношение к системе безопасности.
Я предположу, что там раньше доведут до ума AppArmor/PolicyKit/SELinux, чем появится много вирусов, и таких костылей, какие в MS Windows сейчас, никогда там не будет. В юниксах, кстати, такого рода защиту — по-настоящему действенную защиту — куда проще реализовать хотя бы в силу того, что там системных вызовов, подлежащих контролю, меньше. (Всего их 319 в Linux (Википедия), 330 в FreeBSD (Википедия), более 3400 в MS Windows (Шнайер, 2000 г., данных поновее не нашел).)
Здравствуйте, Cyberax, Вы писали:
RO>>Если кто-то имеет достаточно прав для того, чтобы заменить системный файл, то можно уже надевать белые тапки. C>На практике, вполне хватает — трояны сейчас всякие ламеры пишут для рассылки спама. У меня уже давно ностальгия по вирусам эпохи ДОСа, некоторые из них вообще были произведением искусства. Один OneHalf ( http://en.wikipedia.org/wiki/OneHalf_(computer_virus) ) чего стоил...
Интересно, что будет, когда (если) MS, наконец, сделают надежную защиту от ламерских вирусов (или все свалят на более другие ОС ;-))? Вернутся «старики»?
C>>>Например, я могу быстро посмотреть какие процессы в памяти имеют подпись MS (в Process Viewer'е от бывшего Sysinternals такая фича есть) — очень удобно для обнаружения всяких троянов. RO>>В MS Windows параноидальная и неэффективная система безопасности. (Неэффективная в том смысле, что половина тамошних фич только парит мозги админам, не добавляя защищенности.) Там есть куча способов защитить систему от процессов с администраторскими правами, хотя это невозможно даже теоретически. C>Да я знаю, можешь мне не говорить :)
Здравствуйте, DKM_MSFT, Вы писали:
DKM>Ну, хорошо, давай по пунктам. От подготовки к разработке до чекина. DKM>1) Вот у тебя есть чистая система (линукс без установленных средств разработки итп.) и у меня есть чистая система (виндовс без установленных средств разработки итп.) DKM>Сколько у тебя времени займет подготовить полный build environment (с системой контроля версий, юнит тестами, багтрекером и всеми остальными тулзами, которые тебе в будущем понадобятся)?
Примерно минуту настройки, не считая времени установки. Предполагается, что у меня уже есть готовые списки нужных пакетов — я просто делаю так:
dpkg --set-selections `cat required_packages`
apt-get -u dselect-upgrade
[иду пить чай пока оно скачается и установится]
cp -a saved_etc /etc # Копируем нужные файлы в /etc.
Собственно, я так свою систему и переношу между разными компьютерами.
DKM>2) Сколько команд ты введешь, чтобы настроить все вышеперечисленное? DKM>Я введу одну и уйду пить кофе.
Ну у меня несколько больше одной команды, но близко. И я пойду пить чай
DKM>3) Теперь нам надо синхронизировать проекты с одинаковым количеством строк кода (скажем 5-6 миллионов) с последним рабочим билдом, на котором прошли все критические тесты. Более новые билды меня не интересуют. Сколько у тебя это займет времени выяснить, какой был последний такой билд и синхронизировать исходники? DKM>У меня займет 5 минут.
"apt-get update; apt-get upgrade;" — обновит всю систему. Естественно, в списке источников обновлений будет репозиторий с integration-версиями софта.
Можно и отдельно нужную софтину с зависимостями обновить.
DKM>7) Теперь я хочу внести изменения в проект. Изменения предполагают поиск определения и имплементации нескольких функций, которые ты собираешься использовать/менять. Функции находятся в разных файлах проекта, и ты не знаешь в каких. Сколько времени у тебя займет поиск нужной информации? У меня секунд 5 (порядка времени копирования/вставки).
То есть? Это уже дело IDE, вообще-то. Можно использовать ctags. Ну и банального grep'а тоже часто хватает.
DKM>8)Теперь я изменил 3-4 файла и хочу перебилдить проект. Сколько времени это у тебя займет? У меня меньше 1 минуты.
Тут зависит от типа изменений. В модуляризованом проекте надо будет перестроить только один (небольшой) модуль. Во всех проектах, которые я мучал, внесение инкрементальных изменений требовало меньше минуты времени перекомпиляции.
Если требуется изменить фундаментальный include-файл, то тогда всё плохо. Но именно это вынуждает разработчиков больших открытых проектов делать нормальное деление на подсистемы и модули
Да, естественно, перестройка обычно заключается в запуске одной команды.
DKM>10) Теперь я хочу прогнать базовые тесты, чтобы проверить свои изменения. В опен офисе вообще есть такое понятие? И сколько команд это у тебя займет? У меня одну.
"make test"?
DKM>11) Отлично, теперь я хочу прогнать серьезные тесты, дабы проверить, что я ничего не сломал. Сколько команд у тебя это займет? У меня одну. И времени на моей машине это не займет нисколько, поскольку тесты будут выполняться удаленно. А у тебя?
Это, к сожалению, никак. Хотя над этим работа уже идет, я присылал ссылка на Ubuntu'вский проект.
Однако, опять же, при правильном делении на модули — можно ограничиться тестами измененного модуля.
DKM>12) То же, что и пункт 10, только для профилировки производительности.
Как частный случай тестов...
DKM>13) Оказалось, что тесты не прошли. Как ты будешь их отлаживать? Я получу по e-mail сообщение о том, какой тест провалился, почему и в какой именно функции. Я запущу этот тест на удаленной машине еще раз (1 команда) и произведу отладку.
Это базовая функциональность любой системы непрерывной интеграции.
DKM>14) Я хочу создать инсталляционный пакет для своего тестера, дабы он протестировал мои изменения вручную. Сколько времени это у тебя займет? У меня 5 минут. А сколько команд? У меня одну.
Аналогично.
DKM>15) У тестера на тестовой машине программа дает сбои. Сколько времени у тебя займет настройка удаленной тестерской машины для нормальной отладки (с символами, исходниками итп). У меня 30 секунд. А сколько команд? У меня одну.
OpenSource'ники обычно сами себе тестеры. Выделенные тестеры сразу используют отладочные версии.
DKM>16) Ну все, допустим, я отладил код. Теперь я хочу послать его на ревью. Для этого я введу одну команду, и все мои изменения будут упакованы и отправлены в удобочитаемой форме тем людям, которым я укажу. А что будешь делать ты?
Аналогично. Делаю diff моих изменений и посылаю по почте в список рассылки для разработчиков.
Для ядра Линукса: "git-send-email .". В других проектах, где делается review изменений — аналогично.
DKM>17) Мой менеджер решил протестировать мои изменения у себя. К сожалению, у него стоит другой билд проекта, но он все равно хочет их проверить. Сколько времени у него это займет? 2 минуты. И две команды. А у твоего менеджера?
У OpenSource-разработчика? Аллё!
Все публичные билды, естественно, кладутся в репозиторий пакетов, откуда можно его с зависимостями установить.
DKM>18) Мой менеджер решил, что изменения можно чекинить. Допустим, это баг фикс. Сколько времени у тебя займет зачекинить изменения, обновить статус бага и разослать письма всем людям, заинтересованным в отслеживании изменений в соответствующих местах проекта. У меня 30 секунд.
Зависит от проекта. В Линксе — примерно столько же времени (залить локальные обновления в публичное дерево подпроекта).
DKM>Продолжать?
Да.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>Ну, хорошо, давай по пунктам. От подготовки к разработке до чекина.
DKM>1) Вот у тебя есть чистая система (линукс без установленных средств разработки итп.) и у меня есть чистая система (виндовс без установленных средств разработки итп.)
DKM>Сколько у тебя времени займет подготовить полный build environment (с системой контроля версий, юнит тестами, багтрекером и всеми остальными тулзами, которые тебе в будущем понадобятся)?
DKM>У меня займет полчаса. Большую часть времени будет устанавливаться вижуал студио :(
Ты имеешь в виду, что на сервере всё уже настроено? Это «нечестно». С тем же успехом можно сказать, что в Linux можно всё сделать одной командой наподобие wget http://server/superscript.sh && chmod a+x superscript.sh && ./superscript.sh (я хотел было назвать скрипт с использованием неологизма, который можно обнаружить в этой статье во втором с конца абзаце: http://newkerogaz.narod.ru/r41.html — но воспитание мне не позволило :-).
Я вообще могу ответить, что apt-get install build-essential g++ boost-build svn kdevelop и т. д. займет очень немного времени и усилий, а все остальные перечисленные тобой фичи есть в вебморде, на которую админы потратили 100 человекомесяцев, и с тем же успехом работают по нажатию одной кнопки.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Ты имеешь в виду, что на сервере всё уже настроено? Это «нечестно».
Оно для того и заброшено на сервер, что быть "уже настроенным". Непонятно, нафига вообще сравнивать толстый и тонкие клиенты, как вы тут пытаетесь сделать — идеология разная.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>Здравствуйте, Cyberax, Вы писали: DKM><skip>
DKM>Ну, хорошо, давай по пунктам. От подготовки к разработке до чекина.
DKM>1) Вот у тебя есть чистая система (линукс без установленных средств разработки итп.) и у меня есть чистая система (виндовс без установленных средств разработки итп.)
DKM>Сколько у тебя времени займет подготовить полный build environment (с системой контроля версий, юнит тестами, багтрекером и всеми остальными тулзами, которые тебе в будущем понадобятся)?
DKM>У меня займет полчаса. Большую часть времени будет устанавливаться вижуал студио
DKM>2) Сколько команд ты введешь, чтобы настроить все вышеперечисленное? DKM>Я введу одну и уйду пить кофе.
Достаточно один раз собрать свой дистрибутив или поднять хард с backup.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>Здравствуйте, pavel_turbin, Вы писали:
_>>Исходники нужны как доплнение документации. К примеру, часто используемая CreateFile Function. Есть флаг
DKM>Если какой-то байт не описан в документации, значит не нужно его использовать. А если про что-то в явном виде написано, что это используется операционной системой и трогать это не нужно, значит трогать это не нужно. Потому что сегодня оно работает так, а завтра по-другому. И копать сорцы для выяснения того, как это работает сегодня — это очень хреновая идея, потому что завтра сорцы будут другие и вся ваша оптимизация может выйти вам боком.
Ну-ну, а как на счет не докумментированных функций, которые разрабочики в MS юзают только для своих программ? Или они не болятся?
В общем, тема практически во всех ветках себя исчерпала и переросла в обсуждение lin vs win. Поэтому пора закругляться и делать выводы
На мой взгляд, тут были озвучены следующие принципиально различные резоны открытия исходных кодов.
1) Поиск уязвимостей с целью их скорейшего исправления
2) Использование исходного кода ОС для оптимизации своего кода
3) Использование исходного кода ОС для написания программ для работы с недокументированными частями ОС.
4) Использование исходного кода для выяснения непонятных моментов в документации.
5) Открытие кодов с целью стимулировать "коммьюнити" исправлять баги вместо Микрософта.
Мне думается, что пункты 1, 4 и 5 имеют смысл. С них и начнем.
Пункт 1 решается методом запроса исходных кодов компанией, которая занимается соответствующей деятельностью, и не требует открытия кодов для всех.
Пункт 4 – серьезная проблема. Но, вообще говоря, пункт 4 должен быть исправлен со стороны Микрософта методом написания хорошей документации.
Пункт 5 потенциально любопытен, но в данный момент Микрософт без него вполне обходится, и, думаю, что какое-то время и дальше будет обходиться.
Пункты 2 и 3 я считаю хорошими причинами, почему коды надо закрыть, и не открывать их никогда Ибо нефиг писать софт, который может накрыться с выходом очередного апдейта.
Таким образом, кроме пункта 4 я не вижу причин для открытия кода Виндовс для всех.
Все вышесказанное ИМХО.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>Пункт 4 – серьезная проблема. Но, вообще говоря, пункт 4 должен быть исправлен со стороны Микрософта методом написания хорошей документации.
Это нереально, любая документация почти всегда остается неполной и устаревшей. Для выяснения тонких моментов рулит исходник.
DKM>Пункты 2 и 3 я считаю хорошими причинами, почему коды надо закрыть, и не открывать их никогда Ибо нефиг писать софт, который может накрыться с выходом очередного апдейта.
Почему? Недокументированые API часто необходимы, чтобы делать некоторые низкоуровневые вещи.
Конечно, если MS документирует всё, что можно — тогда будет замечательно. Однако, тут см. объяснение про пункт 4.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>На мой взгляд, тут были озвучены следующие принципиально различные резоны открытия исходных кодов. DKM>1) Поиск уязвимостей с целью их скорейшего исправления DKM>2) Использование исходного кода ОС для оптимизации своего кода DKM>3) Использование исходного кода ОС для написания программ для работы с недокументированными частями ОС. DKM>4) Использование исходного кода для выяснения непонятных моментов в документации. DKM>5) Открытие кодов с целью стимулировать "коммьюнити" исправлять баги вместо Микрософта.
6) Использование исходного кода ОС для поддержки публично недокументированных и закрытых форматов файлов и технологий..
DKM>Пункты 2 и 3 я считаю хорошими причинами, почему коды надо закрыть, и не открывать их никогда Ибо нефиг писать софт, который может накрыться с выходом очередного апдейта.
Здравствуйте, DKM_MSFT, Вы писали:
DKM>4) Использование исходного кода для выяснения непонятных моментов в документации.
DKM>Пункт 1 решается методом запроса исходных кодов компанией, которая занимается соответствующей деятельностью, и не требует открытия кодов для всех.
DKM>Пункт 4 – серьезная проблема. Но, вообще говоря, пункт 4 должен быть исправлен со стороны Микрософта методом написания хорошей документации.
Расщитре п4 как:
4.1 чтение кода Windows с целью обучения и понимания как определенные модули устроены для понимания всего дизайна OS. К примеру, WDK включает "живые" драйвера, типа fastfat (src\filesys\fastfat). Такие примеры реально помогают понять как все устроено внутри для драйвера файловой систем. Становится гораздо понятней как нужно писать свой драйвер файловой системы. Но драйвер ntfs.sys закрыт Почему было бы не включить все системные программы начнем с ntft.sys, fips.sys, cmd.exe, regedit, lsass.exe? Те кто пишет системный софт могли бы использовать эти приложения как примеры, гораздо более удобные чем глупые примеры с MSDN.
4.2 открыть _все_ форматы файлов. К примеру, PST (Outlook) закрытый формат. Почему (я знаю ответ)? Ведь, невсегда есть возможность использовать E-MAPI. Все форматы файлов должны быть открыты иначе народ занимается reverse engineering. От этого плохо обоим сторонам.
Здравствуйте, Cyberax, Вы писали:
C>У меня уже давно ностальгия по вирусам эпохи ДОСа, некоторые из них вообще были произведением искусства. Один OneHalf ( http://en.wikipedia.org/wiki/OneHalf_(computer_virus) ) чего стоил...
Как я тебя понимаю... А Ghost, заражавший com-файлы, меняя в них всего пару-тройку байт и дописывая себя в хвост сектора за концом файла?
DKM_MSFT однажды (24 февраля 2008 01:11) писал:
> В общем, тема практически во всех ветках себя исчерпала и переросла в обсуждение lin vs win. Поэтому пора закругляться и делать выводы
Тут всегда так. Не обращай внимание.
> На мой взгляд, тут были озвучены следующие принципиально различные резоны открытия исходных кодов. > 1) Поиск уязвимостей с целью их скорейшего исправления
+1
> 2) Использование исходного кода ОС для оптимизации своего кода
Не понимаю, как. Вот "Использование исходного кода ОС для оптимизации кода этой ОС" — прекрасно понимаю.
> 3) Использование исходного кода ОС для написания программ для работы с недокументированными частями ОС.
Помоему это ты сам выдумал.
> 4) Использование исходного кода для выяснения непонятных моментов в документации.
+1
> 5) Открытие кодов с целью стимулировать "коммьюнити" исправлять баги вместо Микрософта.
Не вместо! Вместе!
Здравствуйте, pavel_turbin, Вы писали:
_>Здравствуйте, DKM_MSFT, Вы писали:
DKM>>4) Использование исходного кода для выяснения непонятных моментов в документации.
DKM>>Пункт 1 решается методом запроса исходных кодов компанией, которая занимается соответствующей деятельностью, и не требует открытия кодов для всех.
DKM>>Пункт 4 – серьезная проблема. Но, вообще говоря, пункт 4 должен быть исправлен со стороны Микрософта методом написания хорошей документации.
_>Расщитре п4 как:
_>4.1 чтение кода Windows с целью обучения и понимания как определенные модули устроены для понимания всего дизайна OS.
Полностью поддерживаю! Лично мне очень не хватало исходников msgina.dll — просто хотя бы для того, чтобы посмотреть, как надо правильно писать GINA. Ещё было бы крайне интересно узнать, как именно winlogon такие модули вызывает.
А в MSDN эти моменты освещены очень скудно.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Чтобы отечественные разработчики стали устраивать vendor lock-in? TL>>Я запутался... Еще какие слова знаешь? RO>Я очень много букв знаю!
Давай я съеду с этой демагогии. При чем тут открытые или закрытые исходники?
Еще какие слова знаешь? 
При чем тут открытые или закрытые исходники? 
