Recién añadido al horno... los 30 cuadernos de la mítica revista: Hack x Crack. unos 410Mb. Empaquetadas en TAR.
Como datan del año 2002-2005, mucho de su contenido está obsoleto, pero conserva la virtud de guiar paso a paso al interesado, por lo que sigue siendo recomendable su lectura.

Cuadernos de Hack y Crack [completo las 30 revistas en pdf].tar
https://elhacker.info/manuales/Hacking%20y%20Seguridad%20informatica/Cuadernos%20de%20Hack%20x%20Crack%20%5Bcompleto%20las%2030%20revistas%20en%20pdf%5D.tar (410Mb. aprox.)

A ver si he entendido, bien...
Dice coloso55, ¿qué las vacunas incorporan un chip con bluetooth?.

No sé si reir o llorar, da para ambas...

Yo incluso tengo revistas de (electrónica, radio y Tv.) de los 50 y 60 con las primeras noticias que se iban dando en la tecnología digital, incluso las patentes relacionadas que iban saliendo. Lo típico de entonces eran (hablo de revistas especializadas en electrónica), desde altavoces y micrófonos, válvulas, radios televisores, antenas, gramolas... tampoco faltaban, osciloscopios, reguladores de tensión, condensadores, transistores, diodos... incluido cursos por correspondencia.

La disparidad de marcas no tiene nada que envidiar a la de hoy. En el transcurrir de los años, desde luego los anuncios fueron cambiando, a medida que la tecnología avanzaba.
Con la aparición de los primeros miniordenadores (orientados al hogar) a finales de los 70, explosionó... El Z80 se ganó el liderazgo y aparecieron muchas revistas dedicadas a todo el público entusiasta. Los revistas de radio y tv. fueron siendo sustituídas poco a poco por revistas dedicadas a los ordenadores y juegos ...y hasta hoy.

Un log, es un registro de actividad, así si sucede algo inesperado, al menos se sabe que fases realizó y en cual se quedó atascado... Ahí como se ve, terminó correctamente sin ninguna incidencia.

Seguramente el programa tenga alguna opción donde permita indicar si al final devuelve el log completo (te abre el fichero log que ha ido generando) o solo un resultado más breve (un mensaje de ok/fallo).

Otra cosa es que no tuvieres drivers adecuados o actualizados para ver el vídeo, de lo que no puede inferirse que el el DVD esté dañado. Como te han dicho usa un reproductor, para ponerlo en marcha y listo. O ahora que has hecho copia digital, abre el mismo en el reproductor. El conglomerado de ficheros que crea el programa, podría hacerte creer erróneamente que está dañado si no abres el adecuado...

Para empezar (con los grafos), lo importante es siempre ser capaz de entenderlo y por tanto resolverlo...
Las optimizaciones siempre vienen al final (cuando se verifica que funciona todo correctamente), especialmente cuando urge que así sea porque el espacio de soluciones es inmenso y el tiempo excesivo o más bien intolerable o intratable... para casos en que una respuesta se obtenga en lo que dura parpadeo, no importa que sea subóptimo...

Frente a la de 'matriz de adyacencia', está lo que se llama 'lista de adyacencia'.
A menudo (las listas de adyacencia) suelen operarse como listas enlazadas, pero cuando se busca el mayor rendimiento posible en tiempo, es preferible convertirlo en array (si el sistema se deja) a cambio de un escaso tiempo inicial de preprocesado.
Si el sistema tiene una complejidad baja, suele bastar un simple string y/o si tiene una complejidad media vía un fichero de texto. Si el sistema es más complejo o es cambiante de forma dinámica, es preferible crear una clase, que permita dinámicamente añadir, eliminar y modificar los nodos, algo como:

Ambos modos son de interés, pero el uso de uno u otro suele venir abordado por el tipo de problema, es decir, según se requiera.
Como modo general, puede establecerse que la matriz de adyacencia es el método adecuado cuando el número de conexiones entre los nodos es muy elevada. Por ejemplo en el problema (general) del viajante de comercio, todos los nodos están conectados a todos los nodos. La lista de adyacencia en cambio suele ser más conveniento cuando en el grafo cada nodo tiene pocas conexiones a otros nodos, respecto de la cantidad total de nodos presentes en el grafo.

Por lo demás las conexiones, pueden verse así de simple como conexiones, o como referencias a padre/hijo, elegir un modelo de visionarlo, suele dejarse a la preferencia de la intuición, pués así acomoda mejor y queda menos abstracto, con lo que te resulta más cómodo tirar de una visión u otra... por ejemplo en sistemas binarios, muchos prefieren la alusión de derecha/izquirda, para la referencia a los nodos hijo... para mí incluso un nodo padre, es un hijo respecto del que se ve como su hijo, en función pués de la dirección del flujo del recorrido (naturalmente cuando un grafo es dirigido, cierta conexiones son unilaterales, luego (simplificando) toda conexión la veo como un hijo o ciega (ciega= inexistente, aunque a veces en sistemas más complejos, puede ser condicionado dicho caso por otros medios  al margen de haber sido visitado))... hay quien prefiere tirar de 'anterior/siguiente'.
Hay quien de la nomenclatura, quiere hacer un sistema rígido, cuando a todas luces debe ser flexible, pues existe para asistir al ser humano, no para imponerle 'reglas'. No temas patear la nomenclatura cuando lejos de ayudar, esclaviza.

En la vida real, lo normal es que te encuentres siempre con grafos. Otros tipos de estructuras en la vida real, no suelen darse, a menudo son simplificaciones de ellos o en todo caso maquinaciones conceptualmente humanas... recuerda aquel dicho romano: 'divide y vencerás'.
Pero no importa si te acercas a los grafos por una u otra razón, es adecuado conocerlos, pero (al programar) como mínimo ser capaz de recorrerlos.
En programación hay que aventurarse a los diferentes campos que ofrece sin miedo y no hay obligación de profundizar al máximo, a menudo es solo curiosidad o una necesidad puntual.

Si con 'el primer programa', te refieres a la primera versión en zip que subí, sucede lo mismo que te comentaba en el último...

El registro tiene para el campo artículo un valor de tipo string de tamaño 'fijo' (...as string *12), es decir se rellena con espacios al final si el artículo no completa el tamaño del campo.

Hay esto en el código:

        ...
        Get #Canal, ptr, Articulo
 
        If (LCase$(Articulo) = Producto) Then
        ...
 

Falta por tanto eliminar los espacios, tan simple como cambiarlo por esto:

        ...
        Get #Canal, ptr, Articulo
 
        If (LCase$(trim$(Articulo)) = Producto) Then
        ...
 

En cualquier caso, debes utilizar las herramientas de debug, que el IDE ofrece (El IDE no sirve meramente para dejar colorido el texto, tiene muchas herramientas interesantes)...
Si revisas el contenido del valor 'Producto' justo donde se hace la comparación, verás que es: "alicates"
...y de igual modo con la expresión 'LCase$(Articulo)', verías que es:  "alicates     "
...se observa que en efecto se diferencian en los espacios, luego la solución aparece obvia, sin entrar en pánico ni revisiones complejas.
Puedes poner un simple punto de parada en dicha línea (pulsa la tecla F9 encima de dicha línea en tu código y ejecuta el programa (estamos en modo diseño, ahí se interpreta)... al llegar  a esa línea con un punt de parada, el intérprete se para en dicha línea, teniendo ahí el cursor, puedes hacer desde un simple:

debug.print "." & articulo & "." , "." & lcase$(articulo) & "." 
' los puntos son solo para determinar claramente donde empiea y termina el string, lo espacios pueden pasar desapercibido...
 

Sea pegando está línea justo antes de esa y ejecutándola, o abriendo la ventana de pruebas (inmediato) CTRL+G (o buscarla desde el menú --> Ver ...).
También simplemente seleccionado una expresión y desde el: 'menú --> debug --> inspeccion rapida', etc... mejor si se edita el propio menú para tenerlo en el menú contextual.


Por último se te señalo que la comparación, además de no ignorar espacios, exige exactitud, de ahí que incluso sea preferible hacer una búsqueda parcial...
...también sucede que la búsqueda se realiza desde el comienzo, luego, si encuentra el primer registro que cumple la condición y sale... una nueva búsqueda (sin más), para lo mismo volverá a buscar desde el inicio y volverá a encontrar exactamente el mismo registro (si no se eliminó y lo que se busca es lo mismo que antes)...
pero... en el último programa (que subí)... la capacidad para seguir buscando desde el previo encontrado, está implementadaasí como una búsqueda parcial, (podrás ver en el menú que aparece un 'buscar siguiente', que admeás se activa o desactiva conforme la posibilidad de buscar un siguiente exista)...
La búsqueda parcial de un artículo tira del operador 'like' (que es la forma de usar expresiones regulares en vb6), por lo que te conviene que si pasas al primer proyecto, al menos incluyas los cambios acometidos a este respecto en el segundo (en el primero solo se dejó 'insinuado' dicha posibilidad, completarlo quedaba a tu cargo, sin embargo en el segundo lo dejé hecho).

La configuración dle wifi en el móvil, debe concordar con la configuracón aplicada en el router.
Accede al router y configúralo a tus necesidades... Si la seguridad la pones en wpa2, por ejemplo , pués eso mismo deberás aplicar luego en tu móvil. Si desactivas el DHCP para asignar IPs estáticas, pués tu móvil debe luego asignarse una IP en el rango acotado en el router..., etc...

Y sí, el WPS aunque pueda resultar 'cómodo', su activación favorece la inseguridad.
Si tienes aparatos de domótica, tienes que ver si admiten configuración del WIFI, en caso contrario te forzará a tenerlo activado por 'eggs'.

Tanto si eliges DHCP, como IPs estáticas, conviene como mínimo configurar una contraseña distinta de la que trae el WIFI de fábrica, es la configuración mínima que habría que hacer.

P.d.: En google, será relativamente fácil encontrar: "Cómo configurar el router 'tu marca - tu modelo' "

Venía a decirte que como ejercició está bien y hasta ahí, y que resolverte cada addedum solicitado, al final, acaba pareciendo más una tarea que un ejercicio.

Nota que, una vez más la asuencia de una especificación inicila y clara, obliga a cambiar cosas que se daban por 'definitivas', más aún se observa en la nueva petición que hay cosas en el aire, detalles ambiguos que al resolverlos uno debe decidirse por un lado, sin saber si luego será por el otro, y por tanto trabajo en vano.

Te comento por encima para que entiendas la diferencia de cosas y el problema de tirar al vuelo código sin una especificación.
Como mínimo esta debe estar perfectamente clara en tu mente (pero es algo que solo se adquiere con el tiempo), si no te entretienes a detallarla en papel o en un fichero... La ventaja del papel es que puedes mezclar texto y garabatos de forma rápida, guardaro en el bolsillo y llevártelo donde sea, que al momento que surja otra idea, puedes añadirla o modificar la previa. Así y todo al final procede pasarlo a un fichero, dejándolo libre de polvo y paja (tachones e ideas rechazadas)...
Antes de ponerte a escribir una sola línea de código, debes tener clara la especificación del problema a atacar. Si es simple, como digo puedes mantenerlo completamente en tu mente y hacer un esqueleto del mismo (en pseudocódigo), analizar alternativas y decidir según los objetivos perseguidos...


Añadir una ventana de ventas, implica todo esto:
- Añadir artículos a la venta. La que ahora es la 'ventana de compra', pasaría a ser esa de 'ventana de entrada de artículos'.
- Comprar artículos. Ahora la ventana de compra en vez de la actual de compra, sería la 'ventana de ventas', donde el vendedor expone todos sus artículos a la venta. Que igualmente con cada compra se pasarían al 'carrito de la compra' donde finalmente se acepta o se rechazan.
- Comprar un artículo definitivamente, debería reducir el 'stock' en venta. Por lo que esa 'ventana de artículos', debe al mismo tiempo añadir un campo con el concepto de 'stock disponible', y la 'ventana de entrada de artículos', debe modificarse, la cantidad (que antes implicaba la cantidad comprada), ahora indicaría la cantidad en stock disponible... El subtotal en este caso también cambiaría pues vendría a indicar el precio total del coste al proveedor. Además en esa misma ventana habría que poner otro precio, el de 'precio al cliente', pués el precio que ahí consta podría bien reflejar el precio al que el vendedor lo compró al proveedor.
- Si hay una ventana de ventas, es claro que habrá más de un cliente, pues el proyecto ahora mismo se aproxima más a uno para llevar control de sus propias compras, es decir un solo comprador (tú), administrando tus compras de aquí y allá. Una ventana de ventas, se aproxima más a la vista dle vendedor. En este caso hay más de una opción... ----- Se trata de (por ejemplo) una tienda de ropa?. Donde aunque solo hay un único vendedor (la tienda en sí), se personifica en cada empleado que atiende en la caja registradora... luego pueden considerarse varios vendedores. si miras tus tickets de compra de supermercados típicamente al final en la  impresión de la factura verás el típico: "Le atendió Patricia".
----- Se trata de una plataforma de ventas (por ejemplo amazon, eBay). Donde cada venddor no tiene nada que ver con otro vendedor.
En ambos casos, interesa hacer constar la referencia del vendedor (el nombre o Id del vendedor en el caso del primeor y el Id o alias en e l caso del segundo). Sin embargo una diferencia entre ambos, modos es que el el primero no requiere una identificación (login) de usuario, ni por tanto una cuenta registrada a su nombre. El usuario accede a la tienda, compra, paga y se va con sus artículos comprados. En el segundo caso, el usuario para poder comprar debe estar registrado (aunque puede comprar y añadir compras al carrito, a la hora de pagar, se le exigirán las credenciales.

También una ventana de ventas, supone una factura por (lote), por cada comprador. Antes la ventana de compras, acuñaba el id de compras y artículo a medida que estos eran comprados... (por que es una facturación de 'compras' es decir para uso privado del comprador), ahora esos ids, cambian el momento de ser creados. El de artículo debe acuñarse cuando el vendedor añade sus artículos al stock y el de lote, cuando el comrador lo adquiere y deben acompañar.

Luego una 'ventana de ventas' (ventana de artículos en venta), exige otra 'ventana de artículos vendidos' para poder despachar las ventas. Si se trata del segundo caso, debe llevar el campo id o alias del comprador, que además estará asociado con un registor en otro fichero con sus datos (para el envio). Aquí además entra en conflicto la concurrencia de eventos... del tipo: qué pasa si mientras un comprador mete un artículo en su carrito, y le pulsa pagar pasa el tiempo suficiente tal que otro comprador haya adquirido el mismo artículo y por tanto ya no esté en stock, o lo esté pero no en la cantidad solicitada por el comprador?. Exige implementar un sistema eficaz de algún tipo de bloqueo, o bien comprobar en el momento exacto del pago artículo por artículo si aún están en stock. Sea el método elegido que sea, debe ser lo más flexible posible para que la experiencia del comprador no sea 'desagradable' y descarte comprar de nuevo en 'ese sitio' por su mala gestión del stock'.

Igualmente la que ahora es la ventana de compras, lo sería para cada comprador, pero debería adaptarse al caso concreto de cada tipo de 'venta' comentado (hay más opciones pero son los dos casos generales).

En segun que condiciones, puede interesar que cada lote comprado sea un fichero señalando en tal caso como nombre de fichero el id del lote. Al caso tales ficheros tendrían dos registros distintos. el primero es un resumen de la compra: Cantidad de artículos comprados, fecha, numero de lote (que coincidirá con el nombre dle fichero), e id o alias del comprador (si procede) y el monto total de la compra. Y le siguen los registros de compra de cada artículo.
Esto simplificaría enormemente la 'ventana de articulos vendidos', pues la lista, contendría (imprescindible tan solo) los IdLote y puede que cualquier otro campo más, como montototal de la venta del lote, o la fecha, etc.. y si es extenso, contendría justamente la linea completa del registor dle lote que ecabeza cada fichero (aunque lo veo excesivo)... al pulsar en una línea de esa lista, se leería el lote y se presentarían sus detalles debajo de esa lista o en una ventana aparte.

Hablando de ventas, también procede una búsqueda por 'comprador' (dando su Id, o alias). Igualmente si se trata de una plataforma de ventas, donde cada comprador puede hacer compras a distintos vendedores, procede hacer búsquedas por id o alias de vendedor. No en cambio si el tipo de ventas es de un solo vendedor y los 'vendedores' son solo los empelados capacitdo para manejar la terminal de ventas. Aunque incluso así, el propio vendedor (la tiemda), podría querer consultar la ventas que ha realizado al cabo del mes cada uno de sus empleados, en defintiva... con ventas las posibilidades se disparan y deben quedar previamente  definidas y acotadas.

Otra cuestión menor es por ejemplo, tratándose solamente de un facturación personal de compras (loq eu creía que tenías entre manos hasta ahora), usar Ids de tipo integer satisfacen la aplicación. Las compras en un mes para una persona a lo sumo serán unos pocos cientos...  pero para ventas, la cosa cambia... el número de compradores puede ser desconocido, luego un tipo 'integer' (2^15 en vb6), no es válido, debe ser al menos de tipo 'long' (2^31 en vb6).

Cuando el número de registors en un fichero es elevado (con compras por mes, no creo que suceda, peor sí con ventas por mes), los métodos de búsqueda secuencial, pierden todo interés por su ineficiencia (para unos cientos son válidos y más que aceptables a cambio de su simplicidad, pués una búsqueda representará en tiempo apenas un parpadeo), para más cantidades procede tirar de tablas hash, o ciertos tipos de árboles, pero son un tema más avanzado, para el que se precisa tener ciertos conocimientos mucho más sólidos en el lenguaje con que se opera.

En fin, tienes detalles suficientes para avanzar en cualquier dirección que quieras el proyecto (te aconsejo que lo guardes, copies y pegues y hagas las modificaciones en la nueva copia) y código en el que fijarte para construir lo que te falte y requieras. Como puedes leer son tantos detalles (solo he tomado algunos al vuelo, al pormenor son muchos más), que es inaceptable proceder sin una especificación bien detallada. El abanico de posibilidades se abre demasiado.

Cuando tomas un taxi, tu le dices a dónde vas, el taxista ya conoce la ruta más óptima sea en km. o en tiempo según el día de la semana, hora del día, etc... ahora si le dices... vamos al campo de fútbol y cuando llegas... ahora esa calle al final, luego cuando llega.. ahora gira a la izquierda y avanza hasta la segunda calle y luego... el taxista va a ciegas... a un taxista le dará igual si al final recorres 20km. o si tardas 30 minutos más, pues cobra por el tiempo, pero si desde un principio le explicas voy a tal sitio que está dentro de tal ciudad/barrio... a buen seguro sale más barato. Aquí pasa lo mismo, se va 'conduciendo a ciegas', pareces ir a un sitio, peor al llegar dices, 'No, ahora vamos a ese otro sitio'...

Lo que pretendo decirte, es que ...al final, no es la complejidad, pues se desgrana todo en un árbol de decisión y cada cosa con sus detalles queda recogida y puede ser adecuada y convenientemente implementada y además no se tarda tanto, es la falta de una especificación completa del sistema desde el punto uno... lo que impide dar una solución definitiva al tema.

Si un día llegas a vivir profesionalmente de esto, te darás cuenta que: los peores clientes, los que hay que evitar a toda costa, los que hay que reconocer desde un principio para decirles no o dejar claro todo desde un principio, es justamente el que opera de este modo, cambiando contínuamente cosas, que hacen que el tiempo empleado en parte de lo previo no sirva para nada, que los plazos se alargan y nunca se termina el proyecto y que en muchos casos intentarán mantener el precio inicial sin cambios, basado en su punto de vista porque 'son solo unos pequeños cambios'. Incluso aunque el presupuesto inicial fuera más que generoso, es fácil al final acabar perdiendo dinero, tiempo y puede que hasta la paciencia 

No sé a qué te refieres exactamente... Si es por poner algo de código, no acostumbro a hacerlo, casi siempre pongo las explicaciones pertienentes y pseudocódigo. Peor cuando veo código espagueti, entiendo que el interesado no tiene la ayuda necesaria para avanzar...

Nadie discute que para viajar lejos, el avión el barco o un tren, lo hacen más barato.
Y para desplazamientos cercanos, un autobús o el metro también lo son.
...pero a pesar de todo eso, la gente sigue prefiriendo usar su propio vehículo, cuando puede incluso a pesar de que le salga algo más caro (viajar y manetener el vehículo), porque al final esos medios de transporte tienen 'paradas' y con tu vehículo, vas exactamente al punto donde necesitas (aunque luego en la práctica hay que aparcar donde haya espacio y por tanto toque andar lo mismo que si se hubiere usado el bus), y sobretodo con los horarios que quieras, sin depender de si, ya no hay buses o si el siguiente tardará 30 minutos en pasar...
Mira a tu alrededor y verás que al final sea con bici, monopatín, ciclomotor o coche (carro), la gente prefiere su propio vehículo casi siempre a un medio colectivo.

Hay un orden en las cosas... las bases de datos están al final del aprendizaje (de hecho jamás recomendaría SQLLite, sino SQLServer)... al comienzo los ficheros de texto, e incluso en ese punto, los de acceso secuencial y acceso aleatorio.
Cuando tenga la experiencia necesaria, es de esperar que avance. Saltar de la nada a las bases de datos, solo sirve para tener una nebulosa de como las cosas se hacen por debajo...

Me parece que lo interesante para Corlo, más incluso que resolver su problema con este ejercicio, es que acabe de entender la diferencia entre el código espagueti y un código organizado (ni siquiera le propongo utilizar clases), suele conseguirse con algo de paciencia, cuando comparan, acabarán por notar una diferencia por el contraste. Justo cuando hay un contraste entre el modo de hacer hasta ahora y el modo en que se ve algo (reciente o no), es cuando la gente tiene la oportunidad de avanzar (más rápido).

En cualquier caso, el hilo no va sobre filosofía del aprendizaje. Que cada cual se remita a lo que su interior le dicte, incluso creyendose en posesión de la verdad o del error, pues al final es sólo su tiempo (y no el de otro) lo que hay en juego.

Acabo de subirte el manual del Macro Assembler del 8051...
También dejé otros manuales al respecto por si teneis que hacer prácticas, o necesitais profundizar en detalles sobre el hardware.

https://elhacker.info/manuales/Hardware/Intel/Intel%2008051%209800937-02%20MCS-51%20Macro%20Assembler%20Users%20Guide%20Sep81.pdf

EI: edito para enlazar la URL publica.