Yo creo en las comas 

Efectivamente eso es lo que pasa con su ejemplo compilado en 32 bits, los parametros que la funcion necesita son de 4 y no 8 bytes pero asi como en Windows en modo protegido en 32 bits los parametros son todos de 4 bytes en Windows en modo largo en x64 los parametros son todos de 8 bytes. Por eso le dije que en principio usara los tipos de parametros de la funcion y de ultima usara PVOID que al menos es el tamaño de un puntero y este se debe poder pasar en un registro y pila "nativamente".

En realidad si podes llamar a CreateProcessA sin problemas, cada parametro en pila ocupa 64 bits de por si, aunque despues la funcion llamada solo lea los primeros 8, 16 o 32 bits. Si bien hay una sutil diferencia en el codigo generado en ambos casos cada parametro ocupa 8 bytes (notese como el  quinto - 1 - y sexto parametros - 0x1230 - se mueven como DWORD o QWORD pero el siguiente parametro siempre esta a la misma distancia, 8 bytes):

; 45   : ((BOOL (__stdcall *)(LPCSTR, LPSTR, LPSECURITY_ATTRIBUTES, LPSECURITY_ATTRIBUTES, BOOL, DWORD, LPVOID, LPCSTR, LPSTARTUPINFOA, LPPROCESS_INFORMATION))CreateProcessA_fn)
; 46   : (NULL, argv[1], NULL, NULL, TRUE, 0x1230, NULL, NULL, &si, &pi);
mov	 eax, 8
imul	 rax, rax, 1
lea	 rcx, QWORD PTR pi$3[rsp]
mov	 QWORD PTR [rsp+72], rcx
lea	 rcx, QWORD PTR si$5[rsp]
mov	 QWORD PTR [rsp+64], rcx
mov	 QWORD PTR [rsp+56], 0
mov	 QWORD PTR [rsp+48], 0
mov	 DWORD PTR [rsp+40], 4656 ; 00001230H
mov	 DWORD PTR [rsp+32], 1
xor	 r9d, r9d
xor	 r8d, r8d
mov	 rcx, QWORD PTR argv$[rsp]
mov	 rdx, QWORD PTR [rcx+rax]
xor	 ecx, ecx
call	 QWORD PTR CreateProcessA_fn$2[rsp]

; 48   : ((BOOL (__stdcall *)(PVOID, PVOID, PVOID, PVOID, PVOID, PVOID, PVOID, PVOID, PVOID, PVOID))CreateProcessA_fn)
; 49   : (NULL, argv[1], NULL, NULL, (PVOID)TRUE, (PVOID)0x1230, NULL, NULL, &si, &pi);
mov	 eax, 8
imul	 rax, rax, 1
lea	 rcx, QWORD PTR pi$3[rsp]
mov	 QWORD PTR [rsp+72], rcx
lea	 rcx, QWORD PTR si$5[rsp]
mov	 QWORD PTR [rsp+64], rcx
mov	 QWORD PTR [rsp+56], 0
mov	 QWORD PTR [rsp+48], 0
mov	 QWORD PTR [rsp+40], 4656 ; 00001230H
mov	 QWORD PTR [rsp+32], 1
xor	 r9d, r9d
xor	 r8d, r8d
mov	 rcx, QWORD PTR argv$[rsp]
mov	 rdx, QWORD PTR [rcx+rax]
xor	 ecx, ecx
call	 QWORD PTR CreateProcessA_fn$2[rsp]

Si podria tener problemas con tipos de coma flotante que se pasan en otros registros pero no recuerdo ninguna API de Windows que los use.

---

Y de cualquier manera si coincido en que es algo a evitar de ser posible.

Ahh, claro, tiene su logica pero como solo se exportan las funciones en ANSI en un PE no hizo falta la pareja de GetProcAddressA/W 

hFunc=(int64_t)GetProcAddress((HMODULE)hLib,"WriteConsoleA");

https://docs.microsoft.com/en-us/windows/console/writeconsole

Me alegro si conseguiste hacerlo funcionar

Las funciones que reciben cadenas como parametros en realidad terminan en A si son ANSI o en W si son widechar, asi que hasta ahora tu GetProcAddress devuelve 0 siempre. Con eso te deberia funcionar relativamente bien en x64 aunque no estas especificando la convencion de llamada que en este caso deberia ser stdcall.

No entiendo muy bien la razon de usar un entero de 64 bits con signo en lugar de un void * para hFunc (idem para los parametros, al menos que el entero sea sin signo y que sea de 4 bytes para codigo de 32 bits) y %x deberia ser %p para corresponderse con un puntero al usar printf.

¿hFunc es un puntero a funcion y despues se le asigna el valor de retorno de WriteConsoleA?

En principio yo lo hubiera hecho asi:

BOOL b = ((BOOL (__stdcall *)(HANDLE, const VOID *, DWORD, LPDWORD, LPVOID))hFunc)(hStdout, "coso", 5, 0, 0);

O para generalizarlo y que funcione siempre con el tamaño de un puntero como parametro:

((BOOL (__stdcall *)(PVOID, PVOID, PVOID, PVOID, PVOID))hFunc)((PVOID)hStdout, (PVOID)"coso", (PVOID)5, 0, 0);

Como la funcion maneja los parametros depende de la convencion de llamada que especificara los registros y/o la pila para acceder a ellos.

Que no siente precedente pero estoy totalmente de acuerdo con Machacador.


No escuche nada semejante asi que por favor aporta una fuente que lo sostenga.

No, no se hacen tareas ajenas.

Lamentablemente no hay vacuna contra la ignorancia.

Bueno, trata de recordarlo para la proxima y no hacer tareas ajenas.

Yo soy desarrollador de modulos de modo Kernel desde hace mas de 15 años para Windows y desde hace mas de 2 años para macOS y segun mi modesta opinion el iokit de Apple es un chiste malo comparado con el WDM, no tiene ni para empezar.