Сообщений в теме: 199

[GrayFox]

2 Zulkar

Так, по поводу реестра.

Реестр, накапливая в себе ключи, как рабочие и так и уже не используемые, замедляет работу системы.
Не очень сильно, но всё таки.

Предоставите результаты тестов, опровергающие это, я признаю что был не прав.

Я не буду отвечать на пост о правах пользователей на установку ПО.
Это зависит от настроек аккаунта, захотел админ - т ыставишь ПО, не захотел ...

Я даже не буду вступать в полемику, по поводу

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

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

Нет конечно. Если ваши прога находится в папке C:\Program Files\SuperPortableProga то туда должна быть разрешена запись пользователю, который с ней будет работать. Вы считаете это нормально, давать гостю (всякие ситуации бывают) права на запись туда?

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


Теперь далее.

Однако и не в /usr/share/program_name, согласитесь? О чем и речь. Пишите конфиги хотя бы в %HOMEPATH%

Ну, в POSIX системах - хомяк предусмотрен изначально.
А куда ведёт %HOMEPATH% в Windows 9x?

Теперь далее, в одной организации, c WinXP на машинах,
переменная %HOMEPATH% ссылается на C:\. и поскольку
фирма большая, обросшая политиками и т.д.
Доводы: Куда? И какого?! никого не волнуют.

У вас как я понимаю, все пользователи под администраторами сидят?

У нас пользователи, весь бесправные существа, но доступ на запись в файл конфига
спец софта - они имеют.

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

Сразу - точки над ять.
FAR я написал по ошибке, и уже исправился. FAR вар он в реестре прописывается.

Если пользоваетль запускает софт установленный им самим, у него есть право записи для конфигов.
Ясли пользователь запускает софт, установленный админом, не имея право писать в каталог, то :
Админ ===разгон===> Стена

Что касается записи в корень винды под админом, то сам себе зелёный буратино.
Нужно права на папку дать, а не запускать всё подряд от Администратора.

Какие конкретно настройки хранятся в конфигах? Конкретно назовите файлы.

Выбран методом тыка - C:\WINDOWS\inf\lhtsc.inf

-----------------------------

Есть он может писать в конфиги в корне, с большой вероятностью он может писать и в другие файлы в корне (я исключаю вариант с ACL-ями на нужные файлы, как маловероятный). Значит любая уязвимость в софте, позволяющая выполнить произвольный код под его правами компроментирует всю систему.

Мой друг, Если администратор криворук, то пользователь может иметь права не только на корень,
но и на папку системы, что не только "скомпрометирует" её, но и ускорит кончину.

-----------------------------

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

Резюмирую. Реестр нужен, но именно как реестр, что установлено и куда.
Но не пихать в него всё подряд, пихать в него всё и вся....

З.Ы. Мир, братья

[Zulkar]

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
2 Zulkar
Так, по поводу реестра.
Реестр, накапливая в себе ключи, как рабочие и так и уже не используемые, замедляет работу системы.
Не очень сильно, но всё таки.
Предоставите результаты тестов, опровергающие это, я признаю что был не прав.
[/quote]
Ок. На выходных буду занят, на следующей неделе напишу прогу, которая запишет всякую херню в реестр (только в ветвь HKCU/Software естественно). Запишу туда 2000 настроек - ну куда уж больше, верно?
Давайте вместе определимся, по каким критериям определять скорость работы системы.
Приглашаю всех к обсуждению и правилам эксперимента.

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Я не буду отвечать на пост о правах пользователей на установку ПО.
Это зависит от настроек аккаунта, захотел админ - т ыставишь ПО, не захотел ...
Я даже не буду вступать в полемику, по поводу
[quote]По вашему, вордом обычный юзер не должен пользоваться, раз не имеет прав на его установку?[/quote]
Хотя тут явно нарушение булевой логики.
Ведь согласитесь,
может устанавливать и пользоваться установленным
не противоречит и не исключает:
может пользоваться установленным другим пользователем при соответсвующих правах доступа.
[/quote]
Естественно, пользоваться можно при грамотно настроенном ACL. Если у меня 50 программ, каждая из которых хранит настройки в ini у себя в корне мне надо на все ACL давать? А как мне узнать на какие файлы разрешение на запись необходимо? А когда эти программы проапгрейдятся? Снова?
Кстати, вы часто грамотно настроенный ACL видели? - я ни разу. Даже у меня нету , хотя я и понимаю необходимость. Мне просто лень.

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Мама дорогая, вы меня щас ещё в захвате Грузии обвините.
Можно на машину и Администратора без пароля сделать, случаи то они всякие бывают.
[/quote]
При чем тут Грузия? А вы кстати за кого?


Можно машину на паблик с открытым админом поставить, конечно. Вопрос стоял не в этом. А в том, что если я захочу максимально разграничить права пользователей - с програмами на ini файлах у меня это не получится. Или будет геморно. А если на машине несколько пользователей? Как сделать, чтобы их настройки не интерферировали между собой?


[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Ну, в POSIX системах - хомяк предусмотрен изначально.
[/quote]
Изначально, не изначально... Какая разница, главное он щас есть и в винде.
[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
А куда ведёт %HOMEPATH% в Windows 9x?
[/quote]
А фиг его знает. Когда я работал с Win9x я таких слов еще не знал Какая разница, Win9x уже умер давно. Вы бы еще 3.1 вспомнили.

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Теперь далее, в одной организации, c WinXP на машинах,
переменная %HOMEPATH% ссылается на C:\. и поскольку
фирма большая, обросшая политиками и т.д.
Доводы: Куда? И какого?! никого не волнуют.
[/quote]
На этом основании, как я понял, вы утверждаете что разруливать безопасность не надо?

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Если пользоваетль запускает софт установленный им самим, у него есть право записи для конфигов.
Ясли пользователь запускает софт, установленный админом, не имея право писать в каталог, то :
Админ ===разгон===> Стена
Что касается записи в корень винды под админом, то сам себе зелёный буратино.
Нужно права на папку дать, а не запускать всё подряд от Администратора.
[/quote]
То есть надо делать чтобы админ сидел, и на каждую прогу методом тыка, после установки, изучал, на какие файлы и папки надо дать разрешение 666? В документациях такого редко встречается. Да и время, время. То есть все должно настраиваться долго и мучительно, да?
[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Выбран методом тыка - C:\WINDOWS\inf\lhtsc.inf
[/quote]
У меня такого файла нет, следовательно я заключаю, что это не стандартный файл винды. Да и вообще, папка inf с драйверами немного связана. Я не уверен, но думаю что некоторые из них могут запускаться еще до загрузки библиотек, обеспечивающих WinApi. А через NativeApi с реестром работать еще то удовольствие



[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Если администратор криворук, то пользователь может иметь права не только на корень,
но и на папку системы, что не только "скомпрометирует" её, но и ускорит кончину.
[/quote]
Ага. Вы уже указывали вроде что с таким админом надо делать?

[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
Единственная вещь, когда без реестра не обойтись, это когда нужно из одной программы,
узнать где находиться другая программа. Например, инсталлятор патча должен знать где
находиться приложение. Ведь иначе ему придётся спрашивать пользователя - Где?!
А пользователь этого не любит.
Резюмирую. Реестр нужен, но именно как реестр, что установлено и куда.
Но не пихать в него всё подряд, пихать в него всё и вся....
[/quote]
У Майкрософта другое мнение. Я им верю больше почему-то в технических вопросах
[quote name='GrayFox' post='6318740' date='15.08.2008, 11:00']
З.Ы. Мир, братья
[/quote]
Дружба, сосиска!!!

Конечно мир, коллега.

PS: GrayFox - Проблема не в том, что админ может настроить систему криво и дать гостю права на все. Это вообще от ОС и набора программ не зависит. Как говориться, защиту от дурака придумали уже давно, а защиту от дол***ба еще нет. Проблема в том, что при желании настроить систему хорошо - с программами пишущими в ini файлы к себе, придется мучится гораздо дольше, чем с теми, которые пишут в реестр, или хотя бы в %HOMEPATH% А некоторые проблемы решить так и не удастся. Опять таки, разные юзеры могут хотеть разные настройки....

[Visual1]

Мир, братья

Полностью одобряю и поддерживаю этот призыв. Мне тоже думается, так ли уж необходимо всегда и все хранить в реестре? Если какому-нибудь юзеру хочется, чтобы цвет диалогового окошка был, например, желтым, а размер фонта был, ну допустим, 50 то Microsoft вовсе не навязывает программисту реестр (с которым программисту, кстати, работать совсем нетрудно) в качестве единственного и исключительного средства для решения этой задачи.

Современная платформа .NET также сохранила этот гибкий подход. Программист по-прежнему имеет удобные возможности для работы с реестром, но вообще-то сами сборки (компоновочные модули) .NET в реестре больше не нуждаются. Они являются самодокументируемыми, поскольку хранят внутри себя (а не в реестре) метаданные обо всех используемых в программе типах и ссылках на внешние библиотеки. Среда выполнения .NET не использует реестр при поиске сборок. Можно переместить сборки (которые внешне выглядят как файлы .exe и/или .dll) в другое место на своей машине и так же успешно запустить приложение.

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

[Zulkar]

Итак, коллеги, проведем опыт, как настройки помещенные в реестр влияют на производительность винды?
Я остановился только перед тем, как мерить эту самую производительность. Давайте подумаем вместе.

PS: Visual1 - что с вами? Такое ощущение что читаю рекламный проспект Майкрософта
Вот это не понял

Они являются самодокументируемыми, поскольку хранят внутри себя (а не в реестре) метаданные обо всех используемых в программе типах и ссылках на внешние библиотеки.

А до этого как было?
А вообще в стиле Майкрософта - выдать давно уже известное всему миру, за только что разработанное ими.

[v04bvs]

Я остановился только перед тем, как мерить эту самую производительность. Давайте подумаем вместе.

Ну очевидно, следует проверить производительность API реестра, а именно поиск и чтение. Например в тесте обходим весь реестр и читаем каждый его ключ. Потом прибавляем 100000 ключей в разные места (или в одно) и повторяем ещё раз, и сравниваем (с учётом того, что во второй раз читалось на 100000 ключей больше).

[Visual1]

Visual1 - что с вами? Такое ощущение что читаю рекламный проспект Майкрософта
Вот это не понял

Они являются самодокументируемыми, поскольку хранят внутри себя (а не в реестре) метаданные обо всех используемых в программе типах и ссылках на внешние библиотеки.

Со мной все в порядке, не волнуйтесь. Вас, как я понял, не устраивает "рекламный проспект Майкрософта"? Хочется больше технических подробностей? Нет проблем - создайте в Visual Studio .NET простой проект, например, консольное приложение, и загляните в скомпилированный исполняемый модуль с помощью утилиты ildasm.exe. Вы увидите, что сборки .NET действительно не нуждаются в реестре. Это потому, что в сборку с управляемым кодом компилятор встраивает метаданные типов, которые описывают все типы, определенные в скомпилированном объекте, и все члены каждого типа. Таблицы метаданных (metadata) обязательно генерируются каждым компилятором, предназначенным для CLR (Common Language Runtime). В метаданных этого модуля также есть таблицы, указывающие, на что ссылается управляемый модуль - например, на импортируемые типы и их члены. Модули сборки также содержат сведения о других сборках, на которые они ссылаются. Это делает сборку самоописываемой (self-describing), и CLR "знает" о сборке все, что нужно для ее выполнения. Поэтому не требуется размещать никакой дополнительной информации в реестре.

А до этого как было?

(Вы не зря изобразили рядом со своим вопросом этот смайлик, икающий от удивления.) Да много уже было всякого, всего и не расскажешь сразу. Но в контексте обсуждаемой темы наиболее важно, что архитектура и технология COM была предыдущей основой разработки Windows и приложений для нее - кстати, довольно успешной. Windows XP полностью построена на ее основе. Именно модель СОМ в наибольшей, даже в исключительной, степени требует использовать реестр, поскольку это необходимо для взаимодействия приложений (как совершенно правильно указал GrayFox в своем сообщении), а не сами по себе вопросы централизованного и упорядоченного хранения конфигурационных данных и быстродействия их обработки (хотя конечно, это тоже имело значение в пользу перехода к реестру).

А вообще в стиле Майкрософта - выдать давно уже известное всему миру, за только что разработанное ими.

Ну нет, это уже оффтопик и флуд, мне лично неинтересный. Без комментариев.

Сообщение отредактировал Visual1: 19.08.2008, 23:14:41

[Zulkar]

Visual1 - не хотел вас обидеть. Просто замечу, что для тех же библиотек на С++/Delfi/Много Чего Еще так же реестр не требуется. Библиотека или программа на плюсах так же хранит в себе всю инфу о типах и прочее. Можно просмотреть с помощью Dependency Wlaker например. Именно поэтому я и начал флудить

[dzid]

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
2 Zulkar

Так, по поводу реестра.

Реестр, накапливая в себе ключи, как рабочие и так и уже не используемые, замедляет работу системы.
Не очень сильно, но всё таки.
[/quote]
Определитесь, время выполнения каких функций будем сравнивать.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
Предоставите результаты тестов, опровергающие это, я признаю что был не прав.

Я не буду отвечать на пост о правах пользователей на установку ПО.
Это зависит от настроек аккаунта, захотел админ - т ыставишь ПО, не захотел ...
[/quote]
Я надеюсь, что уважаемый дон в курсе, что право на установку ПО != право записи в Program Files? На висте даже безо всяких извращений так.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
Я даже не буду вступать в полемику, по поводу
[quote]По вашему, вордом обычный юзер не должен пользоваться, раз не имеет прав на его установку?[/quote]
Хотя тут явно нарушение булевой логики.
Ведь согласитесь,
может устанавливать и пользоваться установленным
не противоречит и не исключает:
может пользоваться установленным другим пользователем при соответсвующих правах доступа.
[/quote]
И если эта программа не хочет писать туда, где лежат ее исполняемые модули...

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
...skip...
[quote]Однако и не в /usr/share/program_name, согласитесь? О чем и речь. Пишите конфиги хотя бы в %HOMEPATH%[/quote]

Ну, в POSIX системах - хомяк предусмотрен изначально.
А куда ведёт %HOMEPATH% в Windows 9x?
[/quote]
А что, на ней еще что-то работает???

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
Теперь далее, в одной организации, c WinXP на машинах,
переменная %HOMEPATH% ссылается на C:\. и поскольку
фирма большая, обросшая политиками и т.д.
Доводы: Куда? И какого?! никого не волнуют.
[/quote]
Проблемы больных на голову юзверей нормальных software developer'ов не волнуют. Да и вообще - не храните настройки в файлах. Лучше дайте пользователю инструмент для сохранения/восстановления настроек (как это сделано в том-же фаре).

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
[quote]У вас как я понимаю, все пользователи под администраторами сидят?[/quote]
У нас пользователи, весь бесправные существа, но доступ на запись в файл конфига
спец софта - они имеют.
[/quote]
Блин, если наш админ будет раздавать права на запись каждому спец. софту, он больше ничего не успеет сделать. Поэтому спец. софт покупается от пряморуких производителей, где все из коробки работает.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
...skip...
Если пользоваетль запускает софт установленный им самим, у него есть право записи для конфигов.
[/quote]
Не факт, далеко не факт.
[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
Ясли пользователь запускает софт, установленный админом, не имея право писать в каталог, то :
Админ ===разгон===> Стена
[/quote]
Админ тут ни при чем, а вот автору софта нужно и в самом деле как следует разогнаться...

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
...skip...
[quote]Какие конкретно настройки хранятся в конфигах? Конкретно назовите файлы.[/quote]
Выбран методом тыка - C:\WINDOWS\inf\lhtsc.inf
[/quote]
Уважаемый дон в курсе, что данный файл - ничто иное, как описание для установки драйверов? Если нет - рекомендую осилить MSDN, прежде чем нести тут чушь.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
...skip...
Мой друг, Если администратор криворук, то пользователь может иметь права не только на корень,
но и на папку системы, что не только "скомпрометирует" её, но и ускорит кончину.
[/quote]
Друг мой, если программа требует каких-то особых разрешений на нее, то она отправляется в помойку, а ее автор идет собирать бутылки. ACL придумали для раздавания разрешений к ДАННЫМ, а не для введения исключений в системную политику. Просто кладите вещи туда, куда рекомендует производитель системы, и ваши волосы будут шелковистыми, а на куске хлеба - масло.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
Единственная вещь, когда без реестра не обойтись, это когда нужно из одной программы,
узнать где находиться другая программа. Например, инсталлятор патча должен знать где
находиться приложение. Ведь иначе ему придётся спрашивать пользователя - Где?!
А пользователь этого не любит.

Резюмирую. Реестр нужен, но именно как реестр, что установлено и куда.
Но не пихать в него всё подряд, пихать в него всё и вся....
[/quote]
Конечно, все и вся не надо. Машиннозависимые настройки программы - в HKLM, настройки юзера - в HKCU, свойства документа - соответственно в документ.

[quote name='GrayFox' date='15.08.2008, 11:00' post='6318740']
З.Ы. Мир, братья
[/quote]
Мы мирные люди, но наш бронепоезд...

[Visual1]

Просто замечу, что для тех же библиотек на С++/Delfi/Много Чего Еще так же реестр не требуется. Библиотека или программа на плюсах так же хранит в себе всю инфу о типах и прочее.

Да, такое возможно, но только если эти библиотеки не являются компонентами COM. В таком случае, обновленные версии этих библиотек (скомпилированные в автономные файлы .dll) можно просто повторно распространять заново, и незачем беспокоиться об их регистрации в реестре. Замечательно, не правда, ли? (насчет конфликта версий говорить не будем - он присущ также и компонентам СОМ). А как насчет независимости от языка? Может ли такая .dll, скомпилированная, например, из исходного кода на С, и несовместимая с СОМ, использоваться клиентской программой из другого языка программирования, например, Delphi? То-то же. Так что не путайте божий дар с яичницей возможности управляемого кода .NET с возможностями традиционных библиотек .dll

[Zulkar]

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

Visual1

Да, такое возможно, но только если эти библиотеки не являются компонентами COM.

Но согласитесь, от того под .NET этот код идет или native, это никак не зависит?

А как насчет независимости от языка? Может ли такая .dll, скомпилированная, например, из исходного кода на С, и несовместимая с СОМ, использоваться клиентской программой из другого языка программирования,

На дельфи не знаю, но думаю может. Что-то типа extern "C" там наверняка есть.
Я только недавно начал C# учить, не уверен, но было что-то в книге Троелсена, что некоторые фичи, которые можно написать на шарпе, не будут доступны при вызове из VB. Так что и в .NET не все шоколадно.

так что не путайте божий дар с яичницей возможности управляемого кода .NET с возможностями традиционных библиотек .dll

Просто я не вижу, касательно того, о чем идет речь, никаких преимуществ managed кода вообще и платформы .NET в частности, перед native кодом.

[v04bvs]

Да, такое возможно, но только если эти библиотеки не являются компонентами COM.

Можно и COM-ы без реестра грузить. Это просто dll-ка с определёнными соглашениями, не более. Реестр просто удобен в качестве центрального места регистрации COM-объектов.
Кстати C:\WINDOWS\WinSxS не аналог?

А как насчет независимости от языка? Может ли такая .dll, скомпилированная, например, из исходного кода на С, и несовместимая с СОМ, использоваться клиентской программой из другого языка программирования, например, Delphi?

Легко. Практически любой адекватный язык (даже платформа .NET) может вызывать C-шные функции.

То-то же. Так что не путайте божий дар с яичницей возможности управляемого кода .NET с возможностями традиционных библиотек .dll

[Visual1]

Можно и COM-ы без реестра грузить. Это просто dll-ка с определёнными соглашениями, не более. Реестр просто удобен в качестве центрального места регистрации COM-объектов.

В Windows, чтобы обеспечить обнаружение и загрузку COM-сервера в память во время выполнения программы, имеется специальный менеджер управления сервисом SCM (Service Control Manager), который всегда обращается к реестру. Поэтому я очень сомневаюсь в возможности того, что вы утверждаете. Ну разве что если програмист создает его с применением каких-то очень специальных мер.

Кстати C:\WINDOWS\WinSxS не аналог?

Не знаю.

А как насчет независимости от языка? Может ли такая .dll, скомпилированная, например, из исходного кода на С, и несовместимая с СОМ, использоваться клиентской программой из другого языка программирования, например, Delphi?

Легко. Практически любой адекватный язык (даже платформа .NET) может вызывать C-шные функции.

Вы либо говорите о чем-то другом (наверное, о вызове функций С-шных функций Win32 API при помощи оберток, имеющихся во многих современных языках?), либо серьезно заблуждаетесь. Простые "самодельные" DLL зависят от конкретного языка програмирования. Клиенты, использующие экспортируемые функции таких DLL, должны быть написаны на том же самом языке, что и используемая ими DLL.

P.S. (Уточняющее добавление): Под "простой самодельной" DLL я подразумеваю DLL, написанную на любом языке, даже самом мощном, например, С++, но с использованием только лишь ключевых слов этого языка (например, class, interface и struct). К ней можно будет обращаться только из программ, также написанных на С++. Это ограничение было преодолено в СОМ с появлением универсальных типов данных IDL. А в .NET эта проблема решена еще лучше.

Сообщение отредактировал Visual1: 20.08.2008, 14:05:17

[Borg]

>> Visual1

Среда выполнения .NET не использует реестр при поиске сборок. Можно переместить сборки (которые внешне выглядят как файлы .exe и/или .dll) в другое место на своей машине и так же успешно запустить приложение.

Да дела %). Хотел бы я на это посмотреть в живую. К сожалению сколько на .NET програмлю такого, позвольте "бреда" про него не слышал.

Вы наверное перепутали GAC и сам механизм поиска ДЛЛ по которому ищет .NET необходимые ДЛЛ. Но даже там просто так закинуть ДЛЛ в любую папку нельзя только по тем путям которые у него зарегистрированы в окружении. Кстати эти пути храняться в реестре, да и вообще много чего у .NET хранится в реестре!

[Zulkar]

Вы либо говорите о чем-то другом (наверное, о вызове функций С-шных функций Win32 API при помощи оберток, имеющихся во многих современных языках?), либо серьезно заблуждаетесь.

И как же по вашему написаны эти самые обертки?

Простые "самодельные" DLL зависят от конкретного языка програмирования. Клиенты, использующие экспортируемые функции таких DLL, должны быть написаны на том же самом языке, что и используемая ими DLL.

Ничего подобного. Касательно Delphi - поищите в справке для чего нужны такие ключевые слова как external и cdecl. В С++ есть такое слово как extern. Тоже посмотрите для чего оно нужно. Еще погуглите например по ключевым словам вызов dll из delphi

А dll, кроме всего прочего предназначена для смеси различных языков в одном проекте.

Сообщение отредактировал Zulkar: 20.08.2008, 14:00:07

[Borg]

>> Visual1

Опять глупость написали:

ДЛЛ не зависят от языка они с любого языка компилируются в PE файл (кроме управляемых языков), иначе бы любой новый язык програмирования не смог бы запускаться на старой системе где нет необходимого окружения для него.

[v04bvs]

В Windows, чтобы обеспечить обнаружение и загрузку COM-сервера в память во время выполнения программы, имеется специальный менеджер управления сервисом SCM (Service Control Manager),

Service Control Manager относится к службам Windows (аналог демонов UNIXа) и к COM-серверам прямого отношения не имеет.

Вы либо говорите о чем-то другом (наверное, о вызове функций С-шных функций Win32 API при помощи оберток, имеющихся во многих современных языках?), либо серьезно заблуждаетесь. Простые "самодельные" DLL зависят от конкретного языка програмирования. Клиенты, использующие экспортируемые функции таких DLL, должны быть написаны на том же самом языке, что и используемая ими DLL.

Нет. Я использовал в C DLL-ки на Дельфи и наоборот. Всё прекрасно работало. Ключевое понятие - соглашение по вызовам функий.

Сообщение отредактировал v04bvs: 20.08.2008, 14:23:55

[Visual1]

>> Visual1

Опять глупость написали:

ДЛЛ не зависят от языка они с любого языка компилируются в PE файл (кроме управляемых языков), иначе бы любой новый язык програмирования не смог бы запускаться на старой системе где нет необходимого окружения для него.

Borg: сначала научитесь читать, и без ошибки находить, кто это на самом деле написал, прежде чем постить свои оскорбления.

Zulkar и v04bvs: отвечу позже.

[dzid]

Да, такое возможно, но только если эти библиотеки не являются компонентами COM.

Можно и COM-ы без реестра грузить. Это просто dll-ка с определёнными соглашениями, не более. Реестр просто удобен в качестве центрального места регистрации COM-объектов.
Кстати C:\WINDOWS\WinSxS не аналог?

Не совсем. У меня сложилось впечатление, что WinSxS был придуман в целях уменьшения DLL hell. Какой-то он загадочный, этот WinSxS... Чтобы что-нибудь оттуда загрузить, совершенно необязательно с COM связываться. Там много (особенно в висте) plain dll.

Сложностей понавыдумывали, нет чтобы Versioned Symbols в PE ввести

[dzid]

Простые "самодельные" DLL зависят от конкретного языка програмирования. Клиенты, использующие экспортируемые функции таких DLL, должны быть написаны на том же самом языке, что и используемая ими DLL.

Ничего подобного. Касательно Delphi - поищите в справке для чего нужны такие ключевые слова как external и cdecl. В С++ есть такое слово как extern. Тоже посмотрите для чего оно нужно. Еще погуглите например по ключевым словам вызов dll из delphi

А dll, кроме всего прочего предназначена для смеси различных языков в одном проекте.

Это смотря как DLL написана... Если я Вам mangled C++ names заэкспортирую, фигу такую длл к дельфи приделаешь. Да и вообще к чему-либо, что другим компилятором (даже версией оного) собиралось. Еще там есть аккуратно разложенные грабли с memory allocation

[Zulkar]

Это смотря как DLL написана... Если я Вам mangled C++ names заэкспортирую, фигу такую длл к дельфи приделаешь. Да и вообще к чему-либо, что другим компилятором (даже версией оного) собиралось. Еще там есть аккуратно разложенные грабли с memory allocation

А в дельфи можно вызывать функции из dll, которые экспортированы по ординалу?
Да, грабли с memory allocation есть.Это зависит от линковки CRT например. Но самая частая ошибка - освобождение памяти, запрошенной библиотекой в основной программе. Грабли обычно обходятся хорошим проектированием.

PS: Разговор шел о том, что не обязательно либа и программа должны быть написаны на одном языке.