Mensajes

El modo más sencillo de espantar a alguien de la programación, es llenarlo de detalles crudos en fases tempranas.

Basta una explicación general... tiempo tendrá de profundizar si sigue interesado en el tema, cuando ya adquiera una base.

Se hecha de menor aquellos tiempos en los que un S.O. era solo eso, un S.O. un gestor del equipo para facilitarle la vida al usuario. Ahora los S.O. tienen tantas aplicaciones y opciones, no deseadas, instaladas y activadas por defecto, que más que un Sistema Operativo, se convierten en un Sistema Inoperante.

Sería bueno que saliera un nuevo S.O. minimalista, que incluya todos los drivers para disponer y manejar el hardware, y poco más... más parecido a los que fue en su momento win-95. No quita que hubiera opcionalmente algún paquete más completo, pero así, opcional que se instale a petición del usuario si lo necesita.

[Imagina que el sistema operativo carga los datos de un proceso A en el segmento 1233h y lo marca como pertenenciente al proceso A.]

Pero los 4 bits adicionales siguen siendo los supuestos por el procesador al multiplicar por 0x10, ¿no?

No. Por eso son precisos dos registros..
Uno indica el segmento (por ejemplo CS) y el otro el desplazamiento (por ejemplo IP)
Además no vale cualquier pareja de registros. Cada registro de segmento admite unos específicos. Esto tiene que ver con la arquitectura del procesador.

Entonces es una convencion historica... lo supuse, en realidad me parecia poco eficiente considerando otras posibilidades.
Me atrevo a afirmar que el ser humano sacrifica su propio rendimiento por comodidad. Nuestra voluntad en contra de ella misma.

Bueno, es una licencia decirlo así...
El que inventa algo, lo hace como considera mejor (sea mejor por la economía, por los medios disponibles o por cualquier otra razón) en ese preciso momento.
Es muy fácil criticar 20, 50, ...x años después que hubiera sido mejor de esta u otra manera. Cuanto todo estaba oscuro y no había nada en lo que basarse para empezar, cualquier paso dado será el primero, si luego resulta problemático se supone que aprenderán y mejorarán.

1234h:0004h y
1233h:0014h

Calculando las direcciones:

12340h+04h=12344h y
12330h+14h=12344h

Segun Wikipedia: ...
Imagina que el sistema operativo carga los datos de un proceso A en el segmento 1233h y lo marca como pertenenciente al proceso A.
Luego, el segmento inmediatamente siguiente es 1234h, e imaginemos que aqui se cargan los datos de un proceso B.
Si el proceso A accede a sus datos, ¿no estaria accediendo a los datos del proceso B tambien?

A estas alturas (si leíste el enlace de mi anterior mensaje) ya sabes que hay 4096 pares de combinaciones para referirse a una misma dirección, es decir se estarían refiriendo al mismo segmento.

Ahora bien tu partes de una suposición (digamos) errónea... El sistema operativo, cuando asigna un segmento a un proceso, lo marca como ocupado (lleva control de ello en una estructura de datos), luego no va a asignar a otro proceso el mismo (o parcialmente el mismo) segmento.

Hay muchos algoritmos para el manejo de la memoria... Cuando funcionan bien se les supone libre de dichos errores. es lo mismo que si tu tuvieras un array y en un índice guardaras tal o cual dato y más adelante por error lo sobrescribieras por otro dato, sin pretender borrar el que estaba ahí antes. Se supone que cuando ese programa salga a la luz, habrás corregido el error, tan pronto te dieras cuenta...

Tiene que haber una manera de resolver esto, sin embargo no se me ocurre mas nada aparte del problema.

Básicamente se recurre a estructuras de árbol.

Hay varias estrategias, te expongo brevemente algunas ideas:
Al principio el árbol tiene (idealmente) toda la memoria libre, que ha particionado en x tamaño y asigna cada parte a un nodo de un árbol binario. Cada nodo tiene un estado para indicar libre u ocupado y si está ocupado cuanto está ocupado. En este árbol binario, solo los nodos terminales mantiene los datos, los nodos internos podrían considerarse como enrutadores rápidos, solo dispondran de datos muy simples que podrían (interesa que así sea) reflejar el total, pero sin disponer de las direcciones, datos que solo recáe en los nodos terminales.
Luego un proceso se inicia y requiere x espacio, entonces el árbol busca un nodo que disponga de ese tamaño. Si el nodo raíz indica que ese tamaño existe, revisa si su hijo izquierdo para ver si lo contiene, si no el hijo derecho. Y así va  sucesivamente descendiendo hasta el primer nodo que diga tener ese espacio libre, el nodo padre señala señala siempre el espacio libre de sus dos hijos, de modo que no hace falta explorar una rama si un padre declara que en su descendencia no hay memoria libre.
El nodo terminal proporciona la dirección física donde comienza ese espacio y la cantidad disponible.
Un S.O. podria asignar todo el espacio que señala que controla el nodo o bien podría asignar solo la imprescindible ocupada, con lo que partiría el nodo en dos nodos, a la derecha el nodo con la dirección  y el tamaño ocupado, al que marca ocupado y a la derecha el resto de memoria que ocupa ese padre, con la dirección y cantidad libre... como se ha tomado x memoria, a cada padre subiendo va descontando ese dato de 'libre'.
Si no basta un solo nodo para satisfacer la memoria requerida buscará si hay nodos contiguos con suficiente memoria libre, lo que complica la estructura, pués debe ser eficiente en cuanto a búsquedas. Pero ya sabemos que para eso basta consultar a algún padre...
Una de las operaciones de este tipo de estructuras debe ser la capacidad de mover datos de un lado de la memoria a otro precisamente para unificar memoria libre dispersa.
Inversamente a cuando se ocupa la memoria, cuando se libera, se accede al nodo hijo cuya memoria está contenido, se le marca libre e informa ascendentemente de la cantidad añadida.
Estos algoritmos tienen que hilar muy fino, pués el rendimiento de todo el sistema puede depender de su eficacia.

...y en definitiva el S.O. no va a entregar a sendos procesos un mismo espacio de memoria. Ten en cuenta además que los procesadores de hoy día disponen de muchas más intrucciones diseñadas explícitamente para el S.O. que hace 20, 30 ó 40 años.

Típicamente se usa el bit más bajo de cada píxel... La razón, es que con 256 tonos, uno más arriba o abajo, no cambia la imagen de cara al espectador (de hecho comprimirla en jpg o alguno otro formato con pérdida produce mayor pérdida).

Asi cada 8 píxeles obtienes un byte (considera little y big endian, pués no se sabe de qué equipo procedería), cada byte así formado se supone que será un carácter...

Pudiera ser que usara el bit más bajo de cada canal de cada píxel, con lo que serían 3 bits por píxel... y nuevamente deberías intentar en uno u otro orden RGB o BGR.

En alguna ocasión incluso he visto, que guardaban la info solo en el canal alfa a sabiendas.

...en fin, tú que eres el interesado, es quien debe perder el tiempo en ello, para buscar exactamente como está ocultado.

Esto viene de antiguo, de cuando la memoria era demasiado restringida.

Tiene que ver simplemente con el tamaño del bus de direcciones. Como supongo que sabrás, se empezó con 4 bits, luego se saltó a 8, luego a 16, 32, 64... pero... no es así de fácil.

Un microprocesador tiene 3 buses:
- el bus de datos.
- el bus de control.
- el bus de direcciones.

El bus de datos, determina el tamaño de 'palabra' que maneja la UAL... en tanto que el bus de direcciones maneja la memoria. Ha sido típico que cada salto, en realidad se haya dado (a menudo, no siempre) en 2 pasos... primero se duplicaba el tamaño del bus de direcciones y en otra se doblaba el tamaño del bus de datos.

El bus de direcciones casi siempre ha precisado ser mayor que el bus de datos. Aunque la memoria estuviera limitada, otros periféricos externos, odrían tener mucho más espaico al que era preciso poder acceder.

Si se usa un bus de direcciones de 16 bits, solo se puede acceder a 65536 posiciones de memoria... para los viejos micros de 8 bits (dle bus de datos), solía ser suficiente, pués empezaron teneinedo la friolera de 3-8kb. de datos... de los que además (algunos micros) para colmo, tenían una cantidad ya reservada por la ROM (caso típico de los ordenadores dirigidos al mercado doméstico.
De repende se dio el salt a los 16 bits, pero 64Kb. de memoria base daban para poco, especialmente para el acceso a disco... así, sin necesidad de dotar a tod el micro de 4 líneas más a todo el chip, se añadían por 'abajo' de la nada... y así se podían direccionar ya 20 bits, que daban para 1Mb. (2^20)...
El sistema se siguió usando pues era un modelo  útil. por ejemplo...

El sistema operativo, a menudo tiene que tratar con páginas de datos... hay muchos algoritmos, para intentar garantizar que haya memoria libre disponible junta preferentemente, esos algoritmos para hacer un uso eficiente de la memoria, precisan también compartimentar la memoria, lo mismo cuando se precisa guardar memoria a disco para liberarla y tener más memoria libre para alguna aplicación de forma puntual...

Por supuesto eso complica un poco al usuario (programador)... especialmente si no entiende qué hace o porqué existe.

Hoy día, yo no vería mal una paginación basada en 64Mb. de tamaño...

Por aquí, algo de info adicional:
https://foro.elhacker.net/programacion_visual_basic/simulador_segmentacion_paginada-t486073.0.html;msg2168899;topicseen#msg2168899

[casi cualquier ordenador con Thunderbolt 3 es inseguro]

Thunderspy: casi cualquier ordenador con Thunderbolt 3 es inseguro

...ordenadores con Windows o Linux anteriores a 2019 (y muchos posteriores) tienen una vulnerabilidad que permite saltarse la pantalla de login de un ordenador, e incluso el cifrado del disco duro para tener acceso a los datos.

El ataque requiere utilizar un destornillador para acceder al interior del ordenador para conectar un dispositivo temporalmente y modificar el firmware...

Vaya contradición.

Empieza diciendo que todo el mundo tiene que preocuparse, para luego acabar diciendo que solo si tienen acceso físico.... (tiempo, ocasión, conocimiento y un 'dispositivo apto' para hacer los cambios). Yo diría que eso lo restringe enormemente...

Un equipo con agujeros de seguridad físicos, pero inaccesible, forzosamente es seguro. Pongamos un ordenador con todos los fallos físicos de seguridad que se os ocurra... en una nave rumbo a Marte... quién rayos va a decir que es inseguro, si se requiere presencia física para acometer las fechorías.

Yo entiendo que las Universidades estudien, realicen pruebas e informen respecto de la seguridad... lo que no veo bien es que otros se hagan eco de la noticia y saquen conclusiones desproporcionadas.

Entra dentro de lo razonable que una app realizada-encargada por el fabricante de una marca de tabaco, pudiera fallar en la lectura de códigos de otro fabricante (aunque todavía sería lógico que reconociera el identificador del fabricante), especialmente para señalar si es o no légitimo o de contrabando.
...pero que falle con sus 'propios' productos, solo implica una de dos cosas:
A - Se trata de productos fabricados antes de la aplicación, antes de un cambio radical del sistema.
B - Se trata de falsificaciones, que por ser falsificaciones, simplemente 'pintan' un código de barras, que a todas luces es ilegible.

Para salir de dudas, se podría escribir un mail al fabricante, enviando foto o escan de del producto, donde aparece el código de barras, solicitando info con un mensaje similar a:
"Estos artículo no son leídos correctamente por la app "xxxx", marcan el mensaje de error "yyyyy", quisiera saber qué productos y en qué condiciones no puedan ser correctamente identificados por dicha app, para saber a qué atenerme respecto de dicho problema."
El mail, sería preferible ver de enviarlo primero al de la propia app... o bien a info general del fabricante  o en última instancia al correo (si tienen) relativo a anticontrabando.

Este es el tipo de noticias en el que uno no sabe si reir o llorar.
Reírse por el rídículo y llorar por las vidas que la torpeza ha costado.

Sin duda se trata de un misil autoguiado, y estos lo han disparado como si de un tiro con trayectoria fija desde el lanzamienrto se tratara. ...un error así, sería entendible para cualquiera excepto para alguien que diga ser militar.

Si yo ahi le doy Play anda, anda con el ShellExecute:

Private Declare Function ShellExecute Lib "shell32.dll" Alias _
    "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
    ByVal lpFile As String, ByVal lpParameters As String, _
    ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
   
'---------- El boton Play:

ret = ShellExecute(Me.hwnd, "Open", txtPath, "", "", 3)

Ya ahi anda, sin problemas, el bat y lo que sea.
Luego este boton, Guarda los TXT en una base de datos:
...
ContadorPreset es un bucle que guarda en otro registro un numero de codigo para no mezclar los registros de la BD
Luego, cargas esa preset desde el otro boton:
...
Y le das play, con el primer ShellExecute, y anda con todos los archivos, excepto con el Bat Con el bat se cierra la ventana DOS al cargar los datos del Bat....

El caso es que al final no veo ningún string con las rutas que fallan y con las rutas que funcionan...
El contenido del bat, carece de importancia, lo mismo que carecería de importancia el contenido de un txt, o de una imagen, lo que dices que falla es la apertura.


Aísla la llamada a una función como esta (a fin de ver que rutas recibe y que errores genera).

Código (vb) [Seleccionar] Expandir


Private Sub Ejecutar(ByRef Comando As String, ByRef Orden As String)
    Static contador As Long
    Const HANDLE_INSTANCIA As Long = 32

    Debug.Print contador ; comando;
    contador  = (contador  + 1)

    ret = ShellExecute(Me.hwnd, orden, comando, "", "", 3)

    If (ret <= HANDLE_INSTANCIA) Then
        Debug.Print " FALLO: " & ret
    Else
        Debug.Print
    End If
End Sub


que se llamaría así:

Código (vb) [Seleccionar] Expandir

call ejecutar(txtpath, "Open")

Ejecuta varias veces con los que funcionan y con los que no... haz luego una captura a la ventana debug ( y la subes a alguna web y la pones aquí), con las rutas y los valores de error, podrá determinarse qué sucede.
si además muestras la misma salida cuando dices que las ejecutas llamadas desde el commondialog, mejor que mejor, porque así podrá compararse las diferencias entre ambos paths.

[cabe preguntarse si cada marca no tiene a su vez la suya propia.]

Que 'la conexión no es segura', es un invento de Google, que se aplica a todas páginas webs con 'http' al no ser 'https'. Lo que no refleja la exactitud de la realidad, solo que no cifra el contenido.
Si no vas a enviar datos privados ni sensibles, no tiene más importancia.

Si Philip Morris, tiene su propia aplicación, cabe preguntarse si cada marca no tiene a su vez la suya propia. Creo que sería cuestión de acceder a la web de la marca de tu interés y buscar, o contactar con ellos y reclamarles si tienen alguno, disponible para sus consumidores.

Algunos campos de los códigos se dejan al libre uso de cada compañía, imagino que para que ellos tengan libertad de elección sobre como detectar que algo no es de su manufactura. La FNMT todavía seguirá reconociendo los códigos que identifiquen al fabricante, el producto, fecha etc...