Comments on: Cuando hay mucho para escoger http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/ La Cara Oscura del Desarrollo de Software Tue, 09 Sep 2008 23:45:33 +0000 http://wordpress.org/?v=2.6.1 By: Amina http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-928 Amina Sat, 15 Dec 2007 23:05:18 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-928 Tu blog es ... genial! no lo perderé de vista! Tu blog es … genial! no lo perderé de vista!

]]> By: Robert http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-873 Robert Thu, 18 Oct 2007 16:11:46 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-873 Uno de los grandes dilemas de integrar tantas tecnologias, y las cosas se ponen feas cuando los proveedores de harware te dan solo un DLL. Agradece que, por lo que veo, el API por lo menos es usable y no tan feo como otros que he visto que requieren el Handler de una ventana Windows para recibir mensajes (y si mi programa no tiene GUI???? jajaj falta de visión para no decir ignorancia de los proveedores) Es este caso yo fuese experimentado con otra solución, siguiendo un poco la filosofia Unix, crearía un programa no interactivo que sería la interfaz con el dispositivo (un daemon) y crearia la interfaz con la tecnología de mi preferencia (Java, .Net, etc...). usando un protocolo de comunicación sencillo entre el GUI y el daemon Uno de los grandes dilemas de integrar tantas tecnologias, y las cosas se ponen feas cuando los proveedores de harware te dan solo un DLL. Agradece que, por lo que veo, el API por lo menos es usable y no tan feo como otros que he visto que requieren el Handler de una ventana Windows para recibir mensajes (y si mi programa no tiene GUI???? jajaj falta de visión para no decir ignorancia de los proveedores)

Es este caso yo fuese experimentado con otra solución, siguiendo un poco la filosofia Unix, crearía un programa no interactivo que sería la interfaz con el dispositivo (un daemon) y crearia la interfaz con la tecnología de mi preferencia (Java, .Net, etc…). usando un protocolo de comunicación sencillo entre el GUI y el daemon

]]> By: Rómulo Rodríguez http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-870 Rómulo Rodríguez Tue, 16 Oct 2007 10:39:18 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-870 Zeitan, si, supongo que con un poco de más tiempo habríamos podido hacer que funcionara, hemos hecho un montón de aplicaciones con usos de dll's externas sin problemas en el pasado. Pero acá la cosa fue algo diferente por culpa de la presión del tiempo. Uno de los problemas más importantes fue convertir la clase inicial en C++ en una dll que pudiera utilizarse en C#. Las dll por lo general no pueden exportar clases que puedan instanciarse sino más bien funciones, eso por culpa de la forma en que se manejan los objetos en ambos ambientes (C# y C++). Eso hizo que cambiáramos el código para convertirlo en funciones exportables. Luego tal como dices usamos dllimport para usarlas en el código C#, pero el detalle es que nuestro API requiere reservar segmentos de memoria que comparte en modo de escritura y lectura con el software con el que estamos haciendo la IPC. El caso es realmente complejo y a cada rato teníamos excepciones de sistema por conflictos en la asignación de memoria. Creo que con un poco más de tiempo pudiéramos ver como evitamos estos problemas. Nuestro API usa las funciones de Windows ReadProcessMemory, WriteProcessMemory, VirtualAllocEx, VirtualFreeEx y SendMessage entre otras para que tengas una idea. Zeitan, si, supongo que con un poco de más tiempo habríamos podido hacer que funcionara, hemos hecho un montón de aplicaciones con usos de dll’s externas sin problemas en el pasado. Pero acá la cosa fue algo diferente por culpa de la presión del tiempo. Uno de los problemas más importantes fue convertir la clase inicial en C++ en una dll que pudiera utilizarse en C#. Las dll por lo general no pueden exportar clases que puedan instanciarse sino más bien funciones, eso por culpa de la forma en que se manejan los objetos en ambos ambientes (C# y C++). Eso hizo que cambiáramos el código para convertirlo en funciones exportables. Luego tal como dices usamos dllimport para usarlas en el código C#, pero el detalle es que nuestro API requiere reservar segmentos de memoria que comparte en modo de escritura y lectura con el software con el que estamos haciendo la IPC. El caso es realmente complejo y a cada rato teníamos excepciones de sistema por conflictos en la asignación de memoria. Creo que con un poco más de tiempo pudiéramos ver como evitamos estos problemas. Nuestro API usa las funciones de Windows ReadProcessMemory, WriteProcessMemory, VirtualAllocEx, VirtualFreeEx y SendMessage entre otras para que tengas una idea.

]]> By: zeitan http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-867 zeitan Mon, 15 Oct 2007 12:37:49 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-867 Romulo hace unos 4 años me toco hacer algo mas o menos similar, pro un lado teníamos un API que se exponía solo en c++(Software AG Entirex) y por el otro lado una en C ANSI(Lib. SAP RFC) en ambos caso se crearon pequeños wrappers sobre las APIs expuesta que nos hacía de bridge entre la API y el código no manejado. Desde C# lo que hicimos fue usar el TAG dllimport y solo devolver entre ambos mundos Strings (En un caso uno formateado como un XML y otro como un string por espacios). Sufrimos de leaks memorys pero fue hasta que vimso como hacer un correcto free del memory pero la appz soporta como uno 12000 usuarios hoy día. Esa fue mi experiencia y realmente pude hacer interopratibilidad sin trauma aparente. Romulo hace unos 4 años me toco hacer algo mas o menos similar, pro un lado teníamos un API que se exponía solo en c++(Software AG Entirex) y por el otro lado una en C ANSI(Lib. SAP RFC) en ambos caso se crearon pequeños wrappers sobre las APIs expuesta que nos hacía de bridge entre la API y el código no manejado.
Desde C# lo que hicimos fue usar el TAG dllimport y solo devolver entre ambos mundos Strings (En un caso uno formateado como un XML y otro como un string por espacios).
Sufrimos de leaks memorys pero fue hasta que vimso como hacer un correcto free del memory pero la appz soporta como uno 12000 usuarios hoy día.
Esa fue mi experiencia y realmente pude hacer interopratibilidad sin trauma aparente.

]]> By: Rómulo Rodríguez http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-866 Rómulo Rodríguez Sun, 14 Oct 2007 21:41:44 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-866 wxWidgets también lo revisamos, tiene la ventaja sobre Smartwin de ser crossplatform. No obstante como lo que estamos haciendo es solo para windows decidimos irnos por la solución minimalista. Sally es una lindura de IDE. wxWidgets también lo revisamos, tiene la ventaja sobre Smartwin de ser crossplatform. No obstante como lo que estamos haciendo es solo para windows decidimos irnos por la solución minimalista. Sally es una lindura de IDE.

]]> By: dagi3d http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-865 dagi3d Sun, 14 Oct 2007 17:43:33 +0000 http://www.lacaraoscura.com/2007/10/14/cuando-hay-mucho-para-escoger/#comment-865 le habéis echado un vistazo a las <a href="http://www.wxwidgets.org/" rel="nofollow">wxWidgets</a> le habéis echado un vistazo a las wxWidgets

]]>