Каморка

aissp писал(а):почитал на досуге что ноне твориться с комом, ну вроде как транслируется вызов к обычной длл, так что один свой нападок я снимаю, хотя и не полностью, потому как втаб все равно участвует в процессе. А с вариантом нападок остается.

Извини за нудность, но ком не только может находиться в длл (iprocserver) но и в ехе (outofproc server), или может хоститься exe стабом на удалённом хосте (не популярный и наверное полу-мёртвый на сегодня дком).

Здесь при всех наворотах две особеннсти:
1) надо обязательно имплементировать функции, которорые нужны SCM + свои интерфейсы;
2) вторая тонкость, что клиент ком (код программера) никогда не загружает сам длл, разрешает экспортированные символы и т.д.; всё автоматизировано и делается за спиной у программера SCM-мом.

Зачем ты все ето рассказываешь? Я имел ввиду данную конкретную функцию о которой шел разговор и имел ввиду только ето ничего более или ты будешь утверждать что ета функция обычно хоститься на другом сервере? Ну ежели так, то без системного вызова не обойтись

aissp писал(а):Зачем ты все ето рассказываешь? Я имел ввиду данную конкретную функцию о которой шел разговор и имел ввиду только ето ничего более или ты будешь утверждать что ета функция обычно хоститься на другом сервере? Ну ежели так, то без системного вызова не обойтись

Ты, наверное, имеешь ввиду не kernel32.dll- ли? Или даже user32.dll?Где ж та система обитает и вызывается.

В чем отличия вызова функции из статически прилинкованной библиотеки, динамически прилинкованной библиотеки, обращение к другому процессу, обращение к карточке (или другому физическому дивайсу)? А ты про что?

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

При статической линковке линке разрешает адреса фактичеких вызовов (относительные адреса в объектном скомпилированном коде) на стадии сборки.

При динамической линковке размещение будет определяться base адресом, заданным пр компиляции длл, или при невозможости размещения (две и больше длл) по указанным адресам загрузщик вынужден вообще поместить в памяти с w/r доступом, что будет вызывать инетсивный свопинг, и как следствие крайнюю неэффективность программ (см. SDK утилиту rebase, для определения правильных базовых адресов длл).

Таким образом, это просто разное. Возможно у вас некоторое смешение понятий RTL и системных вызовов.

>>обращение к другому процессу,

Посто не возможно в W32, если иметь ввиду непосредственный вызов, как в предыдущем. Адресное пространство разных процессов изолированно.

... Только наиболее низкоуровневый RPC, или высокоуровневые кастом протоколы, основанные на взаимодействии процессов с использованием протоколов более высокго уровня (DCOM, SOAP, пайпы, майлслоты, тсп/юпд, малтикаст, и др. впрочем уже больше извращения, чем промышленно подобные протоколы) Короче, к системным вызовам вообще не имеет отношения. Извините...


>> обращение к карточке (или другому физическому дивайсу)?

Не разбираюсь.

ПС. То, что вы считаете "OLE системными вызовами" - не существует.

aldep писал(а):вытащить исходники и откомпилировать под VC
Это всеже проще будет наверное, чем самому писать.

Боюсь оно там сильно на локализацию завязано так что половину libc придется тянуть с инфраструктурой. Так что под изестный формат проще наверное самому написать.

-Maxim

sobomax писал(а):

aldep писал(а):вытащить исходники и откомпилировать под VC
Это всеже проще будет наверное, чем самому писать.

Боюсь оно там сильно на локализацию завязано так что половину libc придется тянуть с инфраструктурой. Так что под изестный формат проще наверное самому написать.

-Maxim

На самом деле, всё уже давно сделано, и если не хочется по простому -использовать ATL/MFC (я там раньше постил), достаточно пропарсить строку и использавать недокументированные (или плохо документированные) хелперы майкросфт (m$ использует это для своих библтотек шблонов), см. \MFC\SRC\OLEVAR.CPP, _AfxOleDateFromTm.

м-да, вы вопрос то прочитали? объясните мне пожалуйста вот вы пишите:
"может находиться в длл (iprocserver) но и в ехе (outofproc server), или может хоститься exe стабом на удалённом хосте "
Далее я отвечаю что имел ввиду ету конкретную функцию ничего более.
Вы отвечаете:
"Ты, наверное, имеешь ввиду не kernel32.dll- ли? Или даже user32.dll?Где ж та система обитает и вызывается"

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

Короче, к системным вызовам вообще не имеет отношения. Извините... "

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

Еще раз уточню вашу точку зрения: Объект имплементирванный в чужом процессе вызвать можно, можно вызвать объект даже на другом компутере, но, к системным вызоввам ето отношения не имеет. Еще более конкретно: обхект в простанстве другого сервера выщвать можно, но не возможно и никаких системных вызовов... Я с вашего позволения поскипал все остальное не существенное, моуг только заметить что если вы скажите кому то, если речь зайдет о системных вызовах про kernel and user dll, то вас неправильно поймут потому что обе из них работают в user моде в отличие от ядра.

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

ATL/MFC??? Пойду-ка я еще раз повешусь.

Старина Зотин писал(а):ATL/MFC??? Пойду-ка я еще раз повешусь.

Оставайся живым. Почитай МСДН про ОЛЕ ДАТЕ ТАЙМ там и будет ATL/MFC.

Почитай МСДН про ОЛЕ ДАТЕ ТАЙМ там и будет ATL/MFC

Лучше я все таки повешусь.