Mensajes

¿El output del programa es una X cantidad de imagenes por segundo? Entiendo que sos capaz de capturar unas 95/96 imagenes por segundo, si esto es correcto entonces podrias capturar todas esas imagenes en memoria (96 * 240 * 360 * 2 son un poco menos de 16 MB) y despues descartar - no escribirlas en disco - las que sean necesarias para llegar al FPS configurado. El bucle lo que haria es capturar sin parar y al llegar al numero de FPS por segundo segun el hardware con lo que hay en memoria se estableceria el output (imagenes 1, 20, 50, 70, etc. por poner un ejemplo).

Seria mucho mejor que describieras el problema que estas tratando de resolver en lugar de la solucion 

¿Estas tratando de hacer algo que requeriria un S.O. de tiempo real? En los S.O. modernos que solemos usar casi todos no tenes posibilidad de asegurate que algo se vaya a ejecutar en X tiempo, son multitarea, tu programa se ejecuta junto a muchos otros  ... y cuando llamas a Sleep le das prioridad a otros procesos explicitamente.

http://en.wikipedia.org/wiki/Real_time_os

[real]

Si, no lo niego, pero a lo que me refiero es que programas viejitos que aqui me ayudaron a hacerlos, todavía me funcionaron en windows 7 por ejemplo, no he usado windows 8, porque salio la reparación que es windows 8.1, y tiene demasiadas cosas que no me interesan, prefiero la version mas simple como windows 7

Entonces entiendo que acordaremos en que esto es incorrecto: "windows xp es lo mismo que windows 7 pero con un escritorio diferente....". Tache lo completamente superfluo e irrelevante.

Hay programas hechos en C que son detectados rapidísimo... incluso cuando los compilas con Visual Studio de inmediato son detectados e incluso windows te manda un mensaje de alerta

¿Son detectados por que o quien? ¿Que puede llegar a tener que ver esto? En las detecciones por firma el lenguaje usado es irrelevante, se hace la firma y punto, si hablamos de heuristica un programa en assembly sin importaciones es muy sospechoso y si hablamos de comportamiento el lenguaje tambien es irrelevante. En definitiva no diste ningun ejemplo pero si te pusiste a divagar de manera escandalosa ... si queres te pasas por el subforo de ensamblador que modero y nos das un ejemplo real.

Compilandolo con VC++ tenes estas advertencias y/o errores:

(40) : warning C4552: '+' : operator has no effect; expected operator with side-effect
(42) : warning C4552: '+' : operator has no effect; expected operator with side-effect
(26) : error C4716: 'carga' : must return a value
(39) : warning C4700: uninitialized local variable 'num' used

windows xp es lo mismo que windows 7 pero con un escritorio diferente...

No, no es asi, hubieron muchos cambios en el Kernel.

y usando ensamblador windows se queda inofensivo

Te invito a que des algun ejemplo de algo que puedas hacer en ensamblador y no en C/C++ con lo cual "Windows quede inofensivo". Te recomiendo leer sobre el modo protegido ... asi al menos estaras actualizado hasta los 386.

De nadas 

De nadas 

El codigo esta bien en principio y en mi maquina funciona, fijate cual es el estado del driver beep (sc query beep), tiene que estar cargado en memoria para que escuches el beep. Siempre comproba el retorno de las funciones y usa GetLastError donde corresponda.

Hay algo que deberias cambiar y es la convencion de llamada de los punteros a funcion, practicamente siempre deberia ser __stdcall (WINAPI) al ser la API de Windows (por defecto es C); eso lo consultas en la MSDN facilmente.

Trata de hacer coincidir el puntero a funcion, en su tipo de retorno, convencion de llamada y parametros. Ej.:

ExitProcess

Código (c) [Seleccionar] Expandir

typedef VOID (__stdcall *punteroExitProcess)(UINT);


Beep function

Remarks

A long time ago, all PC computers shared a common 8254 programable interval timer chip for the generation of primitive sounds. The Beep function was written specifically to emit a beep on that piece of hardware.

On these older systems, muting and volume controls have no effect on Beep; you would still hear the tone. To silence the tone, you used the following commands:

net stop beep

sc config beep start= disabled

Since then, sound cards have become standard equipment on almost all PC computers. As sound cards became more common, manufacturers began to remove the old timer chip from computers. The chips were also excluded from the design of server computers. The result is that Beep did not work on all computers without the chip. This was okay because most developers had moved on to calling the MessageBeep function that uses whatever is the default sound device instead of the 8254 chip.

Eventually because of the lack of hardware to communicate with, support for Beep was dropped in Windows Vista and Windows XP 64-Bit Edition.

In Windows 7, Beep was rewritten to pass the beep to the default sound device for the session. This is normally the sound card, except when run under Terminal Services, in which case the beep is rendered on the client.

Creo que por las vias normales el ejecutable siempre es el primer parametro (argv[0]) pero es posible llamar a CreateProcess y que no sea el caso ... igual podes comparar y si la linea de comandos no contiene a la imagen asumir que desde el primer caracter es argv[1] ...