¿Medio of topick?: Tipos de datos para dll's

[Jonny]

Hola

Bueno, bueno ... Vaya tinglao para hacer una dll con VB 6, es más difícil casi compilarla que escribir el código...

Casi he hecho que funcione, un script de AutoIt, llamando a una dll hecha por mí.

Algo bueno tenía que tener todo esto, además de aprender otro lenguaje, y esque, ahora después de leer, leer y leer la ayuda de DllCall() (que antes no terminaba de entender) pues ahora, entiendo perfectamente (o eso creo) la función y ¡hasta casi me se todos los tipos de datos, y la equivalencia con las APIS de Windows! jejejeje.

Pero; o me hago un taco con los tipos (yo creo que no), o el taco está en las funciones de VB.

Resulta que he leido, que da problemas el hecho de usar cadenas en las funciones de una dll, pero que puede arreglarse. Dicen en una página, que por un lado hay que pasar los parámetros a la función con algo como esto:

Código: Seleccionar todo

SValue = StrConv(sValue, vbUnicode)

Y aquí viene el lío.
¿Qué hace esta función exactamente? (esto es de VB 6).
¿A que convierte la cadena? y ¿Como se hace en AutoIt esto mismo?, porque no soy capaz de pasarle una cadena como parámetro a la función de la dll.
Entiendo que el código anterior convierte a unicode, y he visto en la ayuda de DllCall, que wstr es eso mismo, pero nada. Salta lo de los informes de errores de Windows.

Dice en la misma página, que la función debe retornar la cadena así:

Código: Seleccionar todo

sValue = StrConv(sValue, vbFromUnicode)

Debe hacer lo mismo, pero no es exactamente igual...

vbFromUnicode

Aunque devolviendo directamente la cadena sin convertirla, indicando en AutoIt wstr como tipo de retorno, obtengo bien la cadena.

A ver si alguien que haya manejado VB me hecha un cable pa explicarme el rollo este ...

Acias,

Salu2!

[Ximorro]

No sé VB, bueno, trabajé con él hace tiempo, pero no me preocupaba en ese momento de cadenas ANSI o Unicode, yo usaba cadenas, y punto, VB ya se encargaba de manejarlas bien

Pero no parece tan complicado, simplemente si desde VB necesitas una cadena ANSI, en AutoIT usa un parámetro str, y si es Unicode, pues pon wstr... ¡y no tienes que hacer nada, AutoIT hace la conversión si es necesario! En principio AutoIT trabaja en ANSI, se puede compilar en Unicode si lo pones en los parámetros de compilación, aunque no todas las funciones trabajan con Unicode. Pero como digo da lo mismo, deja AutoIt en Ansi, que si pones bien el tipo de parámetro (str o wstr) no debe haber problemas.

Supongo que si VB necesita Unicode y la pasas como Ansi (str) entonces es cuando en VB tienes que hacer ese StrConv, o sea, como no le has dicho a AutoIT que haga la conversión, pues tienes que hacerla tú...

De la ayuda de DLLCall:
str: una cadena ANSI (no puede tener más de 65536 caracteres).
wstr: cadena de caracteres UNICODE (16bits) (convertida de/a cadena ANSI durante la llamada, si es necesario). No puede tener más de 65536 caracteres.

Pues eso, que se convierte sola. str no la convierte... porque AutoIT ya es ANSI, así que la pasa tal cual. Fíjate en el tamaño, no pases textos de más de 64kb.

[Jonny]

Hola

Efectivamente, en principio, no debiera ser tan complicado, pero parece que sí.

De VB 6, respecto al Asci o Unicode, no se bien como irá, aunque supongo que como dices hará la conversión él mismo, igual que AutoIt.
De momento, las pruebas que he hecho han sido pasándole una cadena como argumento en Asci, y convirtiéndola en la propia función de la dll a unicode, que es lo que he leído que hay que hacer para que funcione la dll.
La única forma que hasta ahora he encontrado para que funcione, es pasar una cadena como Asci, y no tratarla ni siquiera para convertirla a Unicode, en la dll. A la que intento hacer algo con la cadena recibida, el AutoIt se cuelga, ya pase la cadena con "STR", "WSTR".... como quiera, le da igual, y casca.

A ver si pasando la cadena a unicode (sin que la convierta AutoIt) directamente, le da por funcionar, es de lo poco que me queda por probar. Eso, y usar la dll desde VB.

Salu2!

[Alastor]

Cuando te da crash?
Si es al recoger el retorno de la llamada, prueba a cambiar a cdecl (lo digo porque me pasaba lo mismo)

Código: Seleccionar todo

			$ret = DllCall($dll, "int:cdecl", "MemW", "str", String($Txt))
			$ret = $ret[0]

[Jonny]

Hola

Gracias.
La verdad es que peta con la función DllCall, pero no solo al recoger los datos de la dll (que también si especifico un tipo incorrecto), sinó al pasarle un parámetro de tipo string. Debe ser cosa de la dll, pero no he conseguido saber qué.

Por cierto:
¿Qué es cdecl?

Salu2!

[Ximorro]

No creo que VB haga conversión de tipo de string automáticamente, lo hace AutoIt al hacer el DllCall (según lo que pone en el manual).
Se supone que también debería ocurrir con el valor devuelto, pues también lo especificas en los parámetros de DllCall, pero a saber.

Lo de cdecl es algo interno del compilador para generar el código máquina. Tiene que ver con quién limpia la pila del sistema (zona de memoria donde se pasan los parámetros y se recoge el resultado) y el orden en que se pasan los parámetros. Puede hacerlo el que llama a la función o la propia función, con Cdecl (declaración tipo C) es el llamante, la otra posibilidad es StdCall (gestión estándar), donde es la propia función la que limpia la pila.

No hace falta saber esas cosas tan internas, las comento por ampliar info. Lo importante es saber que existe, y efectivamente es importante saber cómo se ha diseñado la función de la DLL que estás llamando, ¡pues tienes que decírselo a AutoIt!. Si no lo haces AutoIT puede no gestionar bien la pila con resultados desastrosos... como esas petadas que te está dando.

[Jonny]

Hola

Entiendo... Nunca me había hecho falta usarlo, pero quizá haya llegado el momento...


Efectivamente, VB no hace automáticamente la conversión, teóricamente he de hacerla yo, pero nada, ni haciéndola, ni sin hacerla, peta. Lo curioso, es que convirtiendo yo en autoit la cadena que le paso como parámetro a la dll y llamándola así:

Código: Seleccionar todo

$Dll=DllOpen("Prueba.dll")
$CallDll=DllCall($Dll, "WSTR", "Saludo", "WSTR", AscToUnicodeString("Hola mundo"))
Msgbox(0, "", $CallDll[0])
DllClose($Dll)
Func AscToUnicodeString($Arg)
Local $BuffString
If $Arg=="" Then Return -1
$StringDiv=StringSplit($Arg, "")
If IsArray($StringDiv) Then
For $I=0 To $StringDiv[0] Step +1
$BuffString&=AscW($StringDiv[$I])
Next
Else
$BuffString=AscW($Arg)
EndIf
Return $BuffString
EndFunc

Consigo que no pete , pero tampoco obtengo "Hola mundo", que es lo que le paso como parámetro (la función recoge un argumento y lo devuelve tal cual).
Ahora bien, si intento hacer comparaciones por ejemplo con "Hola mundo" desde la dll, peta (es rarísimo).

Total, que el problema viene de la dll, porque dicen que VB no trata del todo bien las cadenas (de eso no tengo ni idea). En cualquier caso, según he leido, las funciones de las dll las tratan en unicode, y así se las paso y las recojo con AutoIt... Pero no hay manera.


Salu2!

[Ximorro]

Ese AscToUnicodeString se supone que no debería hacer falta, pues se supone que al ser el parámetro wstr Dllcall ya debería hacer la conversión. ¿Hace lo mismo si lo pones como si no?

Prueba a sacar la cadena desde VB, a ver si le llega bien (escribiéndola en un archivo de texto o quizás sacándola por un msgbox, si eso no interfiere con AutoIt).

Podías pasarnos el código VB, a ver si alguien que sepa ve algo. También son importantes las opciones de compilación, y en DLL hay que tener en cuenta eso del cdecl o stdcall, las funciones que se exportan, etc... Y no tengas tan claro que una dll trabaja con Unicode, eso es lo normal, no por ser Dll, sino porque Windows está tomando eso como nativo, y dejando el ANSI como "compatible con lo viejo". De hecho en las APIs de Windows hay muchas funciones dobles, una para Unicode y la otra para ANSI. Por ejemplo resulta que existe MessageBoxA (para ANSI) y MessageBoxW (para Unicode) en user32.dll, hay una tercera sin letra, MessageBox, que lo que hace es seleccionar una u otra, supongo que según el programa que la llame o cómo esté éste linkado o a saber. Pero el caso es que como ves hay funciones DLL para ANSI o Unicode, así que puede variar. Si no haces nada especial sospecho que están en Unicode... claro que VB6 ya tiene sus años...

Por otro lado puede que VB6 trate las variables de una manera un tanto especial, por eso no es de lo más adecuado para hacer DLL, si no fija los tipos de variables a tipos estándar de Windows (recuerdo los tipo Variant aquéllos, eso no tendría correspondencia en una DLL) Y los String podrían no corresponder con la representación interna de las cadenas que requiere la especificación de la API de Windows... Mira ver los tipos de VB, a ver si hay "otros tipos" de String que se adecuen más a las cadenas de bajo nivel.

Ah, otra cosa, tal como pones cuando DllCall devuelve el valor ¡en un array!. Por alguna razón devuelve también los parámetros, nunca he entendido por qué (se supone que es por si los pasas por referencia pero en ese caso modifica las variables originales ¿no?). Bueno, el caso es que eso es así si no hay error, porque si hay error no es un array, así que mejor captura los errores:

Código: Seleccionar todo

$cadena = DllCall(..........)
If not @error Then
  $cadena = $cadena[0]
Else
 ; Tratar el error
EndIf

[Ximorro]

Datos sacados de la ayuda de DllCall:
.- Por defecto AutoIt usa el tipo de llamada StdCall. Si tu Dll usa Cdecl tienes que especificarlo tal como te ha puesto Alastor. Habrá que buscar en las opciones de compilación cuál usa por defecto VB.

.- Por defecto AutoIt usa la versión ANSI de la función, de hecho pone el ejemplo de MessageBox que te he puesto antes (qué originales somos), así que si le pones un DllCall a MessageBox, AutoIT en principio usa MessageBoxA. Si quieres que use la Unicode tienes que poner expresamente que quieres MessageBoxW. Esto no te afecta porque tu Dll no tiene dos versiones, te lo comento para que veas que no queda claro eso de que las DLL usen Unicode, precisamente AutoIt busca la versión ANSI, así que es cosa del programador controlarlo...

[Jonny]

Hola

En teoría, efectivamente, no haría falta, al poner "wstr" en el tipo de parámetro, pero curiósamente de esa forma peta al pasar el parámetro como unicode y así no, solo aguanta si lo paso como asci ("str"), pero al convertirlo en la dll a unicode así:

Código: Seleccionar todo

    sNombre = StrConv(nombre, vbUnicode)

peta.

En cambio,con la función que he hecho para convertir la cadena a unicode, almenos la dll, me deja almacenar el parámetro que recibe en una variable local.

No he intentado lo de sacar la cadena a un archivo de texto, pero sí mostrarla en un MsgBox(), y nada... No se ejecuta y peta el AutoIt. Quizá me dejara guardarla en un archivo de texto...


El código de la función de la dll es este:

Código: Seleccionar todo

Option explicit

Public function Saludo(arg As String) As String
Dim sNombre As String

[b]' La cadena recibida convertirla a Unicode[/b]
sNombre=StrConv(nombre, vbUnicode)
[b]' La cadena de salida, convertirla a ¿ANSI? (la predeterminada del sistema)[/b]
Saludar=StrConv(sNombre, vbFromUnicode)
End Function

El archivo .def para compilar la dll es este:

Código: Seleccionar todo

NAME Prueba
LIBRARY Jonny
DESCRIPTION "Prueba de DLL creada con VB6"
EXPORTS Saludo @1

Pues con el cdecl y el stdcall me matas, no sabía nada de eso, así que menos en VB, En lo que he leído de hacer dll's con VB 6 (que es bien poco lo que hay de documentación) no pone nada de eso, más que el código para crear el Link.exe del VB modificado, y los pasos para crear la dll, que no son más que "Nuevo proyecto", "Dll ActiveX" (se supone que no se crea como ActiveX al modificar el linker), añadir un módulo "bas", escribir en él el código y compilar ("Generar Nombre.dll").

Yo tampoco he entendido nunca el array que devuelve la dll, con los parámetros en el elemento [1]... Tienes razón, pero no hice el tratamiento de ese error porque era una prueba,y por qué no decirlo estaba más que harto de ella, de la dll... jejeje. Pero para un programa real, sí es importante si no se quieren tener posibles errores fatales controlar eso.

Salu2!

[Jonny]

Hola

¡Perdón por este segundo mensaje!

.- Por defecto AutoIt usa el tipo de llamada StdCall. Si tu Dll usa Cdecl tienes que especificarlo tal como te ha puesto
Alastor. Habrá que buscar en las opciones de compilación cuál usa por defecto VB.

Gracias por el apunte. Me voy a poner a mirar en el VB, a ver si encuentro algo.

.- Por defecto AutoIt usa la versión ANSI de la función, de hecho pone el ejemplo de MessageBox que te he puesto antes (qué originales somos), así que
si le pones un DllCall a MessageBox, AutoIT en principio usa MessageBoxA. Si quieres que use la Unicode tienes que poner expresamente que quieres MessageBoxW.
Esto no te afecta porque tu Dll no tiene dos versiones, te lo comento para que veas que no queda claro eso de que las DLL usen Unicode, precisamente AutoIt
busca la versión ANSI, así que es cosa del programador controlarlo...

Pero eso ¿Debería solucionarse especificando los tipos de datos ("str" o "wstr") no?

Salu2!

[Ximorro]

Estooooooooooooo, en la función VB... ¿qué es Saludar? porque la función se llama Saludo, si ese es el valor que devuelve deberías asignarlo al nombre de la función ¿no?

A ver si es esa tontería...

¿Option Explicit no era precisamente para obligar a declarar las variables? ¿por qué te deja usar esa variable Saludo si no está declarada? Ese programa tiene algo raro, creo que eso no debería dejarte compilarlo...

Lo de str o wstr ¡depende de qué espere recibir VB! Si VB trabaja en ANSI le tienes que poner str, y si es Unicode pues wstr, y no haría falta hacer conversiones a mano porque para eso estás especificando de qué tipo es la cadena...

El caso es que eso de que peta cuando hace las conversiones me mosquea (debería poner caracteres raros y hacer mal la conversión pero tanto como petar no), sigo pensando que la representación interna de String en VB podría no coincidir bien con las cadenas de la API, y no se está pasando bien el parámetro.
¿Alguien podría probarlo en VB en .Net?
O tú mismo, quizás no sea tan complicado pasarse a VB.Net sabiendo VB6, no hace falta que te metas con C++.
Es cierto que para que un usuario use .NET tiene que tener la plataforma instalada (con VB6 también hace falta en vbrun, pero eso es algo muy pequeñito al lado de .NET). En cualquier caso es raro que no se tenga instalado .NET, lo usa tanta gente que seguramente a todos nos ha tocado ponerlo... además varias versiones.

[Jonny]

Hola

uuuuh, ni caso, eso efectivamente, no iría (lo escribí al momento de postear, no tenía el código a mano).

Código: Seleccionar todo

Option Explicit


Public Function Saludo(Arg As String) As String
Dim sNombre As String

' La cadena recibida convertirla a Unicode
sNombre = StrConv(Arg, vbUnicode)
' La cadena de salida, convertirla a ¿ANSI? (la predeterminada del sistema)
Saludo = StrConv(sNombre, vbFromUnicode)
End Function

Esto sí compila. Recibe una cadena asci, que asigna a sNombre convertida a unicode y por último devuelve sNombre, convertida a asci nuévamente.

Entonces, en AutoIt, debería de hacer algo como esto:

Código: Seleccionar todo

$Dll=DllOpen("Prueba.dll")
$CallDll=DllCall($Dll, "STR", "Saludo", "STR", "Hola mundo")
Msgbox(0, "", $CallDll[0])

DllClose($Dll)

Enviando un parámetro de tipo String a la dll (ya que la conversión la hará la propia dll) y recibiendo también un valor de tipo String, ya que la dll se encargará de devolverlo así.

Pues al ejecutar este código de AutoIt, se cierra el script de golpe y sale lo de informes de errores.
Yo también creo que hay algo raro ahí con los tipos de datos, y ha de ser en VB, pero ...


El proyecto completo, con la dll y el código autoit lo dejo en:

http://www.sendspace.com/file/tz2onc



Por si alguien quiere mirarlo más detenidamente.

.- Por defecto AutoIt usa el tipo de llamada StdCall. Si tu Dll usa Cdecl tienes que especificarlo tal como te ha puesto
Alastor. Habrá que buscar en las opciones de compilación cuál usa por defecto VB.

He estado mirando por internet, y he encontrado esto:

http://www.taringa.net/posts/downloads ... _dll.html

Donde pone entre otras muchas cosas:

* Sólo permite el uso de funciones de librerías dinámicas (DLL) stdcall.

Por lo que entiendo, que compilará así las dll's.

Salu2!

[Ximorro]

Pues mosquea mucho, porque da igual qué combinaciones de tipos de parámetros, conversiones, o tipos de llamada que pongas, siempre casca. Y peta justamente en la llamada a DllCall, sin dar tiempo a AutoIt a dar ningún código de error.

Cada vez tengo más claro que es culpa de VB6, que la DLL no es totalmente compatible con el estándar, y para mí que es cosa de los String (por cierto, ¿has probado a hacer una función que no use cadenas, por ejemplo que simplemente reciba dos enteros y los sume).

Esas petadas tienen pinta de accesos ilegales a memoria. El tipo de llamada no es porque da igual que le pongas stdcall o cdecl, así que sospecho que los String no son como se espera y "los punteros se vuelven locos".

Prueba otros tipos de datos no String, para ver que al menos la DLL en general sí va. Si es por el String... ya puedes ir cambiando a .Net

Por cierto, usa indentación cuando programes, el código se lee mucho mejor...
Además supongo que en VB usas su propio editor, no usas el notepad, ¿verdad? Pues en AutoIt también te recomiendo usar algún editor, no hay muchas opciones pero Scite hace la vida más fácil. Vaya, recuerdo que una vez comentabas que escribías directamente en notepad, no sé si ya te habrás pasado.

[Jonny]

Hola

Efectivamente.

Si cambiásemos el parámetro que recibe la cadena a int, float... Permitiría tratar perfectamente el contenido y devolverlo sin problemas. Vamos, que el problema efectivamente está en las cadenas, y creo que no tiene fácil solución (si la tiene).

Al final, tendré que hacerte caso y pasar a .net, aunque me viene un poco (bastante) grande...

He leido que ahora el VB es VB .net ¿no?
¿Sabeis que tal es, si es mucho más complicado que el 6... Porque C#, lo temo.

Bueno, en VB he escrito poco código, la verdad, pero sí, en el editor que lleva. Lo de dejar el Notepad, es una asignatura pendiente...

Salu2!

[Ximorro]

VB.Net es más evolucionado pero sigue siendo un BASIC, como mejora por ejemplo ahora es un lenguaje orientado a objetos, el VB de antes los usaba, pero no los creaba, o le faltaba cosas muy importantes en OO, como derivar objetos por mecanismos de herencia, por ejemplo. Así que el nuevo es más complejo, y eso se notará, pero sigue la sintaxis de los anteriores VB, con lo que quien manejara aquéllos pasará a .NET mucho más fácil con VB.NET que con cualquier otro de los lenguajes.

C# es como una mezcla de C++ y Java, y me han dicho que ha tomado algunas ideas de Delphi (un Visual Pascal de Borland).
Además está J#, que es más Java, aunque lo han abandonado (ahora hay un F#, que no sé si es el sucesor o algo independiente).
Y hay más...

Así que si te da miedo C# ¡tienes donde elegir!
Pilla VB.NET si te vas a sentir más cómodo con él y ya está.

Algo interesante es que existen versiones gratuitas (Express, las llaman) de Visual Studio, así como Visual Studio Profesional ofrece soporte para todos los lenguajes de la plataforma, en las versiones Express tienes una para cada lenguaje, así que te puedes bajar el de VB.NET y a por ello.


Y el editor.... ¡¡pásate a Scite ya!! No se puede programar sin tener una IDE que te ayude a encontrar errores de compilación, a organizar código, etc...
También puedes usar esto:
http://www.autoitscript.com/wiki/FAQ#Graphical_debugger
Que además tiene un debugger.

[Jonny]

Hola

jajajajaja ¡medio abecedario en lenguajes!
Supongo que se me daría mejor VB.net, por eso de que si mantiene un poco la sintaxis del VB 6, y el VB 6 tiene un parecido con la sintaxis de autoIt...

C#, me parece bastante complicado, pero más que nada porque se basa cien por cien en la POO, lo que implica no solo tener conocimientos de programar o de C#, sinó de Windows, sus eventos, como procesa la información, etc etc.

La cosa es ¿VB.net qué tal se manejará con las dll?. Porque si lo hace igual que el 6 ... (imagino que no, claro).

El debugger gráfico ya lo había visto alguna vez por el foro inglés, pero la verdad, no me dió por bajarlo.

¿No había un parche para traducir el scite a español?.
Esque me suena haber visto por aquí algo de eso hace mucho. No es que no me maneje bien con la interfaz en inglés, pero si puede estar en Castellano, mejor que mejor.

Salu2!

[Ximorro]

A ver, POO no tiene que ver exactamente con Windows, es la forma de diseñar y por lo tanto escribir (lo que llaman implementar) los pogramas. En vez de tener un código principal y una serie de funciones sueltas, como hacemos con AutoIT, en OO encapsulas el código en lo que llaman clases (los objetos son instancias particulares de una clase) que incorporan tanto datos como funcionalidad.

Lo de manejar Windows ocurre mucho en AutoIt, (cuando llamamos a la API o recogemos mensajes de objetos para responder a eventros, o cuando interactuas con el WMI como ponías en otro post, etc.). Como ves eso puede ser añadido al hecho de programar en OO o independiente, depende del acceso que tengas a las interioridades del sistema sobre el que trabajas, en este caso Windows.

Dicho esto, pues VB.NET es OO (más que el 6) y por supuesto maneja eventos y esas cosas (imprescindible con interfaces gráficas). Pero no creo que sea tan diferente de VB6, desde luego no es igual, es mucho más potente (en teoría equivalente a los otros .NET) pero saber VB6 es un paso importantísimo para que sea bastante fácil pasarse a .NET.
Si sabes C++, pues pasa a C++.Net, si sabes VB6 pues te pasas a VB.NET. Fácil
C# es otro lenguaje diferente, no te obsesiones con él, hay donde elegir. Por cierto estuve mirando un poco F# y no tiene nada que ver con el abandonado J#, es algo totalmente diferente.

¿Y las DLL? De eso no tengo duda, mucho mejor que con VB6, seguro.

No me suena lo del Scite en español, pero no creo que sea tan importante, piensa que tampoco es un editor muy complicado, y bastante intuitivo.
En cualquier caso seguro que en este foro de AutoIT también te responderán a las dudas de Scite, al fin y al cabo es su editor por excelencia...

[Jonny]

Hola

miraré lo que comentabas de las versiones express, a ver que encuentro, y me pondré con VB.net seguramente, aunque, VB 6 no es que lo dominara mucho, así que podría ser buena excusa para hacer un pensamiento de aprender cualquiera de los lenguajes del .net, total en todos jugaría casi con la misma ventaja.

No, no es que sea importante el idioma de Scite, era curiosidad, porque si pudiera elegir, pues ... eligiría tenerlo en castellano, pero vamos, que como dices no es muy complicado, más o menos me manejo bien para almenos un uso básico.

Salu2!

[Ximorro]

Bueno, tengo curiosidad, ¿lo has pasado a VB.NET? ¿funciona?
Queremos saber si es problema del VB6 o del AutoIt. Espero que sea del VB6