Mmmmm... se te ha olvidado una cuestión importante: ¿para qué quieres hacer eso?.

Y te señalo por qué es importante.
Supongamos que tu idea es intentar bloquear "programas maliciosos", en este caso, lo más probable es que no sea efectivo al 100%. y te lo razono.
Imagina un programa malicioso, supera cierto nivel de carga de CPU y lo matas, ok... 1 minuto después ahí está otra vez... entonces aunque sea con interrupciones, su tarea sigue adelante, solo que más demorado en el tiempo.

Un programa malicioso, en general si está medianamente bien programado, no opera sólo, siempre están al acecho, son otros ejecutables los que lo lanzan y que 'pasan' por 'buenos', nada raro ni sospechoso en ellos se detecta... es decir el programa que ejecuta la tarea maliciosa, es 'contratado' por otro programa que lo pone en marcha (algo así como cuando alguien contrata un asesino para matar. Él que quiere que muera alguien y la persona que lo mata, si no quiere (ensuciarse las manos y arriegarse a) ser descubierto, es otra, no la misma. Más aún ni siquiera 'habla' directamente, con el que hace el 'trabajo sucio', si no que busca un intermediario...

Así, resumiendo: un programa malvado (A), tendrá una apariencia limpia, y su única tarea será arrancar otro programa (B). Es B, quien de cuando en cuando revisa si el programa que hace el trabajo sucio (C), está en marcha o no, y si no lo está lo manda ejecutar... Así si ya resulta difícil asociar B con C, mucho más A con C.

Luego en efecto matar un proceso, no es todo lo efectivo que es deseable si el objetivo de tu programación, es librarte de procesos 'maliciosos' o solo 'indeseables'. Debes investigar el padre del (proceso) mismo y a su vez al padre de ése y así respectivamente. A veces no es fácil, porque resulta difícl rastrear sin meterse a fondo en el tema. Un programa puede arrancarse, realizar alguna ejecución y luego pararse... al caso, entonces resulta conveniente consultar las tareas programadas... A veces incluso un programa descomprime de un archivo cifrado, otro y lo ejecuta... más aún imagina por ejemplo que tengo dos ficheros, un ejecutbale maligno y un fichero comprimido en zip, rar, 7z, etc... le das una orden de extracción al mismo y a su vez tras ser extraído, es autoejecutado (caso típico de instaladores, que descomprimen y/o decodifican y se ejecutan), tras lanzar esto se desvincula de su marcha y s epara, así la autoría incluso parecerá proceder de winrar, winzip, sevenzip, etc... para todo ello, como te decía debes meterte a fondo y suscribirte a eventos de carga de procesos, peor incluso así, hay virus que se las apañan, para saltarse el control del sistema...

En definitiva, según para qué lo quieras, lo que tienes es suficiente o te quedas a medias. Si por ejemplo tu idea es matar procesos de programas que mina (criptomonedas) en tu equipo (tan de moda en los últimos meses), si es abusivo, puede ser efectivo, pero si no pone el procesador a un nivel muy elevado (digamos que lo deja en un 3-7%), seguirá ahí latente... y si pretendes matar procesos que sobrepasen un 5%, básicamente te vas a cargar a todos, porque en algún momento, todos los programas alcanzan ese valor y lo superan intentasamente.

Sería más sensato, hacer estadísticas, es decir descubrir procesos que sobrepasen ciertos umbrales y registrarlos (nombre de procesos, valores alcanzados y tiempo que permanecen por encima de cierto umbral y frecuencia con que esto sucede), al tiempo consultar dicha estadística y sacar conclusiones... después de eso se supone que lo que hagas tendrá una lógica más acorde que la simpleza de matar al que 'se rebela'...

Por otro lado hay programas legítimos, que en algún momento dado pueden tener picos de trabajo y en general tiene programado que si se para se ponga de nuevo en marcha... hasta x veces, luego ya no se vuelve a cargar hasta la próxima sesión... pero como decía si es legítimo, puede que al matarlo estés impidiendo alguna acción absolutamente necesaria que podría incluso colgar el sistema o generar un reinicio.

...hay más tela que cortar al respecto, pero tampoco es plan de que te sientas atosigado, con toda la panoplia de características...

Uhmmmm... el texto es insuficiente no da detalles precisos, resulta vago, veo de descargarme el vídeo para verlo en otro momento con tiempo... peor creo que no van en la 'buena dirección'...

La solución tiene que ser HARDWARE, de fábrica, nada de webs, ni correos ni leches. Todas las capas que se quiera encima, pero si al fondo no está basado en HARDWARE, siempre será penetrable.

Imagino que el "programo" siendo de La India, estará diseñado y programado íntegramente por hindús... esos que se rifan muchas empresas, por... ¿cómo era?... ah sí, sólo por ser de La India (como si por ello, todo hindú fuera a ser una encarnación del propio Ramanujan).

"Estamos trabajando para..."

En España, lo llamamos "bajada de pantalones" (para poner el culo y que te den por ahí)...

Pués no... Hoy día los motores de explosión se utilizan para los vehículos... si el día de mañana alguien encuentra una utilidad alternativa aunque no sea eficiente, los usará, al tiempo habrá (se crearán) equipos especializados al propósito nuevo, que se ajustan específicamente a ello, entonces que luego los fabricantes de motores de explosión, hagan un giro a sus diseños apra que valgan tanto para vehículos como para esa nueva iniciativa, es tetgiversar el diseño del mismo, para en efecto la demanda alcance a todos y el precio se eleve, pagando todos la demanda de otros... y que en efecto, jamás será igual que una solución dedicada al efecto.

Un ejemplo idéntico fue el caso cuando países como Brasil decidieron usar alcohól de cerales como combustible... ¿os acordais cual fue el resultado?????. Para los que no,... pués que el precio de los cereales para la alimentación se disparó...

No es tan difícil de entender jolín...

No. No es suficiente, el problema es del procesador, no del navegador, el navegador a lo sumo puede complicarlo. Puedes eso sí desactivar javascript, pero es que es prácticamente imposible moverse por la red hoy día sin javascript, florece como los hongos... Pero al desactivarlo en el mejor de los caso, muchos scripts no podrán ejecutarse (por ejemplos ver vídeos), en el peor ni siquiera logras que aparezca la página si dicha página está basada de principio a fin en javascript...

Solución efectiva no ahí... de momento, lo que he leído que están haciendo parches (software), para separar el área de memoria restringida en el Kernel, en 2, dejando fuera el área del usuario... todo ello (según se realice) puede conllevar mucha sobrecarga al tener que estar cargando y descargando zonas concretas... puede haber pérdidas de rendimiento o no, ya veremos como lo resuelven a nivel S.O. Piensa que una solución a nivel del S.O. no puede aceptarse como una solución real, el S.O. no puede cubrir con igual eficacia, un asunto que realmente compete al procesador. Una intrusión en un equipo, podría explotar la vulnerabilidad 'deshaciendo' los cambios aplicados por el S.O.  por eso digo que no es una solución real, solo un parche... vamos como pegar un chicle bajo e depósito de gasolina de un vehículo en medio del desierto... un parche, valdrá para muchos, pero no para todos.

La solución definitiva, creo que jamás llegará, porque eso supone un remplazo del procesador... y ... ¿quién cree que Intel, AMD, etc... van a cambiar casi todos los procesadores del planeta???... en realidad deberían, son productos defectuosos de fábrica... pero tocará 'ajo y agua', y 'contentos' si el S.O. logra sacar algo eficaz para tu versión...

Mira a ver si tienes también el fichero solution (*.sln), áabrelo con el bloc de notas y revisa la versión precisa que se requiere:
Por ejemplo, aquí un proyecto en C# para VS2005, se encabeza así las 2 primeras líneas:
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005

Al abrirlo con el VS2010, tal como te señala Elektro, sale el asistente de conversión (Microsoft Visual Studio Version Selector), y te solicita si deseas hacer copia previamente (y dónde), al final de la conversión te muestra un resumen del resultado... Si no tienes el *.sln, no importa, también es posible desde el *.csproj. Durante la conversión, hace lo propio con los *.cs, directamente cuando no lo abre es porque no portan info de versión, sólo código...

Si te dan problemas tal vez, no sean ni VS2008 ni VS2005, y sea VS2003, quizás deba primero ser convertido a una versión más actual y desde ahí a VS2010 (y si luego instalas otra versión más reciente, desde esa a la nueva)...

Debes comprobar antes del "switch(ficha){" que la casilla esté libre...

Para el tablero deben usarse 3 valores, con estos 2 significados:
- Casilla vacía: por ejemplo un espacio en blanco. Es lo que debe haber al comienzo del juego.
- Casilla ocupada: casilla ocupada. Y para ello se usan dos valores '0' y 'x', cada una identifica un jugador distinto.

Por tanto cuando el jugador elija una casila, antes de intentar asignar el valor de casilla ocupada, debe consultarse si está libre. Sólo si está libre se consigna el valor ocupado, correspondiente al jufador que tiene el turno.


Un pseudocódigo del juego... estúdialo a fondo, es simple y trata de implementarlo.

Dibujar (x, y, valor) es una función que dibuja el valor consuignado en la casilla que se indica.
Pero si te resulta complicado, dibujar una sola casilla, puedes optar por redibujar el tablero entero, no requiriendo al caso ningún parámetro.

finalesposibles = TresEnRaya(valor), es una función que escruta sobre el array si hay tres en raya del valor recibido ("X", ó "0"), si lo hay devuelve un valor 1 (ganado), si no lo hay todavía escruta si queda alguna casilla libre donde jugar, si no lo hay devuelve un valor 2 (tablas), si quedan casillas libres para jugar, devuelve un valor 0 (jugar)... es decir devuelve un valor de la enumeración: finalesPosibles...
Como sabes, 3 en raya puede ser en horizonbtal, vertical o diagonal... comprueba cada línea, horizontal, cada línea vertical y las 2 diagonales, cada una son 3 pares de cordenadas, que puede derivarse a una segunda función...

Buleano = Correcto3(x1, y1, x2, y2, x3, y3, valor) es una función que recibe 3 pares de cordenadas y devuelve TRUE, si las 3 tienen el mismo valor que el recibido.
dándote la primera de las llamadas, ya te faltan solo completar, 2 líneas horizontales, las 3 verticales y las 2 diagonales... la primera te sirve de guía.

Y aquí lo que sería el pseudocódigo de dicha función:

PedirCasillaAlJugador, es una función que reclama un valor entre 0 y 8, no debe admitir ningún otro. 

Pura especulación...

¡¿Tarjetas gráficas para minar criptomonedas?!... una tontería.
Si los fabricantes de verdad quisieran hacer un mercado para el minado de criptomonedas, harían soluciones dedicadas como otras que ya existen... pero claro, por qué no enmierdarlo todo y así afecta a nivel mundial...???. Y así acabaos pagando todos algo que solo necesitan algunos...

Linux Torvalds, les ha dado un buen rapapolvo a los tontainas de Intel... y es que no es para menos...


https://lkml.org/lkml/2018/1/3/797

Yo insisto, en que (algunos de ellos) son agujeros dejados ahí a propósito, por imposición del gobierno 'usasense'...
Hasta hace unos años, podían pasar desapercibidos, hoy día se mira todo con lupa (lo cual es lo correcto, no confiar en ninguna empresa, me cansan esos usuarios ciegos por tal o cual marca, sin reconocer sus defectos)...

---

Para descargar los papers y 'FAQs' genéricas al respecto: https://meltdownattack.com/