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

[dzid]

Zulkar, можно. Но лучше не надо. Никто не обещает, что ординалы в версии x.y.z и x.y.z+1 будут совпадать.

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

__declspec(dllexport) class CFoo {...};

то все.... С любым другим компилятором, кроме того, чем собрал автор, вы радостно пролетаете мимо методов класса CFoo.

А непростые длл требуют изрядного напряжения для их правильного написания, чтобы работало всегда и правильно.

[Zulkar]

А непростые длл требуют изрядного напряжения для их правильного написания, чтобы работало всегда и правильно.

Ну. Кто бы спорил-то.

[v04bvs]

Zulkar, можно. Но лучше не надо. Никто не обещает, что ординалы в версии x.y.z и x.y.z+1 будут совпадать.

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

__declspec(dllexport) class CFoo {...};

то все.... С любым другим компилятором, кроме того, чем собрал автор, вы радостно пролетаете мимо методов класса CFoo.

А непростые длл требуют изрядного напряжения для их правильного написания, чтобы работало всегда и правильно.

Есть сишные стандартные соглашения по вызову функций. С++ вообще здесь пролетает, чтобы его использовать, надо везде писать с-шные обёртки. Если соглашения соблюдаются - никаких проблем нет и быть не может. Memory allocation всегда обговаривается заранее, и граблями это назвать тяжело, т.к. проблема заезженная и понятная.

Ну есть ещё MS-овские соглашения про COM-интерфейсы. Их, кстати, вполне можно использовать из C кода, хоть и муторно.

Сообщение отредактировал v04bvs: 20.08.2008, 19:12:31

[Visual1]

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

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

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

Ошибаетесь, имеет. Причем самое прямое. Когда клиенты запрашивают объект сервера СОМ, они передают диспетчеру SCM код ID объекта, а SCM находит и загружает сервер, получая эту информацию из системного реестра.

[v04bvs]

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

И как же по-вашему программы на Delphi используют системные библиотеки Windows (user32.dll например)? Они то на C написаны, не на Delphi. И COM-ом там не пахнет.

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

Ошибаетесь, имеет. Причем самое прямое. Когда клиенты запрашивают объект сервера СОМ, они передают диспетчеру SCM код ID объекта, а SCM находит и загружает сервер, получая эту информацию из системного реестра.

The service control manager (SCM) is started at system boot. It is a remote procedure call (RPC) server, so that service configuration and service control programs can manipulate services on remote machines.

The service functions provide an interface for the following tasks performed by the SCM:

* Maintaining the database of installed services.
* Starting services and driver services either upon system startup or upon demand.
* Enumerating installed services and driver services.
* Maintaining status information for running services and driver services.
* Transmitting control requests to running services.
* Locking and unlocking the service database.

Ничего про COM-серверы здесь нет. Приведите ссылку на документацию.

[Visual1]

И как же по-вашему программы на Delphi используют системные библиотеки Windows (user32.dll например)? Они то на C написаны, не на Delphi. И COM-ом там не пахнет.

Там, кратко говоря, используется проецирование файлов DLL в адресное пространство вызывающего процесса, получение адресов динамически связываемых функций и их вызов. При создании исполняемого файла ЕХЕ компоновщик просматривает объектные файлы вашей программы и в разделе импорта составляет список всех необходимых DLL, в которых находятся вызываемые вашей программой библиотечные функции. При вызове функций из системных библиотек (например, из user32.dll, реализующей лишь базовые функциональные возможности Win32 API), действительно, СОМ-ом там и не пахнет, а значит, не пахнет никакими возможностями получать указатели на интерфейсы. Только в СОМ возможно ООП на основе интерфейсов, но опять же, если не использовать универсальные типы данных IDL по стандарту Microsoft, то языковой независимости клиентов и серверов СОМ достичь не получится (об этом я уже говорил выше).

The service control manager (SCM) is started at system boot. (...)

Ничего про COM-серверы здесь нет. Приведите ссылку на документацию.

Вот, например, из MSDN Library:

A component called the Service Control Manager (SCM) is responsible for locating the server and running it.

Вот еще, оттуда же:

The Service Control Manager (SCM) is the component of the COM Library responsible for locating class implementations and running them. The SCM ensures that when a client request is made, the appropriate server is connected and ready to receive the request. The SCM keeps a database of class information based on the system registry that the client caches locally through the COM library.

Сообщение отредактировал Visual1: 21.08.2008, 00:33:37

[RAWMIND]

Зачем когда есть Rxlib ?

А я что? Я просто предложил пример в тему. Да и к тому-же код можно расширить - сохранять в реестре (GrayFox, не кидайтесь камнями , для каких-нибудь целей, можно использовать собственный формат файлов вида, например:
<CompName>:<CompProperty=value>[CompProperty=value]..<CR>
Не знаю зачем. Вдруг пригодится А можно использовать для сохранения настроек сетевой порт. Например, "конфиг-файл" находится по адресу admin:4896. AD адыхаит Что хочешь - то и делай.
Хм. По поводу переносимости прикладных программ. Я не спец, но на сколько я знаю, можно писать программы ПРАВИЛЬНО - т.е. пользоваться домашним каталогом (для этого есть переменная %APPDATA%). А уже потом, когда программа будет подготовлена к запуску на съемных носителях, лаунчер заменит значение %APPDATA% для запускаемой программы на <FlashDriveLetter>:\<PathToProgram>\AppData\, либо просто скопирует содержимое каталога AppData на съемном носителе в домашнюю директорию пользователя - а там уже, по возможности, назад.

требуют прав администратора для какой нибудь фигни типа конвертирования музыки

Гыыы. Хай юзер устанавливает такие программы в %HOMEPATH% или вообще на рабочий стол %-)
А вообще, как показывает практика, подобные программы используют не корневой каталог с программой, а просто текущий каталог. Создаем ярлык, меняем рабочую папку на ту, где можно - ву-а-ля! Теперь "."=%HOMEPATH%, а не <PathToProgram>

Еще в /tmp могут писать laugh.gif

Сохранять конфиги в %TEMP% грешно, и вообще можно схлопотать пистон за преступление против человечности %-)

При увеличении количества нодов - мы имеем падение производительности.

А при увеличении количества ini-файлов мы имеем торможение файловой системы %-)

А куда ведёт %HOMEPATH% в Windows 9x?

Сама Win9x ведет к отсутствию безопасности %-)

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

У ini и у inf файлов разное назначение.

P.S.> не обзывайтесь некропостером. Просто больно уж полемики жаркие

[RAWMIND]

Там, кратко говоря, используется проецирование файлов DLL в адресное пространство вызывающего процесса, получение адресов динамически связываемых функций и их вызов. При создании исполняемого файла ЕХЕ компоновщик просматривает объектные файлы вашей программы и в разделе импорта составляет список всех необходимых DLL, в которых находятся вызываемые вашей программой библиотечные функции. При вызове функций из системных библиотек (например, из user32.dll, реализующей лишь базовые функциональные возможности Win32 API), действительно, СОМ-ом там и не пахнет, а значит, не пахнет никакими возможностями получать указатели на интерфейсы. Только в СОМ возможно ООП на основе интерфейсов, но опять же, если не использовать универсальные типы данных IDL по стандарту Microsoft, то языковой независимости клиентов и серверов СОМ достичь не получится (об этом я уже говорил выше).

По-моему, не очень кратко у вас получилось Полностью аналогичным способом используются dll и в программах на других ЯП. Dll - это бинарник и использовать их можно используюя только стандартизированный СИшный вызов.
user32.dll - да, там не много функционала, но отдельно его не используют. Вообще WinAPI, если я не ошибаюсь, представляет собой набор функций, хранящихся в динамически подключаемых библиотеках...
Бред. Совершенно разные технологии

[Visual1]

user32.dll - да, там не много функционала, но отдельно его не используют.

Где я говорил, что его "используют отдельно"? Отдельно от чего?

Бред. Совершенно разные технологии

А я утверждал, что одинаковые? Где, покажите.

Зачем приписываете мне ошибочные высказывания, которых у меня не было?

[RAWMIND]

На это натолкнуло следующее:

из user32.dll, реализующей лишь базовые функциональные возможности Win32 API

Всем известно, какие именно функции GDI реализованы в библиотеке user32, да и назвать их БАЗОВЫМИ, мне кажется, не совсем корректно.

А я утверждал, что одинаковые

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

[Visual1]

да и назвать их БАЗОВЫМИ, мне кажется, не совсем корректно.

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

Если вы со мной не согласны, то скажите, как должно быть.

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

P.S. Ваш "шедевр" насчет функций GDI я тоже видел. Но спорить не буду - не по теме, да и не хочется мне тратить на вас время.

[RAWMIND]

Базовой библиотекой я считаю kernel. Без нее (в отличие от user32) не обойтись. На msdn ссылок давать не буду (нет у меня их, не имею удовольствия регулярно читать статьи), просто логика.

Как должно быть? Dll всеми известными мне компиляторами собираются с одинаковым интерфейсом вызова функций (экспорт). И, соответственно, функции из любых динамически подключаемых библиотек могут использоваться в любой программе, собранной компилятором, имеющим поддержку вызова stdcall. Все просто.

Опечатался. GUI.

Сообщение отредактировал RAWMIND: 22.08.2008, 23:44:24

[Visual1]

Базовой библиотекой я считаю kernel. Без нее (в отличие от user32) не обойтись.

Ошибаетесь. user32 является такой же обязательной базовой библиотекой, как и kernel32. Более того, она является частью самой ОС Windows, об этом прямо сказано в MSDN Library:

These libraries can be user-supplied, vendor supplied (the VBA DLLs that supply its functionality), or part of Windows itself (USER32.DLL, GDI32.DLL, etc.).

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

Это никакое не "удовольствие", а жизненная необходимость для всех, кто программирует под Windows. Ваша "логика" Вас здесь сильно подвела.

[Make your Choice]

СРОЧНО ТРЕБУЕТСЯ ПРОГРАММИСТ AXCAPTA. HELP!!! НЕТ ВОЗМОЖНОСТИ МОНИТОРИТЬ ЦТ. ОТЗОВИТЕСЬ НА МОЙ E-MAIL: CHOICE2008@LIST.RU

[SanKet]

Здавствуйте !
Подскажите пожалуйста, как написать на Delphi программу инсталляции?
Допустим, у меня уже есть написанная работающая программа на Delphi. Я теперь хотел бы её вмонтировать в модуль install.exe или setup.exe, чтобы после запуска этого install или setup моя программа попала бы в меню "Пуск" Windows c возможностью дальнейшей деинсталляции.
Что для этого нужно? Если инфы слишком много, то с благодарностью приму интернет-ссылку на эту тему
Заранее большое спасибо!

[Make your Choice]

срочно требуется программист Axcapta. Пишите на e-mail: choice2008@list.ru

["0x0000"]

to SanKet - наскока помню в делфи есть встроенные средства для создания инсталлеров. Или ищи бесплатные аналоги, их море. Точно не помню, я не дельфинист.

[|imp|]

SanKet, тебе надо: ISTool
Очень простая программка для создания setup-ов.
Если не найдешь в интернете стукни в ICQ, я тебе её скину.

[Ybray]

Здавствуйте !
Подскажите пожалуйста, как написать на Delphi программу инсталляции?
Допустим, у меня уже есть написанная работающая программа на Delphi. Я теперь хотел бы её вмонтировать в модуль install.exe или setup.exe, чтобы после запуска этого install или setup моя программа попала бы в меню "Пуск" Windows c возможностью дальнейшей деинсталляции.
Что для этого нужно? Если инфы слишком много, то с благодарностью приму интернет-ссылку на эту тему
Заранее большое спасибо!

Install Shield Express, должен быть на установочном диске Delphi

[BICH]

Здавствуйте !
Подскажите пожалуйста, как написать на Delphi программу инсталляции?
Допустим, у меня уже есть написанная работающая программа на Delphi. Я теперь хотел бы её вмонтировать в модуль install.exe или setup.exe, чтобы после запуска этого install или setup моя программа попала бы в меню "Пуск" Windows c возможностью дальнейшей деинсталляции.
Что для этого нужно? Если инфы слишком много, то с благодарностью приму интернет-ссылку на эту тему
Заранее большое спасибо!

http://www.innosetup.com/
бесплатная. уже 3 года пользуюсь. можно писать и плагины и алгоритм установки..