SoloCodigo

Y de paso dejo esta otra preguntita:

¿Y por los que no trabajaban en Microsoft? ¿Quien pide? ¿Los que trabajaban en Microsoft si lo merecen y otros no?

Estoy haciendo un programa Anti-Cheat para el famoso juego Counter-Strike ( v1.6 )
y ya lo tengo casi terminado hasta que se me ocurrio eso de desaparecer el proceso por 10-15 segundos y despues de ese tiempo que vuelva a aparecer asi los programas llamados "cheats" no funcionarian ya que inyectarian tarde.

Entonces la mencion del taskmanager solo sirve para confundir ya que no era ese programa tu objetivo.

Mucho peor entonces, o haces lo mismo para cada uno de esos "cheats" o creas una DLL generica que se tiene que inyectar en todos los procesos ... o un driver de modo Kernel.



Con esos pocos datos que das no te puedo decir nada mas.

Podes usar hilos o las extensiones asincronas de Winsock.

Bueno, funciona al final, la verdad que no se decir con precision que fue, quizas que instale el windbg y termine usando el drwatson...en fin

El WinDbg no se "instala", me refiero a que la instalacion no hace mas que crear un directorio y copiar unos archivos ...

Es un ensamblador de alto nivel como su nombre lo indica  

Vale la pena mencionar que cuando queres instalar estos programas te avisan claramente de que llevan incorporada esta mi..da, ahora me acorde que el DaemonTools tambien lo trae aunque es opcional su instalacion, el BSPlayer tiene una comprobacion y sino esta esa porqueria en ejecucion no funciona.

El WhenUSave es una mierda, no dañina que yo sepa que instalan entre otros programas el BSPlayer, mi recomendacion: usar VLC u otro programa  

Si, son incompatibles, SEH esta pensado para C y no es parte del lenguaje (ni de C ni de C++) sino que es la forma de capturar excepciones en Windows, por eso te da warning cuando usas objetos.

Me topé con sin querer con este articulo:
http://en.wikipedia.org/wiki/Singularity_%...ating_system%29

Habla de un SO de investigacion que hizo Microsoft que mayoritariamente está escrito en C#. Para cambiar los opcode de CIL a los de X86 usaron otro proyecto que desarollo el mismo grupo Bartok
http://research.microsoft.com/act/

Si, ya hace bastante que estan con eso, creo recordar un par de discuciones del 2005 y 2006 que tuvimos en el foro donde fue nombrado  

Ya lo habias cambiado para el bug anterior no ?, lo de fullscreen
tenes por ahi las lineas que le modificaste, probe el OllyDbg con FullScreen y salta todo al carajo, lindo programa este Olly.

No las tengo pero las habia buscado por ahi, no se mucho que digamos sobre DirectDraw. El OllyDbg es un depurador, limitado a modo Usuario, pero bastante comodo para empezar.

De los links la mayoria son para VC, mmm

Son todos para VC++ los enlaces que te deje, como el 90% de los recursos que podes encontrar para DirectX.

estoy casi seguro que es WXP2002 con SP2 como dijo Geo, yo tengo el mismo.

Realmente no se de donde salio eso de XP 2002 ... Yo tengo el Windows XP Service Pack y es el build 2600 ... copyright 1981-2001, es la version 5.1 de NT. Pero no hay algo oficial llamado XP 2002 que yo sepa.

Agrego que podes probar usando un depurador de modo Kernel tipo SoftIce que no necesita otra maquina y sino por puerto serie o firewire (1394) con el WinDbg y dos maquinas.

Lo principal es que tenes que tener dos maquinas en red, una donde este el problema y otra con el depurador y el codigo. En la primera tenes que ejecutar un programa del depurador que hace las veces de servidor y desde la segunda te conectas con el IDE.

http://www.codeproject.com/debug/remotedebug.asp

http://www.eastcoastgames.com/articles/MSVCRemoteDebug.htm

http://msdn.microsoft.com/library/default....pplications.asp

http://www.softlookup.com/tutorial/vc++/vcu05fi.asp

http://www.programmersheaven.com/2/FAQ-DIR...tX-Applications

Existe un caso donde podría ser un poco más rápido llamar a la funcion "directa"

Cabe destacar que citas un texto donde pido un ejemplo real (me refiero a los dos funciones X e Y) y el caso que presentas es HIPOTETICO.

Bien, pese a ser hipotetico te aclaro que es despreciable cualquier comprobacion que se pueda hacer, si es que hay alguna ya que generalmente no hay y lo que si hay es transformacion de algunos parametros como por ejemplo cadenas ANSI a Wide y finalmente a UNICODE_STRING para llamar al Kernel que es donde se hacen las comprobaciones y se hacen SIEMPRE vengan los datos desde donde vengan (siempre que sea desde modo Usuario).

En el caso de la NTDLL.dll existe para poder proveer a diferentes subsystems de unas cuantas funciones y mas que nada para pasar a modo Kernel. Esta DLL es usada tanto por Win32 (Kernel32, User32, Gdi32, etc) como por el subsystem POSIX, el subsystem OS/2 y cualquier otro que Microsoft se inventara. Es una de las pautas de diseño que decidieron usar en su momento, asi es que podes usar fork en el subsystem POSIX (esta implementado con funciones de la NTDLL.dll) y no desde el subsystem Win32.