|
15.12.2008, 08:52 | #1 |
Участник
|
COMConnector для 64 разрядных приложений
Коллеги.
Похоже COMConnector 3.0 не совместим с 64 разряднымы приложениями. Я прав |
|
15.12.2008, 09:55 | #2 |
Модератор
|
Да. Ждите 2009.
Сервер, кстати, работает - я запускал 4,0 на х64. Однако скорость была крайне низкой. Эмуляция 32х разрадного режима сожрала все преимущество платформы. С Уважением, Георгий |
|
15.12.2008, 11:32 | #3 |
Участник
|
Что значит "ждите"? Оно уже давно есть, и даже SP1 успел выйти. То, что пока нет локализации приложения для России, не мешает испытать в действии COM-коннектор (от которого, к слову, MS обещает уже отказаться в пользу .NET-варианта).Подождите, а при чем тут сервер? Я так понимаю, изначально речь шла о том, чтобы дергать COM-коннектор из приложения под x64, а не о том, чтобы просто запускать 32-разрядное ядро того же AOS'а под 64-битной ОСью, к примеру. 32-разрядные (x86) приложения под x64-виндами на соотв. платформе работают и так, иначе кому бы нужна были эти x64-винды.О какой эмуляции идет речь? Вроде в виндах под x64 нет никакой эмуляции при выполнении x86-приложений, есть лишь thunk'и для вызова из них 64-разрядного кода ядра, ну и что-нить аналогичное для вызова из ядра 32-разрядных callback-функций приложения, а эмуляции, как на IA64, там afaik нет.
|
|
15.12.2008, 17:10 | #4 |
Модератор
|
Цитата:
Остальное просто рассказал, относилось к серверу, не к СОМу. Спасибо, не знал, что нет эмуляции 32х разрядного режима, думал, есть С Уважением, Георгий |
|
15.12.2008, 18:09 | #5 |
Участник
|
2 George Nordic
Цитата:
Сообщение от George Nordic
Эмуляция 32х разрядного режима сожрала все преимущество платформы.
Цитата:
Сообщение от gl00mie
есть лишь thunk'и для вызова из них 64-разрядного кода ядра
|
|
16.12.2008, 11:36 | #6 |
Участник
|
Дополнительная память теоретически требуется на каждый вызов API-шной функции через thunk, НО каждый отдельный поток в один момент времени может вызывать, очевидно, не более одной API-шной функции, таким образом, накладные расходы на вызов 64-разрядных функций из 32-разрядного кода в общем случае в каждый момент времени не превышают размера стека, использованного под передачу параметров вызываемой функции, умноженного на количество одновременно выполняющихся в системе потоков 32-разрядных приложений. С учетом того, что обычно через стек передается относительно немного данных (в худшем случае до сотни байт), а потоков в системе обычно считанные сотни, ну тысячи, накладные расходы составят лишь десятки-сотни килобайт в каждый момент времени.
|
|
16.12.2008, 10:52 | #7 |
Модератор
|
Прошу прощения. Платформа была Itanium II. http://www.seneca2.ru/archive_370_19932
С Уважением, Георгий |
|
17.12.2008, 03:36 | #8 |
Участник
|
Реализовали доступ через ADO. Пришлось пожертвовать бизнес логикой...
|
|
17.12.2008, 11:03 | #9 |
Участник
|
Ну зачем сразу жертвовать бизнес-логикой? Есть же XML Web-службы, в которые можно "завернуть" вызовы Business Connector'а, - они не чувствительны к "разрядности" клиентских приложений.
|
|
17.12.2008, 17:24 | #10 |
Участник
|
Цитата:
Сообщение от gl00mie
обычно через стек передается относительно немного данных (в худшем случае до сотни байт)
Т. е., похоже, проблемы thunk'ов 32->64 могут возникнуть при недостаточных размерах стека 32-битного потока?.. Точнее, при размерах, не рассчитанных на выполнение в 64-битной среде (при вызовах API-функций, богатых параметрами)? Резерв-то указывается в исполняемом файле... |
|
17.12.2008, 18:40 | #11 |
Участник
|
Чего-то какая-то путаница возникла, по-моему...
Цитата:
|
|
|
За это сообщение автора поблагодарили: somebody (1). |
18.12.2008, 10:35 | #12 |
Участник
|
Цитата:
Сообщение от gl00mie
При чем тут размер стека и "несколько десятков-сотен байт на один вызов"?
Цитата:
Сообщение от gl00mie
при вызове через thunk используется один и тот же стек вызывающего потока, т.е. отдельный какой-нить стек мегабайтного размера (или сколько там прописано в PE-заголовке) не создается.
|
|