FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Esto en vez de divertido parece ser un dolor de cabeza... jajajaja
Cada vez que aclaramos, oscurece... y termina siendo más estático de lo que me imaginaba. Ahora entiendo algunas limitaciones de los ClassHelpers. Hasta allí llegan... Para implementar herencia insertada o cosas por el estilo creo que los muchachos de codegear deberían de replantearse una buena parte del asunto. un arduo trabajo aunque, lo más difícil es decidirse a comenzar, no? Una vez que estás en camino casi nunca resulta tan complicado como parececía antes de empezar. No, no había hecho la prueba de reemplazar un método de la VMT y luego llamarlo mediante "inherited"... daba por hecho que esta función iba a buscar la VMT del ClassParent y allí resolvía el puntero a la función, pero resultó no ser así. es una lástima porque se hubiesen podido hacer cosas interesantes. Es muy peciliar el uso que se hace de la VMT. Parece ser que al final de cuentas termina siendo sólo realmente útil para la persistencia y alguna que otra cosita más. Con respecto a las llamadas (donde simplemente se hace un Jump): ... jmp dword prt [$XXXXXXXX] mov eax, eax ... Se me hace que estas direcciones de memoria (que apuntan a las funciones en cuestión) son llenadas en runtime en el LoadPackage mediante GetProcAddress. Algo similar pasa con las variables globales cuando son compiladas para usarse dinámicamente. En mi caso había una "tabla" de que saltos a funciones en los cuales estaban todos estos juntos (con rtl en runtime): abstract error tobject.initinstance tobject.freeinstance tobject.free tobject.equals tobject.gethashcode tobject.tostring tobject.dispatch handlefinally startexe halt0 registermodule finalization Volviendo a GetVirtualMethodCount, a mí tampoco me queda del todo claro. :S Sí cómo es obtenido y eso, pero exactamente porqué. Sé que juegan con punteros. Toman el final de la vmt, luego recorren las entradas buscando las direcciones de los punteos, buscan la más alta, hacen la diferencia, dividen por 4 y les da. (más magia negra!) pero porqué esos punteros y no otros? A mi entender, se basan en información que no he encontrado o no está disponible (en el orden en que es asignada (alloc) la memoria de la tabla de métodos virtuales). Es decir, SABEN con seguridad que hay un puntero que se contiguo a la tabla de métodos virtuales. |
#2
|
||||
|
||||
Cita:
Tal parece que la estructura de la VMT finaliza con el ShortString que contiene el nombre de la clase, lo cual es bastante lógico. Es información intrínseca de la VMT, pero, como es de longitud variable, en el desplazamiento vmtClassName sólo guardan un puntero a ese ShortString, así la estructura inicial permanece uniforme para todas las VMTs y rematan estas estructuras con el propio nombre de la clase. Es una técnica bastante usual colocar al final de una estructura las partes que pueden ser de tamaño variable. No lo he probado, pero entonces con esto sí podríamos saber cuántas entradas de métodos virtuales y de métodos de interfaces tiene una VMT. Ahora la pregunta sería, ¿cómo distinguir unas de otras? Y algo más de considerar: la función GetVirtualMethodCount que enlacé parece ser de una versión más reciente que la mostrada inicialmente, y en ella el algoritmo es significativamente distinto. Habrá que hacer algunas pruebas adicionales en un rato libre... Espero te alivies de los dolores de cabeza, Poyo, tómalo con calma. Son simples bytes. Me entusiasma participar con los colegas en este tipo de disertaciones. Saludos. Al González. |
|
|
|