La introducción: la parte larga y aburrida

(La pregunta está al final)

Siento dolores de cabeza severos por un componente COM de terceros que sigue cambiando la palabra de control de la FPU.

Mi entorno de desarrollo es Windows y Visual C ++ 2008. La palabra de control de FPU normal especifica que no se deben lanzar excepciones durante varias condiciones. He verificado esto con ambos mirando la_CW_DEFAULT macro encontrada enfloat.h, además de mirar la palabra de control en el depurador al inicio.

Cada vez que hago una llamada al objeto COM, la palabra de control se modifica al regresar. Esto es fácil de defender. Simplemente restablezco la palabra de control, y todo está bien. El problema es cuando el componente COM comienza a llamar a mi receptor de eventos. Puedo proteger mi código restableciendo la palabra de control tan pronto como reciba la llamada del evento, pero no puedo hacer nada tan pronto como regrese de la llamada del evento.

No tengo la fuente de este componente COM, pero estoy en contacto con el autor. Las respuestas que he recibido de él han sido "¿Eh?". No creo que tenga la menor idea de lo que estoy hablando, así que me temo que tengo que hacer algo al respecto. Creo que su tiempo de ejecución (creo que es Delphi o Borland C ++, porque la DLL está llena de nombres de símbolos, todos comenzando con T mayúscula), o algún otro código de terceros que esté usando, eso está causando el problema. No creo que su código modifique explícitamente la palabra de control de FPU.

¿Entonces Que puedo hacer? Desde el punto de vista comercial, es imprescindible utilizar este componente de terceros. Desde un punto de vista técnico, podría deshacerme de él e implementar el protocolo de comunicación yo mismo. Sin embargo, eso sería realmente costoso, ya que este protocolo implica el manejo de transacciones con tarjeta de crédito. No queremos asumir la responsabilidad.

Necesito desesperadamente un truco o alguna información útil sobre la configuración de FPU en los productos de Borland que pueda transmitir al autor del componente.

Las pregunta

Hay algoI ¿puede hacer? No creo que el autor del componente tenga lo necesario para solucionarlo (a juzgar por sus respuestas bastante despistadas).

He estado jugando con la idea de instalar mi propio controlador de excepciones, en el que simplemente restablezco la palabra de control en el controlador y le digo a Windows que continúe ejecutándose. Intenté instalar el controlador conSetUnhandledExceptionFilter(), pero por alguna razón, no se detectan las excepciones.

¿Por qué no estoy captando las excepciones?Si logro atrapar excepciones de FPU, restablecer la palabra de control de FPU y dejar que la ejecución continúe ya que no ha sucedido nada, ¿entonces todas las apuestas están canceladas?Actualiza

Me gustaría agradecer a todos por sus sugerencias. Le he enviado al autor instrucciones sobre lo que puede hacer para facilitarle la vida no solo a mí, sino a muchos otros clientes de su código. Le sugerí que debería probar la palabra de control de FPU enDllMain(DLL_PROCESS_ATTACH), y guarde la palabra de control para más adelante, para que pueda restablecer FPU CW antes de llamar a mis controladores de eventos y regresar de mis llamadas.

Por ahora, tengo un truco si alguien está interesado. El truco es potencialmente malo, porque no sé qué le hará as código. He recibido confirmación anteriormente de que no usa ningún número de coma flotante en su código, por lo que esto debería ser seguro, salvo algún código de terceros que use, que se base en excepciones de FPU.

Las dos modificaciones que he realizado en mi aplicación:

Envolver mi mensaje bombaInstale un gancho de ventana WH_CALLWNDPROC) para detectar los casos de esquina donde se omite la bomba de mensajes

En ambos casos, verifico si la FPU CW ha cambiado. Si es así, lo restablezco a_CW_DEFAULT.