2013-03-26 3 views
0

Я использую ESENT для своих проектов довольно широко, и мне очень нравится, как легко и быстро это работает. И стабильно!Esent падает с Windows 8 в проекте Delphi

Но у меня ОГРОМНАЯ проблема с Windows 8 !!! Независимо от того, как я ссылаюсь на esent.dll (динамически или статически) всякий раз, когда я вызываю что-то другое, кроме JetSetSystemParameter, dll сбой, takig мое приложение вниз по скале.

К сожалению, я все еще не могу заставить его работать. У моего кода не было проблем с Windows 7 или старше. Но с Windows 8 я обнаружил сбой esent.dll, когда пытаюсь создать экземпляр (недействительная операция с плавающей запятой).

Я пробовал все возможные соглашения о вызовах. Это определенно НЕ проблема. Я попробовал еще кое-что и обнаружил эту странную ситуацию: 1. Я создал демо-приложение, используя VS 2012, и JetCreateInstance работал отлично. 2. Точно такой же код в Delphi XE3 отправит сбой esent.dll. 3. Я создал DLL, используя VS 2012, экспортируя метод, который отлично работал в вышеупомянутом демонстрационном приложении, считая, что это ошибка Delphi. 4. И затем я загрузил DLL в демо-проект Delphi (попробовал с 6, XE2 и XE3). Вызывается метод и BOOM. Тот же крах.

Теперь мое предположение заключается в том, что Microsoft не позволит?!? любая другая среда разработчика корректно работает с esent.dll. Возможно ли это?

+1

Это могут быть настройки FPU из Delphi. Вы пытались изменить это? – jachguate

+0

Дубликат: http://stackoverflow.com/questions/13415275/ present-crashes-with-windows-8 – bummi

+0

Было бы лучше закрыть другой. Поскольку этот вопрос лучше, поскольку он дает среду программирования и улучшает диагностику исключения. –

ответ

5

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

По умолчанию Delphi исключает исключения с плавающей запятой. Поэтому, когда код запрашивает блок с плавающей точкой для выполнения операций, которые приводят к ошибкам, сигналы FPU, которые затем преобразуются в исключение.

Но большинство других сред разработки Windows маскируют эти исключения на FPU. Такой код написан в предположении, что среда исполнения имеет исключения FPU в масках. Но если вы вызовете DLL из Delphi, среда выполнения будет иметь unmasked исключения FPU, нарушая это предположение. Я подозреваю, что если вы маскируете исключения FPU, тогда ваши проблемы исчезнут.

Чтобы проверить, если это проблема, то вы можете просто добавить это в ваш код, выполненный в начале своей жизни:

Set8087CW($027F); 

Это будет маскировать все исключения и установить контроль FPU слово настройки Windows, по умолчанию ,

В долгосрочной перспективе вы можете отмаскировать исключения перед каждым вызовом этой DLL, а затем восстановить контрольное слово FPU при возврате вызова в DLL.

Это немного опасная игра с использованием библиотек, которые поставляются с Delphi, поскольку Set8087CW не является потокобезопасным из-за использования глобальной переменной Default8087CW. Если вы хотите больше узнать об этой проблеме, я отсылаю вас к QC#107411.

Смежные вопросы