No es un error. Lo que pasa es que, en los programas de C y C++, la biblioteca estándar (llamada el C/C++ runtime), que contiene las definiciones de funciones estándar, suele no incluirse en el ejecutable, sino que enlaza de forma dinámica (en Windows, un dll). Esto pasa también con Visual C++, por ejemplo, donde los ejecutables generados, necesitan archivos como msvcr*.dll o msvcp*.dll, donde * es un número de versión. Si la computadora donde quieras ejecutar el programa no contiene el archivo correspondiente a la versión de Visual C++ con la que lo compilaste, marcará un error. Vamos, que tu problema no es fallo de Code::Blocks, ni nada por el estilo, simplemente así funciona esto.

En tu caso tienes dos opciones. Una es copiar el archivo que te pide (se encuentra en <carpeta de codeblocks>\MinGW\bin) a una ruta done tu ejecutable pueda verlo, como Windows\system32, lo cual NO recomiendo, o a la carpeta de tu exe. Con eso se arregla.

La otra opción es enlazar estáticamente el runtime, y de esta forma tu ejecutable ya contiene todo ese código, lo cual obviamente incrementará su tamaño, pero eliminas la dependencia de la dll. Esto lo haces de la manera que indican en el link que te pusieron: Project/Build options/Linker settings, y en other linker settings: -static-libgcc. Para C++ también agregar -static-libstdc++.

Como los enum class tienen tipado fuerte, no hay forma de evitar los cast. El problema en ese código es que estás usándolos para algo para lo cual no fueron creados. La idea es tener una lista de valores posibles agrupados en un sólo tipo. De hecho, uno de los principales objetivos para crear los enum class y de las principales ventajas de usarlos es precisamente que no se pueden mezclar ni comparar con ningún otro tipo. Lo que hace ese código es, por así decirlo, totalmente contrario a su naturaleza. Te aconsejaría replantear el diseño. Si de cualquier forma lo quieres hacer así, vas a tener que seguir poniendo todos esos static_cast.

Ah, te había entendido mal. Para eso basta con usar WS_EX_TOPMOST. Con lo de "difuminar" me refería a que cuando haces click en otra ventana, Windows hará que en tu ventana, el título de la misma se difumine un poco, se ponga gris en vez de negra. Pero tu ventana estará siempre al frente. Puedes perfectamente abrir Chrome, Acrobat, etc. maximizados y tu calculadora seguirá encima de ellas.

Para lo del click, ya no necesitarías hacer nada más. Aunque el foco lo tenga otro programa, en cuanto hagas click en un botón de tu calculadora, se activará y presionará el botón a la vez.

Sobre los botones, de forma predeterminada, Windows hace que los controles usen estilo "clásico" (de antes de Windows XP) que se ve bastante feo. Para hacer que tengan apariencia actual: https://docs.microsoft.com/en-us/windows/desktop/controls/cookbook-overview . Lo más fácil es copiar el contenido del archivo manifest ejemplo que ahí se muestra, en un archivo llamado nombredetuejecutable.exe.manifest y colocarlo en el mismo directorio que el .exe.

Pero si realmente quieres dibujarlos tú, lo que debes hacer es, crearlos normalmente, pero encargarte de pintarlos manualmente. Para esto, primero debes crear un manifest file, como te puse arriba. Luego, en tu procedimiento de ventana, debes manejar el evento WM_NOTIFY, verificar si recibiste el código NM_CUSTOMDRAW y si fue alguno de los botones quien recibe el evento. De ser así, dibujas lo que quieras: rectángulo con esquinas redondas, elipses, etc., usando las funciones de dibujo de Windows. Buscando NM_CUSTOMDRAW deberías encontrar información.

Yo simplemente haría que la ventana no se pueda maximizar ni cambiar de tamaño. Así funcionaba antes la de Windows, aunque ahora ya permite maximizar y se ve horrible.

Para que quede en primer plano, al crearla, debes pasar WS_EX_TOPMOST como primer parámetro a CreateWindowEx(). Esto hará que tu ventana siempre esté al frente, pero sí se difuminará cuando hagas click fuera de ella. Esto no se puede cambiar, a menos que hicieras algo que ya raya en el comportamiento de un malware: apoderarte totalmente del "foco", lo cual en esencia significaría bloquear los clicks y tecleos fuera de tu ventana.

Lo del primer click no lo entiendo muy bien. Si te refieres a que cualquier click incluso fuera de tu ventana la traiga al frente y la active, nos remitimos al punto anterior.

Para GUI te recomendaría que te alejes de Allegro, SDL, SMFL. Podrán ser buenas para juegos, pero para GUI... por buenas razones, podría casi garantizar que más temprano que tarde te darán problemas. Mejor recurrir a APIs totalmente especializadas en interfaces gráficas. Habiendo descartado Qt, las únicas opciones multiplataforma que vale la pena considerar son Gtk+ (para C, pero con bindings oficiales para C++ llamados Gtkmm), y wxWidgets. Con Gtk+ yo sólo he programado un poco en Linux. En Windows nunca lo hice, pero leí que era un poco lioso hacerla funcionar. A mí no me gusta mucho, entre otras cosas, porque las aplicaciones no lucen nativas. La documentación es decente. wxWidgets (que es con lo que está programado el Code::Blocks) usa controles nativos en todas las plataformas, y tiene buena documentación, pero no tiene tantos usuarios, por lo que, si te atoras en algo, quizás no sea tan fácil encontrar ayuda. Nunca la he usado, aunque sí leí algo de su documentación. Yo me inclinaría por ella antes que por Gtk+.

Considerando que lo que llamamos comúnmente API de Windows es en realidad un conjunto enorme de APIs para distintas tareas, no hay realmente una equivalencia en Linux. Lo más cercano sería el estándar POSIX, que abarca archivos, manejo de memoria, procesos, hilos, redes, etc., pero por ejemplo, para sonido, hay que usar otras APIs independientes. Y para interfaces gráficas lo mejor es usar las APIs nativas de los Window managers (Gtk+, KdeLibs) o las multiplataforma.

Para redes, como menciono en el párrafo anterior, lo nativo son los sockets POSIX (la API equivalente de Windows, Winsock, se basa parcialmente en ellos, por lo que si aprendes una, es muy fácil pasar a la otra). Quizás no la consideraría de alto nivel, pero, al igual que Winsock, es tan sencilla que en mi opinión, lo único que justificaría usar otra cosa sería que necesitemos algo 100% multiplataforma.

Sí, un bucle vacío también te va a consumir mucho CPU, debido a que las instrucciones de verificación de la condición y el salto de vuelta al inicio, se van a ejecutar muchos millones de veces por segundo:


Aquí, el procesador está constantemente verificando si la condición es true, y saltando de nuevo al inicio del bucle. Esto sucede tan rápido, que ese trozo de código hace que tu procesador ejecute seguramente muchos millones de instrucciones por segundo. En este otro caso:


En este caso, estamos llamando a tecla_presionada() en cada repetición, pero dado que lo único que hace es verificar si se presionó una tecla, regresa muy rápido. Ahora, en condiciones normales, la gran mayoría de las veces no habrá tecla presionada (obviamente nadie puede teclear millones de veces por segundo), por lo que ese if evaluará a falso, y volveremos a la siguiente repetición del bucle. Todo esto pasa muy rápido, y no hay nada ahí que le diga al procesador que tiene que detenerse un poco: él hace lo que tiene que hacer, que es ejecutar las instrucciones que tiene delante, tan rápido como sea posible.

Aunque no sé qué librería estás usando, prácticamente todas (por no decir todas) las que funcionan de la forma if (KEY_BLABLA), en Windows llaman internamente a la función GetKeyState o GetAsyncKeyState. Estas funciones únicamente verifican si la tecla especificada está presionada, y en cualquier caso, regresan inmediatamente, por eso estoy seguro de que así funciona también la función que estés llamando.

La única forma de evitar el alto consumo es haciendo que el bucle no se repita tan rápidamente, y eso sólo se puede hacer, o con algo tipo sleep, que no es muy recomendable, o usando funciones bloqueantes, como en el ejemplo que te puse, que no consume prácticamente nada de CPU. Si no te sirven las funciones de entrada estándar, tendrías que ver si la librería que estés usando tiene funciones que verifiquen si hay teclas presionadas, y si no las hay, espere hasta que se presione alguna, es decir, que funcionen de forma bloqueante. De otra manera, es imposible solucionar el problema.

Pero como te mencioné en el otro mensaje, la mejor solución es usar eventos de Windows, es decir, que tu programa reciba mensajes. De esa manera, ni siquiera hay que poner verificaciones if (KEY_IS_DOWN). Tu programa automáticamente será notificado cuando se haya pulsado alguna tecla, y tú únicamente verificas el valor de tecla virtual que recibas. De hecho, así es como suelen funcionar los keyloggers reales (aunque estos, adicionalmente instalan, como te decía, hooks para capturar teclas de todo el sistema).

Por lo que dices de los recursos de CPU, imagino que en teclainput() iría una función tipo kbhit(), que simplemente verifica si hay datos de teclado. Por lo tanto, cuando no hay tecla presionada, regresa y se vuelve a ejecutar el bucle, ocasionando el alto consumo de recursos. La clave estaría en usar mejor una función bloqueante, es decir, que intente leer una tecla, y si no hay ninguna, simplemente espere, y de esa forma no se usa prácticamente nada de CPU. Todas las funciones estándar de entrada de C y C++ (getchar, cin.get, etc.) ya son bloqueantes, pero un problema es que, de forma predeterminada, stdin usa buffer por línea. Por ejemplo, getchar() lee un caracter, pero el usuario tiene que presionar Enter para que esta función pueda leer lo que escribió. La solución sería cambiar stdin a modo sin buffer. En Windows podría hacerse así:

// Obtenemos handle a stdin
HANDLE hEntrada = GetStdHandle(STD_INPUT_HANDLE);
DWORD modo;
char c;
 
// Guardamos la configuracion actual
GetConsoleMode(hEntrada, &modo );
// Desactivamos el buffer por linea
SetConsoleMode(hEntrada, modo & ~(ENABLE_LINE_INPUT) );
 

Una vez hecho esto, ya podrías hacer algo así:

while (true) {
    c = cin.get(); // o getchar() o cualquier funcion que lea 1 caracter
    escribelog(c);
}
 
// Importante devolver stdin a su estado original antes de salir del programa
SetConsoleMode(hEntrada, modo);

De esta manera, el programa simplemente esperará a que se presione alguna tecla, sin consumir apenas CPU, y en cuanto el usuario teclee algo, sin necesidad de que presione Enter, cin.get() lo obtendrá.

Una forma aún mejor sería haciendo que tu aplicación reciba eventos del teclado, pero ahí ya tendrías que usar más cosas de la API de Windows.

Y, claro está, me basé en el seudocódigo que pusiste, pero esto obviamente no funcionaría como keylogger, ya que sólo captura teclas de tu propia aplicación. Si quisieras capturar las del sistema, podrías crear un hook de teclado (WH_KEYBOARD o WH_KEYBOARD_LL). Realmente no es difícil pero tendrías que meterte más de lleno a WinAPI.

En Windows lo que se usa normalmente es Winsock. Las cabeceras principales son winsock2.h y ws2tcpip.h. Y necesitas configurar tu proyecto para que enlace con libws2_32.a (con la opción -lws2_32). El compilador que usa DevC++, MinGW, ya incluye lo necesario para trabajar con esta API.

Sé que a veces encontrar información sobre cómo usar APIs nativas es algo complicado (encontrar descripciones de las funciones sí es fácil, pero cómo usarlas es otra cosa...), así que te pongo un ejemplo de uso para lo del navegador.

En Windows:

#include <windows.h>
...
ShellExecute(NULL, "open", "Documento.html", NULL, NULL, SW_NORMAL );

En Linux, y en general sistemas tipo Unix, incluyendo Mac OS X:

#include <spawn.h>
 
extern char **environ;
...
pid_t processID;
char *argV[] = {"xdg-open", "Documento.html", NULL};
posix_spawnp(&processID, "xdg-open", NULL, NULL, argV, environ);
 

xdg-open abre el archivo o URL en el navegador por defecto.

Si decides usar algo de esto, ya te recomiendo buscar información sobre qué hace cada parámetro, etc. para entender bien lo que se está haciendo, pero creo que se facilita mucho habiendo visto un ejemplo concreto como este.

Si ya sabes sobre compilación condicional (#ifdef, #elif, etc.), puedes usarlo para incluir lo anterior en tu código y que compile donde sea sin cambios. En tal caso, las macros predefinidas _WIN32, __linux__, y __APPLE__ son tu amigas.

Sobre el resultado de la función JS, necesitas "algo" que entienda y ejecute código javascript y se puede comunicar con tu programa. En este caso, sería algún motor/librería de javascript en C/C++, como V8 o Duktape. Pero V8 es de Google, y por experiencias anteriores con código de esa compañía... imagino que incluso lograr compilarlo llevará bastante trabajo.

Otras formas de hacerlo implicarían comunicarse de alguna forma con el navegador. En Linux hay algunos que funcionan en modo texto, y ahí podría ser relativamente sencillo hacer que tu programa lo ejecute y capture su salida en un string, por ejemplo. Pero necesitarías asegurarte de que el usuario tenga ese programa, y además no sé si en Windows haya algo parecido. Comunicarse con programas gráficos también suele ser posible, pero más complicado, propenso a errores, y tendrías que tener código específico para cada navegador posible. Vamos, no es práctico. Realmente la mejor opción, más simple y portable, es usar una librería tipo Duktape.

Sólo por curiosidad, y dejando de lado caracteres especiales, si arrastras un directorio con espacios a la ventana de tu programa, Windows le añade comillas, ¿cierto? Y de ser así, ¿lo acepta correctamente opendir? Porque hasta donde sé, Windows sí que las añade y así ya no funciona. A menos que haya cambiado el funcionamiento .

Editado: Se me olvidó lo principal que iba a poner. Eso de los acentos en Windows lo podrías solucionar llamando a este par de funciones (incluye <windows.h>):

SetConsoleCP (1252);
SetConsoleOutputCP(1252);
 

Con eso configuras la entrada y salida a la codificación latina.