Mensajes

Saludos, quisiera saber si existe un operador por defecto en una clase c++ y si se puede sobrecargar.

Lo que tengo es una clase Cadena que almacena un array char *texto, declarado privado.

Pero cuando necesito usar ese texto en una función típica de API de Win32 necesito pasar el puntero al array como es lógico y para ello uso el operador(), pero no me parece elegante, ejemplo:

Cadena Titulo("Hola");
SetWindowText(hWnd,Titulo());

Quisiera conseguir esto:

Cadena Titulo("Hola");
SetWindowText(hWnd,Titulo);

Puede que haya que sobrecargar el Operador= pero no se como diferenciarlo del operador de asignación que ya está sobrecargado.

Gracias, un saludo.

Saludos, tengo un programa que muestra datos de una DB Access a través de ADO. Uso un proveedor "Provider=Microsoft.Jet.OLEDB.4.0;". El problema es que utilizo un:

command->CommandText = "DROP VIEW Niveles";
commando->Execute(NULL, NULL, ADO::adCmdText | ADO::adExecuteNoRecords);

Para eliminar una Consulta y volver a Crearla con otro argumento:

command->CommandText = "CREATE VIEW Niveles AS SELECT ...";
commando->Execute(NULL, NULL, ADO::adCmdText | ADO::adExecuteNoRecords);

Todo se ejecuta bien, pero cuando intento abrir un RecordSet que incluye dicha Consulta me da error en Open:

Recordset->Open("SELECT ... FROM Niveles ...", (IDispatch *)Connection, ADO::adOpenKeyset, ADO::adLockOptimistic, ADO::adCmdText);

Al iniciar el programa la primera iteracción se ejecuta bien, pero a la segunda o tercera vez que ejecuto el código salta error en Recordset->Open, y marca error tabla no existe, debido a que uso una consulta que justo antes he borrado y creado de nuevo.

Si en el código salto la parte de borrar y crear la consulta me funciona bien, por lo que supongo que tiene que ver con borrar la consulta e intentar usarla antes de que se vuelva a crear. Esta afirmación se ve reforzada cuando al utilizar un Sleep(10000); o si creo puntos de interrupción, el programa funciona y obtiene los datos tantas veces como sea necesario.

Si alguien puede darme alguna pista de por donde puedo solucionar el problema.

Gracias, un saludo.

Yo uso la opción 2:

Esta es la declaración del punto de entrada de la dll.
BOOL __stdcall DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)

Y esta es la declaración de la función a exportar.
__declspec(dllexport) int __stdcall Funcion1()

La llamada desde Access VBA la realizo con la declaración:
Public Declare Function Funcion1 Lib "BibliotecaDLL.dll" () As Long
Tal y como declaro cualquier función de la API de Win32 Kernel32, user32, etc.
En Access me lanza el error 48 no se encontró el archivo y registrando la dll en Windows me sigue diciendo que no encuentra el punto de entrada de la dll. Si uso LoadLibrary me devuelve 0, creo que no carga la dll y no se porqué. Muchas gracias.

Saludos, estoy intentando crear una dll básica en Visual Studio 2013 concretamente en Visual C++ usando un proyecto Win32 dll, pero el proyecto resultante me genera un archivo que luego no puedo llamar desde VBA (Access). Intento registar la dll con regsvr32.exe pero me dice:
Se cargó el módulo "..\BibliotecaDLL.dll pero no se encontró el punto de entrada DllRegisterServer. Asegúrese de que "..\BibliotecaDLL.dll" es un archivo DLL u OCX válido e inténtelo de nuevo.
El proyecto define el BOOL APIENTRY DllMain(..) y una función que he incluido int __declspec(dllexport) Funcion1(). Si alguien puede ayudarme con este problema. Muchas gracias.

Gracias MCKSys Argentina, trabajaré en ello.

Saludos, estoy trabajando en un Desensamblador en C++, la cuestión es que comienzo a desensamblar el código desde el Entrypoint y voy decodificando instrucciones, cuando encuentro un CALL salto a la dirección y cuando llega el RET vuelvo al lugar donde se llamaba al CALL.

Cuando no encuentro más código nuevo comienzo a analizar los saltos condicionales JXX hasta recorrer todo el código binario. Pero pronto me dí cuenta que esta forma de desensamblar un EXE no era correcta.

El típico programa Windows cuando crea la Ventana principal del programa pasa la dirección de memoria de la función que se encargará de atender los eventos. Y seguro que hay otro tipo de situaciones que no estoy contemplando.

Si alguien puede ayudarme sobre cómo desensamblar un ejecutable, tengo como referencia el PE Explorer 1.99 pero no llego a entender como obtiene el Desensamblado del EXE.

Muchas gracias.

Gracias, desconocía el significado de las estructuras IMAGE_DATA_DIRECTORY y IMAGE_IMPORT_DESCRIPTOR, por eso no entendía como resolver el problema.

Muchas gracias por vuestra paciencia y por la información.

Gracias por responder, los ejemplos me llevan al puntero que según entiendo queda después de que Windows sustituya User32!MessageBoxA a una posición de memoria, pero esto es algo que me servirá en un futuro, pero ahora solo necesito saber como Windows obtiene la información "User32.dll" y "MessageBoxA". Entiendo que Windows lee el Call y consigue obtener la cadena "MessageBoxA" siguiendo los Offset.

Explicado de otra manera, estoy programando un Desensamblador que cuando lee una instrucción Call consigue llegar a través de los diferentes Offsets a la posición del EXE donde se almacena el nombre de la función dll "MessageBoxA", pero no entiendo cuales son los cálculos que realiza Windows o cualquier Desensamblador comercial para obtener el texto "User32.dll".

Muchas gracias por vuestra colaboración.

Saludos, estoy trabajando en un programa de Ensamblador/Desensamblador pero no consigo entender como trabajan las llamadas CALL a DLL. En un EXE generado por MASM que solo tiene el siguiente código:

.data
Titulo db "Mensaje",0
Texto  db "Hola Mundo",0
.code

start:
    invoke MessageBox,0 , offset Texto, offset Titulo,1
    invoke ExitProcess,eax

end start

Utilizo PEExplorer para Desensamblar el código Generado y las 2 llamadas a dll aparecen como:

Direccion     Bytes(Hex)
0040100E  E807000000                        call   jmp_user32.dll!MessageBoxA
00401013  50                                      push   eax
00401014  E807000000                        call   jmp_kernel32.dll!ExitProcess
----------------
0040101A  FF2508204000                     jmp   [user32.dll!MessageBoxA]
00401020  FF2500204000                     jmp   [kernel32.dll!ExitProcess]

Obteniendo las direcciones 402000h y 402008h de la sección .rdata. Mirando en dicha sección obtengo la siguiente Import Table/Import Address Table:

Direccion     Bytes(Hex)
00402000  76200000                                         dd   ??
00402004  00000000                                         dd   00000000
00402008  5C200000                                         dd   ??
0040200C  00000000                                         dd   00000000
00402010  54200000                                         dd   00002054h
00402014  00000000                                         dd   00000000h
00402018  00000000                                         dd   00000000h
0040201C  6A200000                                         dd   0000206Ah
00402020  08200000                                         dd   00002008h
00402024  4C200000                                         dd   0000204Ch
00402028  00000000                                         dd   00000000h
0040202C  00000000                                         dd   00000000h
00402030  84200000                                         dd   00002084h
00402034  00200000                                         dd   00002000h
00402038  00000000                                         dd   00000000h
0040203C  00000000                                         dd   00000000h
00402040  00000000                                         dd   00000000h
00402044  00000000                                         dd   00000000h
00402048  00000000                                         dd   00000000h
0040204C  76200000                                         dd   00002076h
00402050  00000000                                         dd   00000000h
00402054  5C200000                                         dd   0000205Ch
00402058  00000000                                         dd   00000000h
0040205C  B101                                                dw   01B1h
0040205E  4D657373616765426F784100         db   'MessageBoxA',0
0040206A  7573657233322E646C6C00            db   'user32.dll',0
00402075  00                                                db   00h
00402076  9B00                                                dw   009Bh
00402078  4578697450726F6365737300            db   'ExitProcess',0
00402084  6B65726E656C33322E646C6C00         db   'kernel32.dll',0
00402091  00                                                db   00h

Lo que yo entiendo es que en la dirección 402000h esta el desplazamiento 2076h que me lleva a un Word que no se para que sirve (seguro que no esta ahí por casualidad) y al Texto del nombre de la función "ExitProcess" pero desconozco como llego a obtener "Kernel32.dll" aunque deduzco que hay que llegar a la dirección 402030h donde obtengo el desplazamiento 2084h que es donde está el Texto de la DLL. Si alguien puede explicarme como se estructura estas Tablas. Entiendo que Windows cuando carga un ejecutable en memoria Traduce todo esto a posiciones de memoria donde está cargada la DLL y que habrá muchas cosas más que desconozco, pero de momento me basta con poder generar a mano con un programa C++ un Ejecutable con su sección .rdata y sus llamadas a DLL tal y como lo hace MASM. Muchas gracias.