Платформа 8.3.10.2561 +Delphi +V83.ComConnector = нет соединения #805038

Доброго дня! Сменили платформу на 8.3.10.2561 и перестал соединятся COMConnector. При первой попытке соединения: Project Project1.exe raised exception class $C0000090 with message 'floating point invalid operation at 0x1a8381a6'. если повторить попытку, не закрывая приложения, то просто виснет. На предыдущей платформе и всех ранее стоявших никаких проблем с этим не было. 1. Библиотека comcntr.dll регистрировалась заново после установки платформы - удачно. 2. Соединение из Delphi прописано и через V83_TLB (CreateComObject(ClassID) as IV8COMConnector;)  и через CreateOleObject('V83.COMConnector') - результат одинаковый. 3. Соединение на этой же машине в С# устанавливается. В 1С соединение из базы к базе устанавливается. Что такое могло случиться с COM и как это возможно победить? Пока возвращаем платформу 8.3.9.1818.

Например, профили безопасности включили.

Техножурнал настроить и посмотреть

Может разрядность сервера при апргрейде 1С? т.е. старая версия была 32 бита, а новая - 64?

Про профили безопасности не слышал. Подключение под пользователем с максимальными правами.   В журнале ничего подозрительного не увидел. Разрядность как была 64 так и осталась. Попробуем копнуть в профилях пользователя - советуют посмотреть в сторону ограничения опасных функций, хз где это  да и думаю не поможет - ошибка в момент соединения. Никаких действий ещё не выполнялось.

короче это 8087CW должно быть как в 1С

ок.  На весь сеанс меняется или на момент подключения?

ну по логике на время работы с comcntr.dll

Вот блин... работает!!!  Но как , Холмс? Буду экспериментировать. Ставлю Set8087CW($133f) сразу при создании формы.  Все работает...  При закрытии возвращаю значение  и сразу получаю тоже сообщение. Видимо Com ещё не освобожден к этому моменту.... Шайтанство...

ну да. 1с долго выгружается вроде.

Не выполняй Set8087CW(Saved8087CW); после завершения работы с COM Дождись upload Comcntrl + 100500 связанных dll в окне Delphi и нажми кнопку, по которой выполни Set8087CW(Saved8087CW); Если все пойдет гладко - тебя ждут дальнейшие испытания

Откуда взяли v83tlb ?

Спасибо тебе, добрый человек. Хрен бы я когда вышел на эту тему, получая fpio при работе с COM

да эта тема древняя как и delphi. Еще с самых первых версий

Шел 21 век. 64-битные процессоры и программы вовсю использовали SSE для плавучки позрачно для компилятора и для пользователя. Создавались новые стандарты С++, возникали быстрые и могучие языки программирования со своими экосистемами. Программисты на Delphi колупались с сохранением состояния fpu, поломанным еще во времена 8087.

Ты просто не понимаешь о чем вообще речь, потому и написам херню. Бывает.

Да где уж нам, сиволапотным, отошедшим от дельфи в тот момент, когда она еще ценилась за умение собирать 16 битный код под 3.11fwg. Приятно видеть, что с той поры под капотом ничего не поменялось. Стабильность, это здорово, держитесь там, коллеги!

Достаточно дождаться дисконекта - остальные 100500 библиотек не повлияли. Ошибка при закрытии ушла. В каком смысле где взял V83_TLB? Создал заново через Import Component - 1CV83 ComConnector Type Library -> v83_tlb.pas

ну у C++ под капотом тоже ничего не поменялось. таковы стандарты.

Тут дело в реализации дельфевого VCL и прочих потрохов. Тысячу лет тому назад было принято сильно неудачное архитектурное решение, что внутренняя работа библиотек зависит от значения изменяющегося процессорного состояния. Причем этот состояние  может  произвольно меняться снаружи. После, например,вызовов winapi - CreateWindowsEx и все такое. И вот до сих пор этот маразм тянется и тянется, что в общем-то говорит о востребованности и популярности языка с его экосистемой. Остальные языки при проектировании своих библиотек как-то обошли эту особенность.

да ладна. просто в разных компиляторах используют разные значения управляющего слова FPU и при каждом вызове функции из вне проверять не изменилось ли там чего в этом управляющем слове - задолбаешься. Никто не проверяет. Не трогать это управляющее слово или восстанавливать его значение, еcли поменял, - задача писателей dll. А CreateWindowsEx и прочее давно исправили ещё в Windows XP

А что, в дельфи нельзя разве вообще отключить использование FPU? В досовском паскале можно было, он всю плавучку реализовывал библиотеками.

да можно. только нафига

Ну так это же должно убрать проблему, разве нет? А собственно плавучка для учетных задач никогда не была узким местом и на её быстродействие пофиг.

я думаю проблема не исчезнет

проблема будет эмулироваться :)

я бы оставил это слово FPU как в Си++ да и всё.

хотя это Delphi ошибку генерит. пускай будет Set8087CW($133f);

День отработал с этой доработкой. Клиентских соединений по  COM создавалось до 10 одновременно, через них создано  почти 6т. ОПЗС и простые запросы десятками тысяч. Подключаются/отключаются без проблем. Спасибо за помощь v77! От холиваров лучше отказаться. :)

может можно было обойтись просто try except? проигнорировать исключение и работать дальше

К сожалению нет. Ошибка выдавалась на строке Connect  и соотвественно ссылки на COM программа не получала. Ну и далее без неё ничего не работало естественно. Это я сразу попробовал. К тому же ошибка возвращается сразу же, при первом обращении к объекту, если восстановить значение CW.