Здравствуйте, Pzz, Вы писали:

>> Pzz>C# умрет через 5 лет — именно столько живут новые технологии от
>> Microsoft.
>> Pzz>Мораль: не делайте в C# долгосрочных инвестиций.
>> Оптимист, однако. Посмотрим.
Pzz>Реалист.

Ладно, время рассудит. Надоело спорить...

Здравствуйте, BratGanjubas, Вы писали:

BG>Здравствуйте, __MasteR__, Вы писали:

__M>>Пример графического мана. Программа — konqueror. Пользователям KDE очень знакома. Просматривает и инфо. С гиперссылками (комманда ман с гипперссылками работать не умеет, но в консоли есть pinfo — он умеет). На скриншоте ман dlopen.

BG>Мда, детальность описания просто "поражает" Вот пример описания аналогичной функции из MSDN:

BG>

Где? Не вижу? А ты скролбар сбоку не видишь или не догадываешься, что на картинке долько начало?

Здравствуйте, BratGanjubas, Вы писали:

BG>Не могу, ибо конфликт с этим пунктом:

Pzz>> — состав инстяляционного пакаджа должен описываться текстовым файлом в
Pzz>>простой и понятной форме (т.е., не XML), и не требовать специальных
Pzz>>тулзов для своего редактирования

BG>"Тектовый файл в простой и понятной форме" и "не требовать специальных тулзов для своего редактирования" — что ж вы такое пишете? "Hello world"?

Хм, а в чем проблема? Различные абстракции для того и придумывались, чтобы сложное делать простым.

BratGanjubas wrote:
>
> Pzz> — скрипты должны быть по делу. Я не хочу писать скрипт, который
> Pzz>обрабатывает 2 десятка непонятных событий, ради того, чтобы сделать одно
> Pzz>нужное мне, простое действие
>
> Не могу, ибо конфликт с этим пунктом:
>
> Pzz> — состав инстяляционного пакаджа должен описываться текстовым файлом в
> Pzz>простой и понятной форме (т.е., не XML), и не требовать специальных
> Pzz>тулзов для своего редактирования
>
> "Тектовый файл в простой и понятной форме" и "не требовать специальных
> тулзов для своего редактирования" — что ж вы такое пишете? "Hello world"?

Я не понимаю, в чем конфликт.

Казалось бы, инсталлятору достаточно знать, что ставить. Т.е.,
конфигурационный файл должен содержать более-менее список
инсталлируемого софта. Например, .spec файл от RPM'а содержит список
файлов/директорий, которые надо проинсталлировать. Это простой и
понятный текстовый конфиг.

Что до скриптов, меня устроит какой-нибудь VBScript (все равно на этой
платформе ничего лучшего ждать не приходится). Но если я хочу, грубо
говоря, создать при инсталляции пару дополнительных директорий, то
скрипт и должен содержать только несколько команд, которые создают эту
пару директирой.

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

Pzz wrote:
> Казалось бы, инсталлятору достаточно знать, что ставить. Т.е.,
> конфигурационный файл должен содержать более-менее список
> инсталлируемого софта. Например, .spec файл от RPM'а содержит список
> файлов/директорий, которые надо проинсталлировать. Это простой и
> понятный текстовый конфиг.
Проблема номер 1. Как мне перебазировать RPM? То есть чтобы ставился не
в /etc, /usr/local, а (допустим) в /system?

Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
любят хардкодить пути прямо в exe-шник.

> Но если я хочу, грубо
> говоря, создать при инсталляции пару дополнительных директорий, то
> скрипт и должен содержать только несколько команд, которые создают эту
> пару директирой.
MSI-файл — это _декларативное_ описание инсталляции. MSI сам
рассчитывает зависимости (один пакет MSI может состоять из многих
компонентов), понимает перебазирование каталогов и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Cyberax wrote:
>
> Pzz wrote:
>> Казалось бы, инсталлятору достаточно знать, что ставить. Т.е.,
>> конфигурационный файл должен содержать более-менее список
>> инсталлируемого софта. Например, .spec файл от RPM'а содержит список
>> файлов/директорий, которые надо проинсталлировать. Это простой и
>> понятный текстовый конфиг.
> Проблема номер 1. Как мне перебазировать RPM? То есть чтобы ставился не
> в /etc, /usr/local, а (допустим) в /system?
>
> Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
> любят хардкодить пути прямо в exe-шник.

Ну это просто два разных подхода. В UNIX'е он заключается в том, что
каждая запчасть должна знать свое место. В Windows'е он заключается в
том, что все свалено в кучу, но адрес помойки может меняться от
инсталляции к инсталляции.

Честно говоря, Юниксовский подход мне нравится больше, но мы сейчас не о
том.

>> Но если я хочу, грубо
>> говоря, создать при инсталляции пару дополнительных директорий, то
>> скрипт и должен содержать только несколько команд, которые создают эту
>> пару директирой.
> MSI-файл — это _декларативное_ описание инсталляции. MSI сам
> рассчитывает зависимости (один пакет MSI может состоять из многих
> компонентов), понимает перебазирование каталогов и т.п.

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

Мне причем совершенно все равно, платный этот инструмент, или
бесплатный. Но если платный, то хотелось бы иметь возможность
попробовать, прежде чем покупать. Чтобы не платить за кота в мешке.

Pzz wrote:
>> Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
>> любят хардкодить пути прямо в exe-шник.
> Ну это просто два разных подхода. В UNIX'е он заключается в том, что
> каждая запчасть должна знать свое место. В Windows'е он заключается в
> том, что все свалено в кучу, но адрес помойки может меняться от
> инсталляции к инсталляции.
Зато дает больше гибкости. Например, у меня весь рабочий софт находится
на винчестере С (который зеркалируется в RAID-1). А вот всякая фигня
типа игрушек находится у меня на диске E (который не жаль, если он упадет).

>> MSI-файл — это _декларативное_ описание инсталляции. MSI сам
>> рассчитывает зависимости (один пакет MSI может состоять из многих
>> компонентов), понимает перебазирование каталогов и т.п.
> Вот, очень хорошо. А теперь дайте мне, пожалуйста, _простой_ инструмент
> для генерации этих самых MSI. Обладающий теми свойствами, которые я
> перечислил несколько писем назад.
WiX — генерирует MSI по описанию в XML (OpenSource, причем от MS). Или
InstallShield — урезаная версия идет в комплекте со Студией (есть и
evaluation-версии).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Cyberax wrote:
>
>>> Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
>>> любят хардкодить пути прямо в exe-шник.
>> Ну это просто два разных подхода. В UNIX'е он заключается в том, что
>> каждая запчасть должна знать свое место. В Windows'е он заключается в
>> том, что все свалено в кучу, но адрес помойки может меняться от
>> инсталляции к инсталляции.
> Зато дает больше гибкости. Например, у меня весь рабочий софт находится
> на винчестере С (который зеркалируется в RAID-1). А вот всякая фигня
> типа игрушек находится у меня на диске E (который не жаль, если он упадет).

За это приходится платить тем, что когда одному поинсталлированному
пакету что-то нужно от другого, то найти им друг друга бывает непросто.

Собственно, до меня только что доперло, что COM решает именно эту
проблему: как разным компонентам найти друг друга, если адрес помойки
заранее неизвестен. И, кстати, именно из-за отсутствия этой проблемы COM
не нужен в UNIX'е,

Однако с COM'ом есть свои трудности, а именно его пространство имен (не
важно, что мы называем именем — строку или GUID) не иерархично,
насколько я понимаю. И нет возможности одному пользователю иметь один
набор зарегистрированных COM'овских компонентов, а другому — другой.

>>> MSI-файл — это _декларативное_ описание инсталляции. MSI сам
>>> рассчитывает зависимости (один пакет MSI может состоять из многих
>>> компонентов), понимает перебазирование каталогов и т.п.
>> Вот, очень хорошо. А теперь дайте мне, пожалуйста, _простой_ инструмент
>> для генерации этих самых MSI. Обладающий теми свойствами, которые я
>> перечислил несколько писем назад.
> WiX — генерирует MSI по описанию в XML (OpenSource, причем от MS). Или
> InstallShield — урезаная версия идет в комплекте со Студией (есть и
> evaluation-версии).

Я специально просил без XML. Это не из-за какого-то там каприза, а
потому, что я хочу иметь возможность работать с этими описаниями не
только ручками, но и как-то автоматически. Например, если моя программа
может быть собрана в нескольких разных конфигурациях, я не хочу
поддерживать ручками несколько разных описаний инсталляции. Я бы
предпочел генерировать их автоматически из некоторого общего темплейта.

XML для такой жизни слишком плохо подходит.

Здравствуйте, Cyberax, Вы писали:

>> Казалось бы, инсталлятору достаточно знать, что ставить. Т.е.,
>> конфигурационный файл должен содержать более-менее список
>> инсталлируемого софта. Например, .spec файл от RPM'а содержит список
>> файлов/директорий, которые надо проинсталлировать. Это простой и
>> понятный текстовый конфиг.
C>Проблема номер 1. Как мне перебазировать RPM? То есть чтобы ставился не
C>в /etc, /usr/local, а (допустим) в /system?
C>Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
C>любят хардкодить пути прямо в exe-шник.

Не знаю, как rpm, но фрибизднишные порты это успешно решают. Включая захардкоденые пути. И конфиг там простой и понятный — Makefile называется. 8))

Pzz wrote:
> За это приходится платить тем, что когда одному поинсталлированному
> пакету что-то нужно от другого, то найти им друг друга бывает непросто.
А вот для этого есть реестр

> Однако с COM'ом есть свои трудности, а именно его пространство имен (не
> важно, что мы называем именем — строку или GUID) не иерархично,
> насколько я понимаю.
С GUID'ами проблем не возникает (если их не тратить зря — то хватит на
всех ), а иерархию имен можно сделать с помощью ProgID.

> И нет возможности одному пользователю иметь один
> набор зарегистрированных COM'овских компонентов, а другому — другой.
Вообще говоря, такая возможность есть. У каждого пользователя есть
HKCU/Software/Classes, куда можно заносить регистрацию объектов.

Проблема в том, что MSные тулзы (ATL/MFC/VB) по умолчанию не
поддерживают это (тяжелое наследие Win95). Нужно руками переделывать
регистрацию — поэтому оно почти и не используется.

>> WiX — генерирует MSI по описанию в XML (OpenSource, причем от MS). Или
>> InstallShield — урезаная версия идет в комплекте со Студией (есть и
>> evaluation-версии).
> Я специально просил без XML. Это не из-за какого-то там каприза, а
> потому, что я хочу иметь возможность работать с этими описаниями не
> только ручками, но и как-то автоматически. Например, если моя программа
> может быть собрана в нескольких разных конфигурациях, я не хочу
> поддерживать ручками несколько разных описаний инсталляции.
Какое совпадение — у меня это замечательно делается из JScript'а с
помощью MSXML. Причем мелкие изменения (типа увеличения номера билда)
делаются вообще в две строчки.

> Я бы предпочел генерировать их автоматически из некоторого общего темплейта.
А это я делаю с помощью XSL.

> XML для такой жизни слишком плохо подходит.
Он для этого подходит идеально. Просто инструменты немного другие.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Kemm wrote:
> C>Проблема номер 1. Как мне перебазировать RPM? То есть чтобы ставился не
> C>в /etc, /usr/local, а (допустим) в /system?
> C>Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
> C>любят хардкодить пути прямо в exe-шник.
> Не знаю, как rpm, но фрибизднишные порты это успешно решают. Включая
> захардкоденые пути. И конфиг там простой и понятный — Makefile
> называется. 8))
Ага, конечно. Помню, как-то я строил GTK под простым пользователем для
установки без админовских прав....

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> C>Проблема номер 1. Как мне перебазировать RPM? То есть чтобы ставился не
>> C>в /etc, /usr/local, а (допустим) в /system?
>> C>Ответ — никак. Особенно если учесть, что в *nix'ах до сих пор очень
>> C>любят хардкодить пути прямо в exe-шник.
>> Не знаю, как rpm, но фрибизднишные порты это успешно решают. Включая
>> захардкоденые пути. И конфиг там простой и понятный — Makefile
>> называется. 8))
C>Ага, конечно. Помню, как-то я строил GTK под простым пользователем для
C>установки без админовских прав....

А еще можно в гамаке и в лыжах. Причем при должной сноровке получится и то, и то.
Да, порты предполагают установку от пользователя, имеющего все необходимые права. А что, rpm можно не рутом поставить?

Cyberax wrote:
>
>> За это приходится платить тем, что когда одному поинсталлированному
>> пакету что-то нужно от другого, то найти им друг друга бывает непросто.
> А вот для этого есть реестр

Сам по себе реестр ничуть не лучше hardcoded путей. Кроме места
(реестра) должна быть еще и договоренность, как этим местом пользоваться.

>> Однако с COM'ом есть свои трудности, а именно его пространство имен (не
>> важно, что мы называем именем — строку или GUID) не иерархично,
>> насколько я понимаю.
> С GUID'ами проблем не возникает (если их не тратить зря — то хватит на
> всех ), а иерархию имен можно сделать с помощью ProgID.

COM'овские компоненты регистрируются глобально. А это значит:
— пользователи не могут иметь независимый набор COM'овских компонент
— нельзя одновременно иметь две разных версии одного и того же компонента
— компнент нельзя просто "позвать" из программы или скрипта. Его надо
сначала зарегистрировать. При этом если такой компонент, но другой
версии, уже имеется, то я могу испортить конфигурацию машинки. Кроме
того, если мне этот компонент нужен "на минуточку", то надо не забыть за
собой подчистить.

>> И нет возможности одному пользователю иметь один
>> набор зарегистрированных COM'овских компонентов, а другому — другой.
> Вообще говоря, такая возможность есть. У каждого пользователя есть
> HKCU/Software/Classes, куда можно заносить регистрацию объектов.
>
> Проблема в том, что MSные тулзы (ATL/MFC/VB) по умолчанию не
> поддерживают это (тяжелое наследие Win95). Нужно руками переделывать
> регистрацию — поэтому оно почти и не используется.

Вообще говоря, и RPM'ы бывают relocable, просто я забыл об этом
упомянуть. Сам я такие никогда не делал, поэтому подробностей не знаю.

>>> WiX — генерирует MSI по описанию в XML (OpenSource, причем от MS). Или
>>> InstallShield — урезаная версия идет в комплекте со Студией (есть и
>>> evaluation-версии).
>> Я специально просил без XML. Это не из-за какого-то там каприза, а
>> потому, что я хочу иметь возможность работать с этими описаниями не
>> только ручками, но и как-то автоматически. Например, если моя программа
>> может быть собрана в нескольких разных конфигурациях, я не хочу
>> поддерживать ручками несколько разных описаний инсталляции.
> Какое совпадение — у меня это замечательно делается из JScript'а с
> помощью MSXML. Причем мелкие изменения (типа увеличения номера билда)
> делаются вообще в две строчки.

Я попробовал JScript, и обломался, когда обнаружил, что вот именно на
нашей билдовой машине он и не работает. Наверное, WSH был какой-нибудь
другой версии.

Поскольку у меня за плечами была еще примерно сотня "пользователей",
которые могли самостоятельно собирать мою софтину, я как представил
себе, как я буду обучать их инсталляции WSH'а, так сразу и передумал
использовать JScript

>> Я бы предпочел генерировать их автоматически из некоторого общего
> темплейта.
> А это я делаю с помощью XSL.
>
>> XML для такой жизни слишком плохо подходит.
> Он для этого подходит идеально. Просто инструменты немного другие.

Чем хорош простой текстовый файл, это тем, что он не навязывает выбора
инструментов. Поэтому если один инструмент не подходит, можно взять
другой. Например, хочешь Перлом его обрабатывай, хочешь — тем же
JScript'ом. А можно, например, пропустить через C preprocessor, или
через M4, или через SED/AWK.

P.S. Кстати, .INF файл от нашего драйвера с 6-ю возможными
конфигурациями мы пропускали через C preprocessor

И это было _очень_ удобно.

Kemm wrote:
> Да, порты предполагают установку от пользователя, имеющего все
> необходимые права. А что, rpm можно не рутом поставить?
Нет, просто в исходниках GTK были захардкодены пути (/usr/lib и еще
что-то). Пришлось ручками править исходники — даже через Makefile не
конфигурировалось.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> Да, порты предполагают установку от пользователя, имеющего все
>> необходимые права. А что, rpm можно не рутом поставить?
C>Нет, просто в исходниках GTK были захардкодены пути (/usr/lib и еще
C>что-то). Пришлось ручками править исходники — даже через Makefile не
C>конфигурировалось.

Это либо не порты были, либо еще что. Да и нет в gtk хардкорных путей.

Pzz wrote:
>> > За это приходится платить тем, что когда одному поинсталлированному
>> > пакету что-то нужно от другого, то найти им друг друга бывает непросто.
>> А вот для этого есть реестр
> Сам по себе реестр ничуть не лучше hardcoded путей. Кроме места
> (реестра) должна быть еще и договоренность, как этим местом пользоваться.
Это все же лучше. Я бы не отказался от подобного механизма в Юниксе —
чтобы все /etc и прочие /usr можно было запихать в один каталог /system.

> COM'овские компоненты регистрируются глобально. А это значит:
Ну, во-первых, COM-объекты можно регистрировать локально для пользователя.

> — пользователи не могут иметь независимый набор COM'овских компонент
Теоретически — могут. На практике этому мешает наследие Win95.

> — нельзя одновременно иметь две разных версии одного и того же компонента
Можно. У разных версий будет разный GUID — это основное правило при
создании компонент. Приложение может использовать ProgID (версируемый
или портируемый) для нахождения нужного CLSID.

> — компнент нельзя просто "позвать" из программы или скрипта.
Можно. Хотя это требует ручной загрузки IClassFactory из dll-ки
компонента. Обычно с этим не заморачиваются, но такая возможность есть
(лично ее использовал).

> Его надо сначала зарегистрировать. При этом если такой компонент, но другой
> версии, уже имеется, то я могу испортить конфигурацию машинки.
При установке новой версии (в идеале) старая версия не трогается. Ну а в
реальной жизни ситуация как с so-шками в *nix'ах.

>> Проблема в том, что MSные тулзы (ATL/MFC/VB) по умолчанию не
>> поддерживают это (тяжелое наследие Win95). Нужно руками переделывать
>> регистрацию — поэтому оно почти и не используется.
> Вообще говоря, и RPM'ы бывают relocable, просто я забыл об этом
> упомянуть. Сам я такие никогда не делал, поэтому подробностей не знаю.
Бывают. Но в дистрибутиве RedHat'а, например, их почти нет.

> Я попробовал JScript, и обломался, когда обнаружил, что вот именно на
> нашей билдовой машине он и не работает. Наверное, WSH был какой-нибудь
> другой версии.
Может быть. У нас везде без проблем работает.

>> > XML для такой жизни слишком плохо подходит.
>> Он для этого подходит идеально. Просто инструменты немного другие.
> Чем хорош простой текстовый файл, это тем, что он не навязывает выбора
> инструментов.
XML — тоже. Я для XSLя использую инструменты из libxml'я (кодировки
менять очень удобно, например).

> Поэтому если один инструмент не подходит, можно взять
> другой. Например, хочешь Перлом его обрабатывай, хочешь — тем же
> JScript'ом. А можно, например, пропустить через C preprocessor, или
> через M4, или через SED/AWK.
Инструменты для XML есть для всего. SED/AWK тоже можно использовать —
ведь XML — это бычный файл.

> P.S. Кстати, .INF файл от нашего драйвера с 6-ю возможными
> конфигурациями мы пропускали через C preprocessor
> И это было _очень_ удобно.
Ну так делайте тоже самое с XML — это ведь тоже текст.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Pzz, Вы писали:

Pzz>Stoune wrote:
>>

Pzz>Какой может быть make, если мы говорим о мелкософте? Про GNU make
Pzz>документация как раз наличиствует.
Тогда мы говорим о nmake. В гугле будто бы были ответы в первом десятке, только детальнее смотреть не было времени.

Pzz>Как мне научиться писать такие выражение $(SXS_MANIFEST:.Manifest=)? Это
Pzz>цитата из DDK'шноко Makefile, и этот синтаксис нигде не описан.

Pzz>Насчет форума, мы про документацию говорим, или про форум? Форумы и про
Pzz>Линух существуют...
Абсолютного совершенства не существует, к сожалению.


>> Pzz>Многие вещи можно понимать по-разному.

Pzz>Вы не понимаете вопроса. Есть имена сетевых интерфейсов. Которые
Pzz>выглядят по-разному в разных вариантах Форточек. В NT они выглядят, как
Pzz>GUID в фигурных скобках.

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

Pzz>GetAdaptersInfo() возвращает эти самые GUID'ы. BindAdapterHandler
Pzz>получает то же самое, но с префиксом \Device. Вопрос, это случайное
Pzz>совпадение, или на это можно закладываться? Если на это нельзя
Pzz>закладываться, на что можно?

Вот что нашол Гуглом:

In NT4 a NDIS miniport was identified by a simple name like "EL905B".

Windows 2000 introduced NDIS 5.0 and new miniport naming conventions. NDIS adapter names on NDIS 5.0 and higher are globally-unique identifiers (GUIDs) like "{9c9770b5-cfbc-41df-be1d-510cec826190}".

А связывание одного имени с другим судя по всему делается посредством функции NdisMRegisterDevice. Более детальные данные не было времени искать. Если задача распространённая то думаю на форуме по сетям или низкоуровневому прграмированию вам ответят.



Pzz>man прошел ничуть не менее долгую эволюцию. Многие не считают MSDN
Pzz>удобным. Особенно, если речь идет не о простых поделках, а об advanced
Pzz>программировании.
Извини но я не знаю ни одного человека кто считает man удобнее и знакомых которые занимаются advanced(RT, embedded Linux) програмированием
под одну и другую систему предостаточно. Впрочем я и сам не формочки клепаю, но мой опыт не в счёт так как я большую часть времени работал с Виндой.

Pzz>Не зря же люди кроме MSDN'а столь усердно используют самплы. И кстати,
Pzz>таскают ошибки из самплов из драйвера в драйвер.
Вы предлагаете писать всё самому. По моему вероятность тогда сделать ошибку на порядки выше, а что такое ошибка в драйвере дамаю сами знаете и трудности отладки тоже должны быть вам знакомы. Обычно после некоторого периода использования ошибки стают извесны и те люди которые следят за обновлениями MSDN и DDK узнают о них.

>> Pzz> — Очень часто символ или структура описана, а на что делать #include,
>> Pzz>не сказано.
>> Внизу страницы с функцией секция
>> Requirements
>> Client: Requires Windows XP, Windows 2000 Professional, Windows NT
>> Workstation, Windows Me, Windows 98, or Windows 95.
>> Server: Requires Windows Server 2003, Windows 2000 Server, or Windows NT
>> Server.
>> Header: Declared in *Winbase.h; include Windows.h.*
>> Library: Use Kernel32.lib.

Pzz>Может быть, я был недостаточно внимателен, но я не всегда находил
Pzz>правильную ссылку на хидер/библиотеку. Иногда приходилось угадывать. И
Pzz>совершенно непонятно, правильно ли я угадал, и не будет ли проблем со
Pzz>следующей версией DDK/SDK.
У меня такой проблемы никогда не возникало и сообщений таких на форумах по ВиньАпи тоже не замечал, может проблема всё таки надумана.

>> Pzz> — Конфликты между включаемыми файлами, и способы их разрешения нигде
>> Pzz>не документированы. Попробуйте как-нибудь смехо ради подцепить
>> Pzz>ntstatus.h из user space.
У меня просто мысли не возникнет вызывать функции ядра из пользовательского кода.
>> Pzz> — Оставлять у публичной функции недокументированные параметры, это
>> хамство
>> Добавляйте ИМХО. Они вам мешают? Обычно они зарезервированы на будующие
>> нужды и не одна такая функция со временем
>> обзаводилась документацией и функциональностью.

Pzz>Если мне дали ручку, я хочу знать, что эта ручка значит. Особенно
Pzz>приятно, когда слегка объясняют, чего параметр значит, а потом говорят,
Pzz>что он must be XXX. И как это понимать?
А меня это никогда не волновало. И мне например лучше если будет неиспользованный параметр чем будет ситуация как с Файловым диалогом в 2000, там структуры разного размера и я делал первое время пока не получил новый СДК хак, ресайзил структуру для того чтобы добавить параметр который отвечал за поддержку Place Bar, но в результате в 98-ой нужно было делать проверки так как там этого параметра не было, а будь заразервировано в структуре такое место всё бы работало без дополнительных проверок. А вообще раз параметры ни на что не влияют, разве что естетически, то какая мне разница сказано не трогать их, я и не трогаю и большинству тоже безразлично.


Pzz>Я смотрел, как делают другие. Другие, например, не используют Makefile,
Pzz>а используют проекты. Эти проекты работают ужасно, если есть несколько
Pzz>билдовых конфигураций. Одна и та же информация (например, путь к
Pzz>дополнительным директориям с хидерами) дублируется ручками в разных
Pzz>конфигурациях. Даже списки файлов с исходниками приходится дублировать.
Pzz>Поэтому, изменяя что-то в проектном файле, надо обязательно пересобирать
Pzz>все конфигурации. Многие этого не делают, и поэтому одно неловкое
Pzz>движение легко приводит к тому, что project файл становится поломанным.

Pzz>Кроме того, у каждой версии Visual Studio формат project файлов свой. Не
Pzz>всегда возможно стандартизовать версию Visual Studio в масштабах
Pzz>проекта. Например, в проекте могут быть задействованы сторонние
Pzz>контракторы, которые сразу задействованы в разных проектах, с разными
Pzz>требованиями к версиям инструментов.
Что ж есть такая проблема, смотрите в сторону msbuild.
Pzz>Попробуйте как-нибудь смеху ради построить проектный файл, который
Pzz> 1) собирает компилятор с самодельного domain-specific языка (на чем вы
Pzz>его писать, кстати, будете, ведь стандартного lex/yacc для Форточек нет).
Есть Cygwin и я его использую уже 3 года, а ещё есть windows serveces for unix и UWIN и ещё комерческий только название не помню, плюс много поменьше.
Кстати у меня некоторые библиотеки написаные под старые дистрибутивы Линуха ни в одном Линухе не прокомпилировались, а в Cygwin без единой модификации.

Pzz> 2) Прогоняет через него файлы, в результате чего получаются сишники
Pzz> 3) Собирает уже основную программу, которая в частности включает в
Pzz>себя эти самые сишники.

Pzz>Теперь добавьте сюда 6 конфигураций основной программы. И я посмотрю на
Pzz>Вас, как вы будете управлять таким проектом.
Если речь идёт обо мне то — SCons, bjam. Нас голыми руками не возьмёшь


>> Pzz>Что предлагается делать, когда CD-писалка жалуется на ошибку номер
>> Pzz>столько-то?
>> Как писалка связана с операционкой?

Pzz>Операционка это не только ядро, но и софт под нее.

Что ж если дело зашло о софте, где то кидали ссылку о состоянии с разработкой OpenOffice. А вообще количество и качество софта под две операционные системы то соотношения будет разнится в несколько порядков.

Pzz>Если угодно,
Pzz>операционка, это способ жизни (и взгляд на вещи).

Согласен.

Pzz>А делать-то что? Вчера писалка работала. Сегодня не работает. Пойти и
Pzz>купить новую?

Pzz>Мне помогла замена Easy CD Writer на Nero. Т.е., железо было не
Pzz>виновато. Но замена одной программы на другую (обе, кстати, стоят
Pzz>каких-то денег), это ведь тоже не подход...

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

Pzz>Деньги за сниффер готовы платить те, кто пишет сетевые драйвера,
Pzz>протоколы и т.д. Чтобы отладить небольшую офисную сеть, должно хватать
Pzz>тех инструментов, которые стандартно поставляются вместе с ОС. Иначе
Pzz>зачем такая ОС нужна?
NetMon поставляется с сэрверной версией Винды. Мне его в большинстве случаев хватало. Некоторые через него даже отлаживают сетевые драйвера.

>> Pzz>Как Вы, например, будете разбираться с ситуацией,
>> Pzz>когда у Вас в сети по ошибке завелись два DHCP-сервера, ничего не
>> Pzz>знающих друг про друга, и конфликтующих между собой?
>> Я в такой ситуациии разобрался штатными средствами Винды. Только вторым
>> DHCP оказалось неправильно работающее домашнее подключение к интернету.

Pzz>Квалифицированный человек может разобраться с этим голыми руками. Как
Pzz>объяснить, что делать, неквалифицированному?
Ну вообще такие вещи делает как раз квалифицырованный админ и неважно в какой системе, или вы хотите сказать что DHCP в Линухе может уже и домокухарка? .

>> Pzz>Как починить файловую систему, если OS с нее не грузится? Линух в таком
>> Pzz>случае можно загрузить с флопика или CD.
>> Очень много средств, но опять же они стоят денег. ERD Commander например.

Pzz>Разве средства элементарного восстановления не должны входить в состав
Pzz>системы?
Есть ещё System Restore в ХР и Консоль востановления, они и входят в состав системы.
Мои любимые конамнды fixboot и fixmbr для прибивания загрузчика Линуха после неудачного експеримента


Pzz>Не хватает, это значит, что какие-то особенности конфигурации конкретно
Pzz>моей системы не совпадают с тем, что ожидали авторы программы. Например,
Pzz>не хватает каких-нибудь прав, чего-нибудь в реестре неожиданное
Pzz>написано, или какая-нибудь DLL'ка не той версии.
А разве вы под Линух не так же пишете? Програма для работы должна иметь какие-то права, если вы как дивелопер сидите под админом то вы не вправе рассчитывать что пользователь будет делать то же и вообще я ненавижу криворуких разаработчиков которые для плёвых програм необосновано хотят прав админа или не учитывают что на одном копютере может быть несколько пользователей и все настройки хранят в одном файле и ещё часто в Program Files. Нужные хаписи в рееестре создаются/проверяются инсталятором, также как и DLL.

Pzz>Далеко не все программы способны внятно объяснить, что им нужно. В
Pzz>Линухе, по крайней мере, можно взять strace, и посмотреть, куда програма
Pzz>лазает. Что делать в таком случае в Форточках? Переставлять всю систему?

FileMon, RegMon, Process Explorer(www.sysinternals.com)


Pzz>Назовите мне такую книгу. Все, которые я до сих пор видел, не стоили
Pzz>того, чтобы их читать.
Ну если по устройству Винды то смотрите ниже, а для програмирования Рихтер. По администрирования не знаю что постоветовать, я учился в своё время на своих ошибках, одной книги не назову, а сейчас пользуюсь в сновном разными справочниками.

Pzz>Кстати, мне больше интересно не администрирование, а программирование.
Pzz>Назовите мне хоть одну виндовсную книгу такого же класса, как "The
Pzz>Design and Implementation of the 4.4 BSD Operating System", McKusick'а и
Pzz>др. Я ее с удовольствием прочту...

Если вам так хочется понять как устроена Винда внутри есть чудесная книжка Марка Руссиновича "Microsoft Windows Internals 4-Ed".

Здравствуйте, O-Sam, Вы писали:

S>>>>Сходите на местную линуксовку, проагитируйте разбирающегося студента насчет поработать.
OS>>>Я подозреваю, что это должен быть студент-заочник, потому что первые полгода точно ему придётся решать 8 часов в неделю вопросы, возникающие у пользователей, привыкших к винде. Много вы видели разбирающихся студентов-заочников?
S>>Зачастую чаще вижу хорошо разбирающегося студента чем разбирающегося админа средней руки, тем более чем разбирающегося препода.
S>>Вдобаваок студент это такой зверь что обучается быстро.
OS>Возможно, но мне всё равно кажется что привлекать к управлению, пусть и небольшой, но ИТ-инфраструктурой студента немного рисковано. Мало ли что — проблемы с преподавателями, сессией...

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

OS>>>Так вот в том то и дело что gimp — "вполне себе порисовать" в домашних условиях.
S>>Приму на веру.
S>>Но всетаки хотелось бы узнать чем же гимп не?
OS>Уже не помню, но где-то года полтора назад, когда я экспериментировал с Линуксом (пробовал дома под ним жить) gimp мне показался сильно уступающим по функционалу.
Чесно говоря не видел ни одного професионального дизайнера или художника работающего с gimp. Я не спорю обучить то его можно, но вот только професионал вас пошлёт подальше и уйдёт в контору где ему не будут ставить такие условия. Я уже молчу что для полиграфии например нужна ещё куча софта , который фотошоповские форматы принимает без проблем

Здравствуйте, Stepkh, Вы писали:

S>Здравствуйте, O-Sam, Вы писали:

OS>>>>Так вот в том то и дело что gimp — "вполне себе порисовать" в домашних условиях.
S>>>Приму на веру.
S>>>Но всетаки хотелось бы узнать чем же гимп не?
OS>>Уже не помню, но где-то года полтора назад, когда я экспериментировал с Линуксом (пробовал дома под ним жить) gimp мне показался сильно уступающим по функционалу.

S>А можно мне задать вопрос: Фоошоп — это единственная программа для рисования?? как и автокад единственныйй и не повторимый КАД для всех?

S>Что-то терзает меня смутное сомнение, что это далеко не так..
S>В году этак в 98/99 попалась мне статья про какой-то крутой фильм из Голливуда: мол как там все круто визуализировано и т.д. и т.п.
S>Так вот там прозвучала очень интересная фраза: "поскольку операционка слабая как и железо под нее (НТ 4.0), то и софт был выбран соответвующий... не очень мол.." И дальше прозвучала просто фантастическая сумма: 100К у.е. на одно рабочее место. Причем произвоитель этого софта — какая-то английская контора.

Для тех компаний которые готовы отвалить такие сумы за рабочее место поверте стоимость операционки не имеет значения. Очень часто для таких систем нужна специальная процесорная архитектура и Microsoft изза малого количества инсталяций не будет для неё портировать операционку. Мне вот только интресно как єто соотносится с нуждами масового рынка?

S>К чему все это? Просто не единым фотошопом жив человек как и автокадом...
S>Кстати, автокад — это кадовская система очень и очень начального уровня. Есть там системы и помощнее и подороже.. и работают они не тольок под виндой.
Да только люди привыкли работать под виндой и переобучение конструктора для работы под линухом очень часто подороже стоимости лицензионной винды. А о CAD-ах мой завод полгода назад купил 10 лицензий для AutoCAD LT и для него его возможностей в самый раз. 40-50-летнего конструктора с 20-30 летним стажем и работе в винде обучить не так то просто, а о линухе можно молчать, а раскидыватся человеческим материалом никто не будет, потому как люди с таким опытом на вес золота, они на кульмане за день могут создать больше и качественнее чем молодёжь за месяц в AutoCAD, CATIE или ProIngineeer.

Здравствуйте, Stepkh, Вы писали:

S>Здравствуйте, O-Sam, Вы писали:


S>В том-то и беда, что наши студенты не знают ничего (а также и преподаватели) что может быть отличного от Windows и программ для него (неё).
Ну о том что студенты ничего не знают, это для меня не новость, только вот вина от этого лежит на 90% на студентах и их родителях, они не знают потому что не хотят ничего знать и дай им Линукс котрый 90% из них точно в последующей жизни они не будут использовать от этого ничего не изменится, а Виндой и софтом для неё пользоватся так или иначе будут все и не дать знания о них как раз будет плохо. А Линух те кому надо и кто имеет голову подучат сами, если же специальнсть обязывает знать Линут то у нас по крайней мере их дают, другое дело что большинству студентов на это наплевать, они прищли не чтобы учится, а чтоб получить диплом.
S>Так что насчте стандарта де-факто... это как вам сказать- на какой, простите, территории?

CATIE, ProInginneer не катит? Знают, только лицензия на одно рабочее место стоит очень немало. Таких организаций которым нужны такие мощные CAD-ы не всем нужны.
S>Как dBase СР 866 — стандарт для подачи формы 8ДР на территории Украины?

Вы будете удивлены но 1С по умолчанию этот формат и использует.
OS>>(я не говорю что под линух нет нормальных сред разработки ПО, просто пытаюсь передать ощущения рисовальщика, который после Photoshop CS2 садится на gimp)

S>Давайте разберем по порядку что такое Гимп, Фотошоп, КАД и т.д. Это сугубо узко специализированные программы. Все(!) их возможности нужны очень узкому кругу лиц. Согласитесь, покупать Фотошоп и кричать на каждом углу что он кул,а гимп отстой, только потому что я смог в нем отсканированую печать со студенческого билета реанимировань и сотярпать левый студентческий (был такой случай , согласитесь- ну очень узкое применение. Лично я — ни разу в жизни не пользовался Фотошопом (пример выше был не со мной). Сейчас потихоньку использую Гимп и то, только для того чтобы отмасшатибировать да откадрировать картинку — и все. 80% пользоваетлей делают то же самое. А то что умеет эта программа для 80% — с головой. Остальные 20% — милости просим в мир платного ПО.
Только в Украине за прошлый год продано более милиона цифровых камер, каждый её владелец сталкивается время от времени с потребностью редактирования фото и Adobe Photoshop Elements как нельзя кстати для таких нужд, а сколько людей возпользуестя gimp даже имея выбор? Я отвечу это будет очень малый процент, в худшем случае выберут продукт от Jasc, Corel, Ulead, тот же IrfanView, ACDSee, Picassa , а gimp бует стоять в конце очень длинной очереди.

S>Я не агитирую, что Фотошоп или Гимп рулез/отстой — я просто хочу сказать, что очень многое зависит от узкого кругозора наших специалистов/пользователей... Как я в свое время "прозрел" — ХИРЭ, л/р по предмету а-ля ВМКСС — тема л/р использование МС Ворд... В л/р главое было как рисовать таблицы... Вопрос: а какого хрена мне покупать(!) этот офис и писать такую л/б если послезавтра выйдет новая версия ПО или контора разорится? Почему не ТеХ, к примеру? Да потому что эти горе-преподаватели даже не слышали об этом.
Знаете прежде чем хаять своих преподавателей нужно самому чего-нибуть добится в жизни. MS Word стандарт де-факто и де-юре и тот же OpenOffice организации выбирают по критерию совместимости с продуктами МС. Вы решение о покупки офиса на организации не будете, а будет принимать руководитель, который посчитает что ему дешевле, купить лиц. офис, или тот же MS Works и посадить на него девочек после техникума с небольшой зарпалатой или нанять людей которые будут разбиратся в Линухе, но которым и платить придётся соответственно. Вы предпочитаете чтоб вас учили ТеХ? А после окончания ваши познания в ТеХе будут похороненны, потому что спектр применения этой системы минимален даже в сфере издания книг.

S>Попросите тех специалистов, что используют АвтоКАД, сказать: а какие вы мол знаете недостатки и слышали вы про аналогичные системы? 80% ( опять это 80/20) удивленно пожмут плечами и спросят: а разве что-нибудь еще есть?
КБ Антонова до недавнего времени использовало AutoCAD , и позволить они могли и серйозней системы, только если он решает их задачи зачем платить больше. А вы спрашиваете не у тех специалистов, если будет потребность у меня на заводе есть как минимум 3 конструткора которые смогут работать с ProInginneer, только догадайтесь на какой операционке? её название не будет начинатся на Л.

S>А если уж подходить к теме платного ПО, то многие конторы даже не знают что надо платить!
Это не значит что со временем не заплатят.
S>П.С. Сам в последний раз держал в руках (в смысле чертежи делал) Автокад версии 10.0

S>П.П.С.
S>Eclipse не устроит отца русской демократии как среда? KDeveloper мне тоже хватает
KDeveloper — по сравнению с VS дешовая поделка. Eclipse уже получше но лично мне VS на порядок удобнее, єдинственное чего не хватает єто рефаккторинга, который в 2005 появился.