No existe.
En el diseño de un router, no se contempla almacenar el historial de sitios visitados. entre otras cosas, porque requiriría una memoria adicional que encarecería el aparato y además exigiría una gestión de la misma que a buen seguro consumiría muchos recursos. Lo limitan a bloquear Ips (seguramente de tamaño limitado) y a un breve historial de los bloqueos (eso sí suele permitir enviar el historial a un correo, para que el peso de mantener los ficheros recaiga en ti).

Hay un programa que cumple tus requisitos casi exactamente. Se llama PeerBlock (sucesor de PeerGuardian), que permite registrar (vía driver), las IPs (con su puerto) que se conectan a tu equipo, con la opción de poder bloquear listas de IPs, sueltas o por rango. (adjunto una captura más abajo).
Pero considera que un sitio web, puede tener una sola IP o recibir procedente de ella, muchas otras IPs (por ejemplo para cargar una imagen presentada ahí, pero alojada en otra web), por lo que tampoco quedaría como a tí te gustara, eso sí, permite guardar el historial acotando el tiempo que se almacena, el tamaño destinado , etc... y al tiempo te sirve para bloquear o permitir el flujo desde ciertas direcciones (ponerse tonto bloqueando a diestro y siniestro, tiene por resultado bloquearte el acceso a internet, por lo que es importante saber qué se hace).



https://en.wikipedia.org/wiki/PeerBlock

Tienes la alternativa de LibreOffice, que siendo gratuito, no tienes problemas de licencias...

Si pones el título quizás alguien lo tenga y quiera compartirlo...

Ufff...

Un lenguaje no se crea de esa manera.
1 - Para crear un lenguaje, lo primero es crear una especificación del mismo, que recoja todo lo que contendrá y como será contenido.
2 - Le sigue la definición (por ejemplo) en código BNF, con lo que una vez completado se puede programar y abordar el análisis léxico y el sintáctico.
Nota que la primera parte sería en prosa y la una y la otra van íntimamente unidas, la primera detalla partes de la semántica que la segunda deje 'al aire'. Además puede debería recojer también ejemplos, de cada definición así saca de dudas ante alguna complejidad...
Esa definición además debe ser filtrada para eliminar ambigüedades, eliminar entradas no accesibles, etc... es todo un proceso que llega a ser un arte por sí mismo.

La parte que pides corresponde al análisis semántico, es absurdo tratarlo si  previamente no se ha ido incluyendo cada símbolo en la tabla de simbolos (durante las fases de análisis léxico y sintáctico).
Es derivable durante el análisis semántico, el tratamiento de tipos, así como capturar los errores no interceptables en las fases previas.
Llegado a ese punto, resulta absurdo traducir de un lenguaje fuente a otro lenguaje fuente, suele reservarse para casos concretos en los que aún no esté completo el compilador (generalmente para un sistema distinto a aquel en el que se está operando). Como mínimo, lo adecuaod al caso es que invocaras directamente el mismo compilador que usa el lenguaje al que querías traducir.
Aunque lo más óptimo (de cara al rendimiento), es pasarlo luego a un código intermedio, previas optimizaciones, para al final compilarlo al sistema de destino (con las correspondientes optimizaciones según el sistema destino).

Hay quien tira de herramienrtas externas, como Flex, Bison, etc... para simplificar partes de la implementación del lenguaje. Tiene su beneficio y su perjuicio. Aunque claro, el tiempo de aprendizaje del mismo no difiere sustancialmente de implementar uno mismo su propio programa. El peor perjuicio que yo veo al usar herramientas externas, es que tu lenguaje debe cumplir ciertos requisitos, para acoplarse correctamente con ellos y sobretodo que determinados errores, aunque los intercepte, no ofrecen detalles específicos (lógicamente es algo personalizado de cada lenguaje), que es la principal razón por la que mucos lenguajes devuelven mensajes de error crípticos e ininteligibles muchas veces.

Si a pesar de todo insistes seguir por el camino que llevas, lo más que puedo sugerirte es que tu array, debe alojar una estructura y que esa estructura sea lo suficientemente flexible para contener los diferentes tipos por puntero... básicamente en ese array tendrías que albergar lo que has omitido que es la tabla de símbolos:
Así dicha estructura podría contenener al menos estos campos:
- Nombre del parametro.
- Fue declarado-inicializado el tipo.
- Valor de la enumeracion del tipo (por ejemplo byte=2, char=3, entero = 4, buleano =1, etc...)
- Se recibe por valor o por una direccion (qué se almacena en la pila, su valor o la dirección donde consta el valor?)
- Es un tipo simple o compuesto (los complejos serían aquellos que recogen varios campos. string y array de (cualquier otro tipo) aunque caigan en esta categoría deben considerarse simples, por cuando el único otro campo preciso es su cantidad de elementos, y el valor puede ser accedido por un indice sin más complicaciones que veirificar sus limites..., digamos que string y array son intermedios entre simple y complejo, pero se tratan como simples en prácticamente todos los lenguajes).
- ...

Vamos lo cojas por donde lo cojas, exige una especificación prácticamente antes de escribir una sola línea de código.

p.d.: Si es solo cambiar parcialmente la sintaxis de un lenguaje, podría ser aceptable como lo llevas...

Un poco off-topic...

Vaya, esto me ha refrescado que a raíz de aquel hilo y el problema que me encontré con prácticamente cada editor, es que se emperran en cargar en memoria el fichero completo, lo que admás de impráctico (para determinadas tareas sobre todo), si no tienes tanta RAM, no puede operar con el fichero (es un problema que se ha dado con cierta frecuencia, pero es a raíz de ese hilo que...), por lo que decidí, hacerme un editor hexadecimal (sencillo), que leyera solo 1-4 kb, de la posición elegida desde un scroll... y que las búsquedas las hiciera de igual forma (en segundo plano, cuando encuentre un hallazgo, carga su 'pagina' y que espere a que se pulse 'buscar siguiente').

Esta solución implica, emplear más tiempo en lectura a fichero a cambio de mantener la memoria prácticamente sin cambios... lo dejé medio funcionando y luego por carga de trabajo lo aparté y lo tenía completamente olvidado... vuelta a retomarlo...

Tranquilo, yo al menos he plantado más árboles que el papel que ocupen mis libros...
Seguramente en tu casa tengas puertas, ventanas, mesas, sillas, etc... de madera. Aplícate la misma regla (incluída los latigazos).

En realidad, los árboles debería plantarlos quien los tala (al margen de incendios u otras catástrofes).
Me preocupa enormemente más la contaminación derivada del petróleo en todas sus formas y variedades.

Jajaja...
hay películas donde la Tierra es aniquilada (ej: Guía del autoestopista galáctico),
películas donde la Tierra es tranformada y todavía habitable (ej: El planeta de los simios)
o inhabitable durante quien sabe cuanto (ej: la serie los 100),
o solo irrespirable pero todavía habitable (ej: Blade Runner),
hay películas donde la tierra es perdonada (ej: ultimatum a la Tierra),
películas donde se cree exterminada y luego resulta que no (ej: la serie Galactica)
y películas donde la amenaza es reducida (ej: Mars attack) de este caso quizás sea de las que más haya...

Si compras todos los boletos, será difícil que no te toque, así que a cuál te refieres tu???. ...en relación a "se adelantan a lo que va a suceder".

Usa GetDevices... quizás tengas que añadir una referencia al ensamblado.

Me obligas a leerme el pdf, y es precisamente lo que uno trata de evitar, porque ir al detalle fino, requiere mucho más tiempo en responder y sale un mensaje más largo.

Es definitiva es como te señalaba en mi mensaje anterior...
En ese incluí el ejemplo para decodificar un supuesto comando de la bateria (que existe se llama B (Battery), pero con sus valores específicos).

El comando X27, viene explicado también en el pdf, recibe '#' con 6 bytes, un cóoodigo de error viene en la forma: "#- loque sea".

Lo más sencillo al caso una vez leído por encima en pdf, es hacer un parsing genérico y luego especifico para cada comando... es más o menos el pseudocódigo previo que puse en mi mensaje anterior... la parte del preparsing, sería algo como:


Ahora una funcion que preprocesa el comando recibido:

Como decía conviene tener una enumeracion que represente cada comando:
Hay todos estos comandos:  "The I, O, L, B, V, T, F, H, R, C, Q, S, W, X are single uppercase

La funcion procesar comando, tendrá en selector de casos, con un caso para cada comando que te interese y un 'else', para el resto...
Esto viene a ser equivalente al código de más arriba, solo que allí se recibía 1 solo byte y se ejemplificaba solo el comando 'B' de batería.
Algunos comandos  como el X, tienen 'subcomandos' en la forma Xn, donde 'n' es un numero...
Estos comandos dento de su 'caso', examina precisamente el 'subcomando', y lo gestiona a su vez con otro 'selector de casos'.
Como los comandos al final tienen varos bytes, interesa más hacer una llamada en esta funcion para dedicar una funcion exclusiva para procesar cada comando o subcomando, incluso aunque haya partes comunes entre ellos, será m
ás fácil de implementar y de mantener aunque sea a costa de más código:


Y bueno, este es el esqueleto para decodificar todo... fíjate que es un simple parsing, donde primero se verifica si el resultado es un codigo de erro o no... sino, luego se verifica que comando se trata, luego cada comando si tiene subcomandos, deriva a otra funcion que identifique de qué subcomando se trata, al final cada comando final, tiene que ser procesado individualmente, porque los bits de cada uno tendran un significado unico y específico...
El caso de error, igualmente en su llamada debe derivar descendeidno e comandos y subcomandos, segun sea el caso, para que al final procesar el error. Ignoro si cuando es un código de error, se compone de un unico byte o más... si es solo uno, una unica funcion (a nivel de comandos y subcomandos) podría ser suficiente, en cambio si tiene varios bytes, y el codigo puede ser excesivo (generaría una función muy larga), convendría en ese caso, tener una etapa más donde se procese cada byte (si cada bit tiene un significado propio, si cada byte tiene un significado propio es lo mismo que recibir 1 solo byte con significado propio a nivel de bit (o más de 1).

En fin, el trabajo no es complicado, solo largo y algo tedioso, porque son más de una docena de comandos y algunos tienen subcomandos, y luego cada caso se procesa a nivel de bit, por lo que necesitas constantes a mogollon...

pd.: Olvidaba adjuntar una captura que hice, para que veas que viene explicado, tienes que leerlo primero entero, para tener una idea global y luego ocn más detenimiento en el apartado que más te interese, si te interesan todos, pués paciencia, hoy uno y mañana otro.

Es aún más sencillo, en NET muchas colecciones admiten la adicion de un array directamente con 'AddRange', lo que nos evita la necesidad de usar un bucle...

private void button1_Click(object sender, EventArgs e)
        {        
            string[] uds= "C:D:F:G:".Split(':');
            comboBox1.Items.AddRange(uds);
 
            //comboBox1.Items.AddRange(unidades.Split(':'));  //el Split se puede hacer en una sola linea.
        }
 

Si además quieres que aparezcan los dos puntos, es preferible modificar el string de entrada, remplazando los dos puntos por los puntos y un espacio (y entonces hacer el Split por el espacio).