No me quiero anticipar pero segun fuentes no oficiales una vez mas volvio a ganar el MAS:


 

Windows 7 esta obsoleto, Microsoft ya no le da soporte.

De nada.

Y lo seguira haciendo siempre que tengas un bucle continuamente ejecutando codigo.


Por lo de arriba y con un Sleep esta solucionado en un simple programa de ventanas.


Ah, bien, entonces busca otro ejemplo de OpenGL que si funcione a tu gusto y listo, todo solucionado ... o no.

¿Que input y animaciones? ¿Eso se supone que esta en el codigo de arriba?


Sera un problema de OpenGL entonces. ¿Es acaso la tecnologia adecuada para un "visualizador de imagenes"?

https://stackoverflow.com/questions/5999555/opengl-on-windows-uses-tons-of-cpu-when-swapbuffers-is-called-on-a-renderthread

Llamar a glFlush y glFinish como dicen ahi antes de SwapBuffers reduce a la mitad el consumo de CPU en mi maquina (de 5%/6% a 2%/3%).


Pero si ese codigo no hace nada ... en fin.

¿Pero hiciste lo que te dije? ¿Pusiste la llamada al Sleep? Hacelo y despues me contas.

Lo que pasa es que ejecutas continuamente DrawGLScene y SwapBuffers, ponele un Sleep(1); justo despues.

¿Que valor tiene EBX? Indefinido. ¿A donde apunta EBX? Nadie lo sabe.

Asumo que estas trabajando en Windows aunque no lo dijiste. Ni bien arranca el programa, mucho antes del entry point con el WinDbg puedo ver:

ntdll!LdrpDoDebuggerBreak+0x30:
00007ffe`c765119c cc              int     3
0:000> r ebx
ebx=272000
0:000> dd @ebx l1
00000000`00272000  00010000

Lo que sucede al parecer es que la direccion a la que apunta EBX contiene el valor 0x10000=65536, es un puntero a una estructura (el PEB, Process Environment Block) pero igual el planteamiento de usar un registro con un valor indefinido es un error de logica (podria apuntar a 0 u otra direccion invalida provocando una excepcion no controlada). De esos cuatro bytes solo modificas el primero haciendo que el valor cambie a 0x10004=65540, despues al solo usar el primero tambien en la multiplicacion el resultado es correcto.

Esta es la razon ultima por la cual al depurar ese valor es 0x10000  Justamente el tercer byte del PEB indica si un proceso esta siendo depurado o no BeingDebugged. No deberias escribir en el PEB ...

0:000> dt ntdll!_peb
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   +0x002 BeingDebugged    : UChar
   +0x003 BitField         : UChar
   +0x003 ImageUsesLargePages : Pos 0, 1 Bit
   +0x003 IsProtectedProcess : Pos 1, 1 Bit
   +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit
   +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit
   +0x003 IsPackagedProcess : Pos 4, 1 Bit
   +0x003 IsAppContainer   : Pos 5, 1 Bit
   +0x003 IsProtectedProcessLight : Pos 6, 1 Bit
   +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit

PD. EBX es un registro a preservar en STDCALL. Al final no estas multiplicando dos registros, estas multiplicando el registro EAX por un byte al que apunta el registro EBX.

Hay un subforo de ASM donde deberia ir esta pregunta: https://foro.elhacker.net/asm-b84.0/
Lo reportare y con suerte alguien lo movera.

O cambias el proyecto a ANSI, o llamas explicitamente a FindWindowA o mejor simplemente usas literales de cadena anchos asi: L"CADENA".

De nada.

EdePC: lo encontre justo antes de irme a dormir poniendo funciones de consola c en Google, parecia util a simple vista al menos