Antonio S.O.S.... PCODE DLL no funciona con FWH 7.12

[Cgallegoa]

Hola Antonio y amigos:

Tenemos desarrolladas 17 aplicaciones distintas las cuales, a su vez, se personalizan de acuerdo a las necesidades de los clientes. Consecuentemente tenemos un uso intensivo, MUY INTENSIVO, de DLLs externas con funciones contenidas en diferentes PRGs.

Hemos venido trabajando con FWH 2.7 (Julio del 2006), xHarbour 0.99.61 en forma perfecta. Sin embargo, aun cuando estaba ansioso por actualizarme a la última versión de FWH, la cual obliga a la última de xHarbour, me contuve por temor a las incompatibilidades entre versiones de xHarbour.

Esta semana me actulicé a FWH 7.12 y xHarbour 1.1.0 y comenzó mi pesadilla. No debería ser así.

Dicho y hecho: ahora ya no funciona más el uso de PCode DLLs. Simplemente las invoca pero no ejecuta el código contenido en ellas. Esto adcional a otras incompatibilidades que estamos testeando.

Estoy seguro que no es asunto de FiveWin, sino de xHarbour, pero Antonio, necesitamos tu ayuda al respecto. Es inaceptable que por este tipo de cambios en xHarbour, limiten la actualizacion de tu maravillosa herramienta, pues si no solucionamos esto nos veremos forzados a mantenernos con FWH 2.7.

Antonio y amigos, hemos probado de todo y definitivamente no funciona. Si revisan los ejemplos PCODEDLL.PRG y TESTDLLP.PRG incluídos en FWH, verás que ya no funcionan. Si los compilas con FWH 2.7 y xHarbour 0.99.61 funcionan perfecto, pero no con FWH 7.12 y xHarbour 1.1.0

Si algún compañero ya ha tenido este problema con las DLL y lo ha solucionado por favor tirenme una mano.

Antonio, hay solución que no implique cambio complejo de código ?

Un abrazo para todos,

Carlos Gallego

[Antonio Linares]

Carlos,

Habeis recompilado las DLLs ?

Es necesario por los cambios de pcode de xHarbour

[Cgallegoa]

Antonio millón de gracias por tu respuesta.

Sip. Hemos compilado las Dll.

Sólo para prueba, por favor hazlo con PCODEDLL.PRG y TESTDLLP.PRG utilizando Buildhdp.bat y Buildx.bat. Los cuatro archivos están en FWH\SAMPLES.

Verás que invocan bien la la función contenida en la PCODEDLL.DLL, devueve bien el resultado, pero no ejecuta las instruciones que están en la función, en el ejemplo, unos MsgInfo

Saludos,

Carlos Gallego

[Cgallegoa]

Antonio,

Los ejemplos que te indico, son lo que vienen con FWH. Tal cual se compilaron.

Estoy realmente preocupado, pues imagínate casi todos nuestros clientes tienen personalizaciones en su aplicaciones a través de las DLL, mismas que con frecuencia toca modificar, pues ya tu sabes como son los clientes, piden cambios, cosas nuevas, etc. Sólo en lo que va de esta semana, hemos hecho seis modificaciones. Las hicimos con FWH 2.7 y funcionan de maravilla. No pudimos con FWH 7.12, y por supuesto que las recompilamos por efectos del pCode. Simplemente no funcionan.

Saludos,

Carlos Gallego

[Antonio Linares]

Carlos,

Si, acabamos de construir esos ejemplos y efectivamente la DLL funciona pero no llama a las funciones del EXE, por eso MsgInfo() no funciona.

De momento, que la DLL se construya y cargue bien es buena señal.

Falta por descubrir porque no se está accediendo a las funciones del EXE. Seguimos revisando...

[Cgallegoa]

Perfecto Antonio,

Quedo tranquilo sabiendo que tu ya estás al tanto. Seguro que lo resuelves y por favor jálale las orejas al equipo de xHarbour , que no hagan esas locuras, y si atropellan, que primero toquen el claxon

Larga, larguísima vida a FiveWin. Es el mejor.

Saludos,

Carlos Gallego

[Antonio Linares]

Carlos,

Solucionado Hay que hacer algunos cambios:

pcodedll.prg:

Code: Select all  Expand view  RUN

// Harbour sample of a pcode DLL

#include "FiveWin.ch"

function Func1()

   static cTest

   if cTest == nil
      cTest = "it works!"
   endif

   MsgInfo( "Hello from inside the PRG pcode DLL" )
   MsgInfo( cTest )

return nil

function Func2( c1, c2 )

   MsgInfo( c1, c2 )

return "it works ok!"

DYNAMIC MSGINFO
DYNAMIC ERRORSYS
DYNAMIC FW_GT
DYNAMIC TACTIVEX
DYNAMIC GETPROCADDRESS

#PRAGMA BEGINDUMP

#include <windows.h>

typedef PHB_SYMB ( * VM_PROCESS_SYMBOLS_EX ) ( PHB_SYMB pSymbols, USHORT uiSymbols, char * szModuleName, ULONG ulID, USHORT uiPcodeVer );

static HB_EXPORT PSYMBOLS hb_vmProcessSymbols( PHB_SYMB pSymbols, USHORT uiModuleSymbols, char *szModule, int iPCodeVer, PHB_ITEM *pGlobals ) /* module symbols initialization */
{   
   static FARPROC s_pProcessSymbols = NULL;
   PHB_SYMB pModuleSymbols = NULL;

   if( !s_pProcessSymbols )
      s_pProcessSymbols = GetProcAddress( GetModuleHandle( NULL ), "_hb_vmProcessSymbols" );

   if( s_pProcessSymbols )
      pModuleSymbols = ( ( VM_PROCESS_SYMBOLS_EX ) s_pProcessSymbols )
                     ( pSymbols, uiModuleSymbols, szModule, iPCodeVer, NULL );

   return pModuleSymbols;
}

#PRAGMA ENDDUMP


En testDLLP.prg:

Code: Select all  Expand view  RUN

function Main()

   local hDll := LibLoad( "pcodedll.dll" ) // LoadLibrary( "pcodedll.dll" )

   // HB_LibDo( "DLLInit" )  ya no es necesaria esta llamada!
   HB_LibDo( "Func1" )

   MsgInfo( "Back to the EXE" )

   MsgInfo( HB_LibDo( "Func2", "a parameter from the EXE", "Inside the DLL" ),;
            "Value returned from the DLL function" )

   // Ahora podría liberarse
   LibFree( hDLL ) // FreeLibrary( hDll )  don't free it

return nil


[Antonio Linares]

Carlos,

Si modificas vm\maindllp.c de esta manera, entonces ya no tienes que incluir ese código en C en el PRG:

Code: Select all  Expand view  RUN

HB_EXPORT PSYMBOLS hb_vmProcessSymbols( PHB_SYMB pSymbols, USHORT uiModuleSymbols, char *szModule, int iPCodeVer, PHB_ITEM * pGlobals ) /* module symbols initialization */
{
   FARPROC pProcessSymbols;
   HB_SYMBOL_UNUSED( pGlobals );

   /* notice hb_vmProcessDllSymbols() must be used, and not
    * hb_vmProcessSymbols(), as some special symbols pointers
    * adjustments are required
    */                                                                   
   pProcessSymbols = GetProcAddress( GetModuleHandle( NULL ), "_hb_vmProcessSymbols" );

   if( pProcessSymbols )
   {
      return ( ( VM_PROCESS_SYMBOLS ) pProcessSymbols )( pSymbols, uiModuleSymbols, szModule, iPCodeVer, pGlobals );
   }
   /* else
         may we issue an error ? */

   return NULL;
}


Y tienes que incluir esta definición en include\hbtypes.h:

Code: Select all  Expand view  RUN

typedef PSYMBOLS ( * VM_PROCESS_SYMBOLS ) ( PHB_SYMB pSymbols, USHORT uiModuleSymbols, char *szModule, int iPCodeVer, PHB_ITEM * pGlobals);


[Cgallegoa]

Antonio, gracias por tu respuesta, pero definitivamente no funciona.

Seguí las instrucciones que diste. Modifiqué maindllp.c y hbtypes.h

En un ejemplo simple compila, ejecuta, lee el contenido de la función en la Dll y retorna bien el resultado, perfecto. Pero.....

Tengo Dlls conformadas por 5 o más PRGs con más de 10000 líneas de código que controlan procesos complejos de producción industrial, otras controlan sistemas de venta POS y manejo de periféricos POS. Se crean Ventanas, Diálogos, Browses, se capturan datos, se imprimen informes, interactúan con TSBrowse y TSButton, Gráficos, etc. En otras palabras, hacemos maravillas con las Dll y todas funcionan perfecto con FWH 2.7.

Por lo que pude inferir, ya no hace falta compilar y linkear en las dlls el archivo FWSTUB.PRG pues no hace nada. En su reemplazo, tomé todas esas intrucciones y las cambié de Stub a DYNAMIC. Luego las incorporé como "includes", en cada PRG que conforman cada Dll. Si en un prg no están incluídas genera error cuando invoque alguna función en ese prg. Por otro lado, si se linkean como Libreria, como se hacía con FWStub, no reconoce ninguna función.

Lo mismo hay que hacer con cada función de Clipper/Harbour que se quiera utilizar en la Dll. Por ejemplo si quieres hacer un dbGoTop, pues debes ponerlo como DYNAMIC, igual con Empty(), File().dbSkip()....... es decir, todas, sin excepción, las que vayas a utilizar.

Adicionalamente, pones un Dialogo con un simple SAY en un prg y funciona bien. Muestra el diálogo y el say, pero si se te ocurre poner OemToAnsi("seleccione su opción"), entoncer revienta, genera error y no indica cuál ni en dónde. Para solucionarlo te quedan dos opciones: O quitas el OemToAnsi() o pasas la rutina al primer Prg de la Dll para que funcione. Entonces nos quedara un PRG de más de 10000 líneas

Tres personas llevamos 24 horas sin dormir intentando hacerlas funcionar y no hemos podido. O somos muy burros o fue un cambio estructural y no damos por dónde buscarlo.

Y esto es apenas el inicio de las dlls. ni hablar de intentar hacer un deSetFilter, un ADSSETAOF o alguna función de mayor peso. Error y no se sabe porqué. Toca ir aislando línea por línea para ver dónde se genera el error, algunos definitivamente no los pudimos solucionar.

Créeme que hemos hecho todos los intentos y es terriblemente desgastador. Tratamos de valernos por nosotros mismos para no molestarte ni molestar a los compañeros del foro, pero el asunto definitivamente se escapó de nuestras manos.

AUXILIO Antonio...................

No existirá alguna forma de dejar todo el proceso relaciona con el manejo de PCode Dlls como estaba hasta la versión 0.99.61 ?

Por la modificación que me sugeriste, queda claro que fué un cambio en xHarbour, pero lamentablente, a más de que manejo un inglés muy deficiente, no tengo los conocimientos técnicos para lanzarme en una consulta de esta naturaleza y plantearla de la forma en que le gusta a Ron Pinkas.

No sé si algún otro colega usa intensivamente Dlls y con cuál versión . Si alguno está usando la última versión de FWH y de xharbour, y usa intensivamente código en Dlls y le están funcionando bien, por Dios, que me eche una manito, y me cuente cómo lo hizo.

Y como la Ley de Murphy es inexorable, justo en estos días se les ha ocurrido a una buana cantidad de clientes pedir cambios o procesos nuevos por cierre de año e inicio del próximo.

Un abrazo y espero con ansias tu ayuda,

Saludos,

Carlos Gallego

[Antonio Linares]

Carlos,

Este es el resultado de determinadas personas en Harbour que se dedican a cambiar cosas sin importarles mucho si rompen compatibilidad con el código anterior y el programador es el que sufre las consecuencias

Y tampoco es fácil ir hacia atras, pues muchas veces son cambios que afectan a distintas partes internas.

Se nos ocurre un "hack" en la máquina virtual que quizás funcione. Vamos a hacer algunas pruebas...

[Antonio Linares]

Carlos,

Tendrías algún ejemplo de PRG para construir la DLL que falle y que no use FWH ? gracias

[Cgallegoa]

Antonio,

Totalmente cierto.

Parece que la gente va perdiendo el horizonte.

Yo creo que es el momento en que tú deberías retomar el liderazgo de desarrollo en xHarbour, así como lo tienes en Harbour, y consolidar código en un sólo producto, por ejemplo yHarbour, donde el principal objetivo sea el fortalecimiento de FiveWin.

Lo que necesitamos ahora, más que nunca, es fortalecer al máximo a FiveWin. Tu maravillosa herramienta fué la primera opción que tuvimos todos lo programadores puros de Clipper para salir del mundo de los 16 bits. Fué y ha sido indiscutiblemente la mejor. Fuiste el maestro de miles de programadores y el decano de Harbour. Tú lo create. Tu visión, tu capacidad y tu profesionalismo lo crearon.

Lástima la desersión, que con la dispersión de esfuerzos, en vez de fortalecer una herramienta y un concepto, los debilitan, y que, en vez de darnos un largo y próspero camino a los miles que venimos de Clipper, crean confusión. Van naciendo xxxVisuales, que en vez de unir, dividen.

Yo invito a los amigos que se apartaron de FiveWin y se fueron por otros caminos a que regresen. FiveWin ya está recontra probado, es la plataforma de miles de aplicaciones de todo tipo, hermosas, sólidas y robustas, corriendo por todo el mundo. Los invito a que apoyemos a FiveWin, a que no nos olvidemos, que todos, o casi todos, comenzamos el mundo de los 32 bits con Fivewin, que gracias a tí y a tu producto, aprendimos, vivimos, comimos, creamos empresa, crecimos, etc. Un poco de agradeciemiento hacía tí y hacia tu producto no vendría mal.

FiveWin no es una aventura, es una realidad, una sólida realidad, y si la hacemos más y más grande, todos ganarémos.

No hay límite a lo que puedes hacer con FiveWin y con un xHarbour (xHarbour estable y compatible, por supuesto). El límite es la capacidad e imaginación del programador.

Ufff, amanecí inspirado, que ya parezco político.

LARGA, LARGUISIMA VIDA A FIVEWIN. ES EL MEJOR

Un abrazo y quedo a la espera de tu ayuda,

Saludos,

Carlos Gallego

[Antonio Linares]

Carlos,

Prefiero no entrar en polémicas y discusiones sin fín

Consígueme un ejemplo que reproduzca el error sin usar FWH

Gracias!

[Cgallegoa]

Antonio:

http://mastersoft3000.com/publico/prudll.zip

Va un ejemplo completo super reducido que muestra el problema de los SAY con OemToAnsi. Pero va con FWH

No sé como simular el mismo comportamiento sin usar FWH.

Saludos,

Carlos Gallego