Вызов функций из DLL, хранящейся на сервере

Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long

может вот это поможет

Я писал клиент сервер, но я предпологаю, что проще длл поставить где-то то рядом, если это позволяет задача.

> brigval
Программа работает от имени обычного пользователя. Позволит ему это делать только свихнувшийся админ.

> LeonidSN
Много по этому написано книг. Один из способов - DCOM, то есть размещение COM на удаленном сервере.
Но нужны ли такие сложности при программировании для AutoCAD?

> kpblc
Не так. Регистрировать надо только DLL с COM-объектами. Обычную DLL регистрировать не нужно. Если ее использует только одно приложение, DLL может лежать просто рядом с ним.
В системные папки помещают DLL, к которым требуется доступ из разных приложений. Если DLL используют несколько приложений одной фирмы, их обычно размещают с Program Files\Common Files, например  Program Files\Common Files\Autodesk Shared.
Рассуждая о сервере, надо уточнять терминологию. Например, файловый сервер может отображаться в виде диска и на нем можно зарегистрировать COM-dll. Приложение выполняется на рабочей станции в ее памяти.
А клиент-сервер - совсем другое. Это удаленная машина, к которой вообще может не быть "файлового" доступа. Клиент-серверные приложения выполняются на ресурсах сервера, а клиенту возвращают только запрошенный результат.
Например, сейчас все видят результат выполнения запроса к серверу. Программа работает один densi знает где, мы видим наш запрос (его лучше скрывать, чтобы не вводить в искушение "кул-хацкеров")
https://www.caduser.ru/forum/topic26761.html
и результат в виде текста этой страницы в формате HTML. Основную работу проделал сервер.

У нормального админа обычные пользователи не имеют прав на запись в такие каталоги. А программа должна работать без запроса дополнительных привилегий. Кроме того, System32 рассматривают как свалку для своего "добра" только плохие разработчики. Для этого есть специально отведенные места (Documents and Settings и т.п).

> brigval
DLL операционной системы - да. А вот посторонним DLL там делать нечего. Именно из-за них и происходит "криминал".
Даже "законопослушные" программисты (чаще всего на VB) иногда включают в свой дистрибутив "свои" варианты даже системных DLL. Этому способствуют некоторые системы подготовки инсталляций, которые запускают приложение, проверяют, какие DLL оно использует и включают в дистрибутив. Иногда эту DLL еще и подправят под свои интересы. После чего приходится переустанавливать или восстанавливать Windows.
А "нехорошие" программисты специально заменяют стандартные библиотеки на свои (трояны, вирусы и т.п.)
На вид безобидные чужие DLL, размещенные в системном каталоге тоже могут нести в себе что угодно.
Поэтому у хорошего админа доступ в такие места для пользователей закрыт. Если же программа такая "хитрая", что требует администраторских привилегий, то хороший админ ее и ставить не даст. Без всяких доказательств и объяснений.
Но зачем ломиться именно в System32? Хорошая программа всегда знает, где живут ее собственные компоненты и умеет к ним обращаться.

Да, до версии 2004 был именно "из этих". Что весьма снижало уважение к фирме, так как WinNT, Win2000 уже существовали, а AutoCAD 200* были сделаны, как будто есть только Win98.

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

> DVAD
ИМХО: сделать инсталлятор и отслеживать корректность версии будет проще в результате.

> ShaggyDoc
И все-таки. Как можно осуществить вызов функций из из обычной DLL не помещая ее в System32?
Программа находится на сервере, DLL - на сервере. Это очень удобно при смене версий. На клиентской машине папки с программой нет. В какое место может быть помещена DDL на клиентском кмпьютере и что должна сделать программа что б получить возможность работать с функциями из DLL?
Или, возможно проще, в какой папке ОС ищет DLL, если не находит ее в System32?

> Александр Ривилис
Спасибо!
В данном случае
1 - не подходит, так как программа на сервере
2 и 3 - это для плохих программ, как говорит ShaggyDoc
4 - видимо, как и в случаях 2 и 3.
5 - остается одно, копировать DLL в папку для временных файлов. Наверное это логично.
А откуда такая полезная информация.

P.S.: Это именно та функция, о которой написал Smel: https://www.caduser.ru/forum/topic26761.html
Параметр lpLibFileName может быть полным путем доступа к DLL-файлу.