Y el niñato soy yo que se comporta como niño al responder, hablando cosas de Dioses, "h4x0r", y así, en lugar que argumentar algo más valido, si claro. Pero bueno prefiero programar mis interfaces en Delphi o C#, VB.NET que usar libreria con tantos errores que he visto.

¿Y el punto importante aqui es que sea multiplataforma? No es claro cuando alguien quiere usar Win32 saber que está trabjando bajo Windows? Yo no sé porqué incluso lo mencionas. Además de decir que la gente no deberia quejarse por "unos cuantos MB".

Pero bueno para alguien que evade el Win32 para simples tareas en lugar de aprender como Windows funciona, me es suficiente saber que tipo de scriptkiddie lo dice. Y sí, ve a quejarte como niñito lloron.

El punto es que esto es claramente asunto de la pila, la gente de esas practicas deberia incluir los ejecutables con los que se trabajara, sino pues que programen en ensamblador y evitar este tipo de situaciones.

Tan "potente" que te agrega MB's para un simple ejecutable y además que debes de comprar la licencia sino debes
de hacer tus programas open source.


Podes publicar el código para ver que errores tienes. De todos otra forma de crearlos es usando CreateWindow, cada control tiene su nombre de clase: http://msdn.microsoft.com/en-us/library/windows/desktop/bb773169(v=vs.85).aspx. Y usando CreateWindow creas el control.
Hay ejemplos en la MSDN
Usando tu propia clase:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633575(v=vs.85).aspx
Ejemplo de un "edit":
http://msdn.microsoft.com/en-us/library/ms926200.aspx

¿Podes decirnos que tiene que ver con la pregunta?

@Basurian:
Deberias de revisar esas practicas ya que deberia de hablar acerca de qué configuraciónes se deberian pasar al compilador para que los ejecutables se generen como se espera. Para mi que practicando con programas generados desde lenguajes de alto nivel no es muy practico, ya que se esta suponiendo que se obtendrá un determinado código generado por el compilador.

Compiladores son libres de generar el código como mejor convenga, dependiendo de las configuraciónes (debug, release, o alguna personalizada) generarán en la pila alineamientos, rellenos o incluso comprobadores para evitar eso mismo que estas haciendo. A pesar de las configuraciones algunos generan optimizaciónes donde el usuario nisiquiera es consiente de eso y muchas situaciónes como esas...

No sé a qué te refieres...

Sí, dejar de programar malware en VB y aprender C/C++.

La mayoria de "reversers", me refiero a los que aprenden primero a depurar programas con algun lenguaje de alto nivel como VB6 y luego intentan aprender un verdadero lenguaje como C/C++ es normal que recomienden/usen variables DWORD, DWORD64 para almacenar punteros, ellos deberian de aprender a programar de la manera correcta.

Usando ULONG_PTR no es la unica manera, también es posible usar BYTE*/PBYTE aunque yo también me siento mejor usando ULONG_PTR.

Usando esto no es lo correcto:
IMAGE_SECTION_HEADER.Name es de tipo BYTE no una cadena asi que es totalmente valido que el nombre de la sección contenga
valores nulos o la longitud del nombre sea el maximo numero de bytes, en este caso 8; strcmp retornará un valor incorrecto en esos casos
memcmp estaba bien.

Me referia a algo como esto:

#define SIZE_OF_MEMBER(Type,Member) (SIZE_T)(sizeof(((Type*)0)->Member))
 
PIMAGE_SECTION_HEADER FindPESectionByName(IN PIMAGE_NT_HEADERS NT, IN BYTE SectionName[8])
{
    if (NT &&
        SectionName)
    {
        PIMAGE_SECTION_HEADER pFirstSection;
        pFirstSection = IMAGE_FIRST_SECTION(NT);
        for (ULONG s = 0; s < NT->FileHeader.NumberOfSections; s++)
        {
            if (!memcmp(
                SectionName,
                pFirstSection[s].Name,
                SIZE_OF_MEMBER(IMAGE_SECTION_HEADER, Name)))
            {
                return &pFirstSection[s];
            }
 
        }
    }
    return NULL;
}

Es sólo una función para obtener un puntero a la sección.

-
Códigos que parsean el formato PE deberían de ser escritos bajo un manejador de excepciónes en el mayor de los casos, sino fijate el monton de programas para parsear PE/PE32+ que se cierran cuando se abren imagenes PE "malformadas".

Sí y viendo el código porqué razon necesitas el valor en AllocationSize? Ya que si primero utilizas GetFileSize y luego sobreescribes el valor retornado por GetFileInformationByHandleEx en la misma variable... En XP falla ya que GetFileInformationByHandleEx no es exportada.

No hay necesidad, podes importarla normalmente, vas a necesitar la ntdll.lib que podes encontrar en el WDK luego: propiedades -> linker -> input -> escribes el nombre. Bueno eso es para Visual studio que es el mejor para gente que esta programando para Windows.