Mensajes

No mire el codigo del enlace pero ya en la primera linea que dejaste aca no tiene sentido usar strlen, lo que queres que lea es maximo el tamaño del buffer y no de la cadena que hubiera antes en el buffer.

Podrias usar otro control en lugar de EDIT, un LISTBOX por ejemplo. Esto no tiene nada que ver con assembly sino que es un uso elemental de la API de Windows.

Antes de volver a consultar repasa todos estos tutoriales:
http://win32assembly.programminghorizon.com/tutorials.html

La clave ya existe asi que no es necesario usar RegCreateKey/Ex y BYTE es un typedef de unsigned char asi que no habria ninguna diferencia.

El codigo original funciona con los permisos necesarios ...

ERROR_INVALID_HANDLE6 (0x6)
The handle is invalid.

¿Que devuelve RegOpenKeyEx? Tu programa deberia comprobar eso antes de intentar llamar a RegSetValueEx.

ERROR_ACCESS_DENIED5 (0x5)
Access is denied.

Ejecutalo como administrador si es el caso.

No solucionaste ninguno de los problemas anteriores, el programa sigue generando dos excepciones no controladas.  Deberias hacerte cargo de eso antes de intentar mostrar mas de una linea en un EDIT, ese control muestra texto, asi que si, tenes que concatenar y usar saltos de linea.

Cuando tengas excepciones no controladas como es el caso usa el WinDbg para investigar. Aca podes ver rapidamente, extracto de comando kb:

000cfc04 00401060 007c05d4 00000066 616c6f68 USER32!SetDlgItemTextA+0x21
000cfc18 74dd62fa 007c05d4 00000110 002a22ac image00400000+0x1060

0:000> db 000cfc04
000cfc04  18 fc 0c 00 60 10 40 00-d4 05 7c 00 66 00 00 00  ....`.@...|.f...
000cfc14  68 6f 6c 61 44 fc 0c 00-fa 62 dd 74 d4 05 7c 00  holaD....b.t..|.
000cfc24  10 01 00 00 ac 22 2a 00-00 00 00 00 1a 10 40 00  ....."*.......@.
000cfc34  cd ab ba dc 01 00 00 00-01 00 00 00 1a 10 40 00  ..............@.
000cfc44  c0 fc 0c 00 df f9 df 74-1a 10 40 00 d4 05 7c 00  .......t..@...|.
000cfc54  10 01 00 00 ac 22 2a 00-00 00 00 00 b7 a9 a8 04  ....."*.........
000cfc64  00 00 00 00 10 01 00 00-80 30 b1 00 24 00 00 00  .........0..$...
000cfc74  01 00 00 00 00 00 00 00-00 00 00 00 30 00 00 00  ............0...

'hola' esta en la pila como tercer parametro, empujaste esos 4 caracteres cuando lo que necesitas empujar es un PUNTERO a una CADENA (serie de caracteres con su 0 terminador).

Despues tenes un stack overflow, procesas WM_INITDIALOG y al llamar a SetDlgItemText generas un WM_COMMAND, este lo procesas saltando de nuevo a .proceso ... y asi hasta que se agota la pila, no saltes a proceso desde .funcion y pensa de nuevo la logica del programa.

Aca algo al respecto:
https://groups.google.com/forum/#!topic/comp.lang.asm.x86/t3MPZkJ8kCc

Insisto: no se puede correr cuando no se sabe gatear ... tenes que empezar desde cero.

En la linea 9 estas asignandole a x la direccion de memoria donde se encuentra la cadena "101010101" (ademas eso genera un memory leak, la memoria antes reservada no fue liberada y no hay mas referencias a ella) por eso despues cuando intentas escribir sobre la cadena da error, seguro que la misma esta en la sección de datos de solo lectura.



Klixz: lee las preguntas con atencion por favor.

uy gracias!!! corregi algo pero no del todo alguna idea para seguir avanzando?

Si, aplica todo lo que te dije en el mensaje anterior, con eso sin duda podes hacerlo funcionar tal y como ya hice yo.

PD. Seguis sin pasarle el HANDLE devuelto por FindFirstFile a FindNextFile. Seguis usando 13 como magic number en la primera llamada a WriteConsole. Y FindNextFile no retorna INVALID_HANDLE_VALUE cuando falla sino 0, su tipo de retorno es booleano. No te acostumbres a usar EBX, no podes modificar su valor sin preservarlo como indica la convencion de llamada stdcall.

Tu programa ya es de consola, no hace falta llamar a AllocConsole.

¿De donde sale 13? No podes saber de antemano el tamaño de la cadena que contiene los nombres de los archivos/directorios ... ahi tenes lstrlen importada, usala.

¿Que estas tratando de comprobar si retorno correctamente? ¿FindFirstFile o WriteConsole? Si es la primera entonces el codigo esta mal, no podes hacer el cmp DESPUES de llamar a WriteConsole ya que esta igual que todas las funciones que retornan un valor va a hacerlo en EAX y va a sobreescribir el valor que retorno antes FindFirstFile. Incluso aunque no retornara nada, tenes que conocer la convencion de llamada stdcall, en la misma se especifica que EAX es un registro volatil y no preservado, es decir que cada funcion puede cambiarle el valor y retornar a la funcion llamadora sin restaurarlo al valor que tenia al ser esta funcion llamada.

Justamente ligado a lo anterior el primer parametro de FindNextFile es un HANDLE, el que devuelve FindFirstFile mas precisamente, no una cadena.

BOOL WINAPI FindNextFile(
 _In_   HANDLE hFindFile,
 _Out_  LPWIN32_FIND_DATA lpFindFileData
);

Tambien tenes que comprobar el valor de retorno antes de tratar de trabajar con lpFindFileData, eventualmente la funcion falla cuando no hay mas archivos/directorios.

La etiqueta Exit no tiene codigo, asi que ejecuta lo que sea que haya en memoria, ponele un ret al menos (tambien tenes importado ExitProcess, podrias usarlo).

¿Viste la cantidad de errores en tan poco codigo? Por eso repito: mirate los hilos con chincheta entonces, tenes que leer mucho para pasar de hacer copy/paste.

Mirate los hilos con chincheta entonces, tenes que leer mucho para pasar de hacer copy/paste.