La forma en que lo hacen en el segundo link (NtQueryInformationThread) es sencilla en C++, pero no tengo mucha experiencia llamando a funciones de la API desde .NET, y nunca he programado en Vb.Net. De cualquier forma, van algunos consejos que te podrían servir al menos darte una idea general.

En C# sería algo más o menos así:

Obtener handle a cada hilo mediante la función de la API OpenThread (kernel32.dll):

IntPtr hThread = OpenThread(0x0040, false, idHilo);

Luego llamas a NtQueryInformationThread (ntdll.dll):

IntPtr startAddress = Marshal.AllocHGlobal(IntPtr.Size);
NtQueryInformationThread(hThread, 9, startAddress, IntPtr.Size, IntPtr.Zero);

Cierras el handle con la función de API CloseHandle (kernel32.dll):

CloseHandle(hThread);

Obviamente habría que hacer manejo de errores y demás, pero para empezar podrías probar a ver si te sirve de esta manera.

Una solución rápida que se me ocurre es esto:

La función que recibe los comandos del usuario los pondría en algún tipo de cola, de forma sincronizada (usando una región crítica, por ejemplo). Cuando el usuario llama a la función Analizar(), ésta va tomando cada comando de la cola (obviamente, de forma sincronizada) y ejecutándolo. Dado que no quieres que un comando bloquee la ejecución de otro, esta función podría lanzar un hilo que ejecute cada uno de ellos. Para que esto no sea muy ineficiente, te recomendaría usar un "pool", que podrías crear tú, o usar el de Windows (la familia de funciones *Threadpool* de la API de Windows).

El comando CuentaRegresiva lo podrías manejar dentro de un bucle y haciendo llamadas a Sleep(1000) luego de cada mensaje "Faltan X cantidad de segundos", porque como se ejecuta en su propio hilo, no bloquearía el programa; o algo más elegante sería usar funciones de colas de temporizadores (Timer Queues) que la API de Windows proporciona. Éstos se ejecutan de forma periódica; en tu caso harías que esto ocurriera una vez por segundo. Podrías pasarle a la función callback de cada timer un puntero a una variable con el valor inicial recibido en el comando CuentaRegresiva (10 si fueran 10 segundos, etc.) y ésta, en cada ejecución lo decrementaría. Una vez que ese valor llega a 0, detienes (destruyes) el timer.

Dado lo anterior, Inicializar() podría inicializar las regiones críticas, y Apagar() esperaría a que los hilos terminen su ejecución (mediante la función WaitFor* correspondiente al tipo de hilo que decidas usar).

No me detengo en cada punto de los que pusiste porque me parece que algunos son muy simples.  Creo que lo único que podría tener cierta complicación es el tema de procesar comandos sin que uno bloquee los demás, y quizás la implementación de la cuenta regresiva; de ahí que me centrara en estos temas.

Es cierto que x86/x64 son little endian, pero eso no es lo que causa tu problema. Los editores de texto y el comando cat esperan un archivo de texto, pero en la línea

  if(write(fd, &userid, sizeof(int)) == -1 )

estás escribiendo un valor entero en el archivo. Obviamente si se intenta leer como ASCII o UTF-8, se van a mostrar símbolos raros. Necesitas convertir userid a texto, por ejemplo, mediante sprintf o snprintf, y luego guardar esa cadena resultante.

Tienes otro error importante. Los elementos de argv son punteros, no arrays. Así, esto:

  databuffer = (char *) ec_malloc(sizeof(argv[1]));

está mal, pues sizeof devolverá el tamaño de un puntero (4 u 8), por lo que si el mensaje no cabe en esa cantidad de bytes, estarás sobrescribiendo bytes indebidos. Lo que necesitas pasar a ec_malloc es: "strlen(argv[1]) + 1".

Es que no digo que sobrescribir en nuevas posiciones sea lo normal sino que es posible. No conozco todas las circunstancias en que eso pueda ocurrir ni sé si está documentado. Sí sé que, por ejemplo, si el archivo se encuentra en un directorio donde la compresión de Windows esté activada, o si se usa la cifrado de disco, sí puede suceder (y creo que es lo normal) que los datos se escriban en otras posiciones, pero la mayoría de los usuarios no usan esas características. No sé en qué otros casos pueda ocurrir, pero como te decía en el segundo mensaje al mencionar WriteFile, no me parece motivo de preocupación, pues creo que en la mayoría (si no es que en todos) de los casos típicos, sí se sobrescribirán correctamente.

Con los SSD y memoria flash en general, es diferente. Normalmente usan técnicas para que las escrituras estén bien distribuidas a lo largo de la unidad. Aunque dudo que las memorias USB económicas que la mayoría usamos las implementen (y si lo hacen, que lo hagan bien), los SSD, o al menos la mayoría, seguro que sí lo hacen. Cada fabricante usará sus técnicas, algunas más o menos agresivas, pero un ejemplo: https://en.wikipedia.org/wiki/Wear_leveling


Como sea, yo no me preocuparía mucho, a menos que estuviera haciendo algo ilegal. Con sobrescribir los datos de las maneras ya mencionadas, creo que es muy poco probable que una persona normal los pueda recuperar.

Sí, eso está claro desde el principio. A lo que me refiero es a que, dependiendo de cómo se haga, sobrescribir un archivo no necesariamente implica que se sobrescriban los sectores originales. Digamos que tienes un archivo C:\archivo.dll. Por más que lo sobrescribas, el SO, e incluso la controladora del disco/unidad (especialmente en SSD) son libres de escribir los datos nuevos en una ubicación completamente distinta, y simplemente hacer que C:\archivo.dll "apunte" a estos nuevos sectores, dejando intactos los anteriores, y por lo tanto, susceptibles de ser recuperados. Por eso la propia Microsoft en su documentación dice que la única manera más o menos confiable de hacer que un archivo sea (prácticamente) irrecuperable es usando herramientas especializadas.

En tu caso no estamos hablando de proteger información ante un análisis forense profesional ni nada por el estilo, así que, como te mencioné, probablemente con que sobrescribas la .dll mediante WriteFile u otra función similar sea suficiente. Pero es importante ser conscientes de que la posibilidad de recuperación existe, y de que, sin usar software especial, el hecho de que los datos sean o no realmente sobrescritos, es algo que no puedes controlar, al menos hasta donde sé.

Todo eso que dices se puede hacer sin mayor problema, pero es difícil hacer que un archivo sea 100% irrecuperable por muchas razones. Si sólo necesitas evitar que un "listillo" los recupere, hay varias alternativas.

Si quieres sobrescribir el ejecutable desde un .bat, lo mejor sería invocando herramientas externas como SDelete. Esto lo podrías hacer como te dije en el mensaje anterior, reemplazando el "del" con "sdelete" o algún programa equivalente, y así podrías incluso prescindir de la .dll. Te sugiero una herramienta especializada porque borra de forma relativamente segura, haciendo difícil la recuperación, y porque los comandos estándar con los que podrías intentar sobrescribir el archivo (echo, copy, xcopy, etc.) en realidad crean uno nuevo y borran el anterior.

Si no quieres usar programas adicionales, puedes usar la opción de una .dll. Obviamente deberás usar carga explícita (LoadLibrary, etc.) para poder cerrarla. Luego la puedes sobrescribir, por ejemplo, con WriteFile. Aunque seguramente no hay garantías de que los bytes originales se sobrescriban, creo que (normalmente) sí sucede así. Eso sí, en este caso, al final no podrías sobrescribir el .exe sino sólo borrarlo.

Aunque es cierto que, hasta donde sé, un exe no puede eliminarse a sí mismo, hay maneras de hacerlo indirectamente. Por ejemplo, en C++ podrías poner algo similar a esto como última instrucción del programa antes de salir:

ShellExecuteA(NULL, "open", "cmd", "/c timeout /t 2 & del ejecutable.exe", NULL, SW_HIDE);

para que se ejecuten los comandos timeout y del. Lo que hace es esperar un par de segundos para estar seguros de que el ejecutable ya se cerró, y entonces borrarlo. Si quisieras hacer algo más complejo que sólo borrarlo, en lugar de "del" ejecutas lo que quieras, incluso un archivo .bat.

De todas formas, coincido en que esto no parece tener mucho sentido, salvo que se trate de actividad maliciosa.

Cuidado con e. Fíjate que el enunciado:

F es negativo o E es no negativo pero no ambos a la vez

no dice nada acerca de qué pasa cuando F es no negativo (o cuando E es negativo). Suponer que negar una cosa implica negar la otra es un error. Si puedes usar la negación o complemento lógico (y no veo por qué no) podrías resolverlo así:

NO ((F < 0) Y (E >= 0))

Edit: no lo leí bien, pues lo anterior admitiría que ninguna de las condiciones se cumpliera.

Por cierto, aquí hay que invertir las condiciones ya sea de E o de F:

Buen aporte. Aunque no lo probé (tan sólo porque actualmente ya no me llaman mucho la atención estos temas, no por desconfianza o algo por el estilo) sí le di un vistazo al código y es refrescante ver algo directo, claro y sin florituras innecesarias (que parece ser lo común en estos tiempos). Te comento un error:

char *Pathvar = getenv("TEMP");
...
DLLName = strcat(Pathvar, DLLName);

strcat modifica su primer parámetro, pero, dado que tú no reservaste la memoria a la que apunta, no es seguro hacerlo y de acuerdo a las reglas de C, es incorrecto (básicamente es como escribir más allá de los límites de un array). Como suele ser el caso con los bugs de punteros en C, es posible tener la suerte de que el programa funcione bien, pero no deja de ser un error esperando a manifestarse. Al margen de eso, las reglas del lenguaje expresamente prohíben modificar los datos del puntero devuelto por getenv. También aquí el resultado podría ser impredecible, por lo que es mejor corregirlo reservando (malloc) para Pathvar un bloque con el número de bytes suficientes para la ruta del directorio temporal más el nombre de la DLL más un byte adicional para el caracter nulo, y entonces sí, copiar getenv("TEMP") a Pathvar y luego concatenarle el nombre de la DLL.

También hay algunas maneras en que podrías ahorrarte la compilación. Esto a lo mejor ya lo sabes y decidiste compilar por alguna otra razón, pero si no es el caso, y lo haces sólo para que el stub pueda conocer los datos de la DLL de .NET (preprocesas el .c para sustituir los datos entre "$$" antes de la compilación, imagino), puedes distribuir (o incluir en tu EXE) solamente la DLL del stub ya compilada. Tu programa podría simplemente añadirle como recursos tanto la DLL de .NET como el nombre del entry point o cualquier otra cosa que necesites, mediante la familia de funciones *UpdateResource de la API de Windows o lo que proporcione .NET. El stub cargaría esos recursos y reservaría dinámicamente la memoria de rawData. O, sin recursos, tu ejecutable podría limitarse a escribir toda esa información (junto con offsets para encontrar los datos fácilmente) al final de la DLL del stub. En cualquier caso, ya con esa información el stub procedería a escribir los bytes en la DLL temporal, la cargaría, etc. tal como lo hace actualmente.

Esto parece un error en el diseño de tu programa. No sólo por el bucle infinito que provocará, lo cual tiene solución simple (aunque no muy limpia) sino porque ese tipo de interdependencia casi nunca es bueno. Si es curiosidad lo que tienes, sí puedes pasar punteros a funciones miembro, pero teniendo en cuenta algunos detalles.

Las funciones miembro no static, como Alpha(), siempre se ejecutan en el contexto de un objeto concreto (el puntero this, que reciben como parámetro implícito). No puedes simplemente pasar el puntero a la función, sino que necesitas saber sobre qué objeto operar. Hay varias formas de hacerlo. Una simple que podrías probar es algo así:

Declaras Beta de esta manera

void Beta(void (ClaseA::*funcion)(void), ClaseA& o);

La invocas desde Alpha así:

b->Beta(&ClaseA::Alpha, *this);

Y dentro de Beta:

(o.*funcion)();

No es lo más limpio, pero simplifica el código (lo de evitar el bucle infinito te lo dejo. Hay muchas maneras de hacerlo). Aún así, reitero que te recomiendo que rediseñes el programa para no necesitar esto.