En el otro hilo, ya te expliqué que hay dos librerías con los mismos componentes pero son diferente versión, si instancias aquella cuyo GUID no coincide, evidentemente no va a funcionar, da igual que los métodos sean idénticos...
- Bienvenido a Test Foro de elhacker.net SMF 2.1.
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#1431
Programación Visual Basic / Re: Esta OCX/DLL me tien harto, como la registro? MSComctlLib
21 Julio 2019, 18:56 PM #1432
Noticias / Re: La curiosa historia de "El Rincón del Vago", el portal web al que miles de ...
20 Julio 2019, 15:54 PM
...pués a mi siempre me parecieron (una gran parte de los habituales que solía tener) más del tipo de usuarios de 'forocoches', folloneros a más no poder, propio de post-adolescentes, atiborrados de alcohol, drogas y testosterona 'masturbina'... 
#1433
Foro Libre / Re: La Fuerza Aérea de EEUU advierte a quienes pretenden asaltar el 'Área 51'
18 Julio 2019, 23:04 PM
...pero si el alienígena vive en la "Casa Blanca"... creo que se han equivocado de escenario.
A "Machete", le vendría bien,, quien sabe si alguien se anima y crea un guión con esa idea (el título bien podría ser "Asalto al Área-51") y lo acaba protagonizando...
A "Machete", le vendría bien,, quien sabe si alguien se anima y crea un guión con esa idea (el título bien podría ser "Asalto al Área-51") y lo acaba protagonizando...
#1435
Desarrollo Web / Re: Cuanto pesa una pagina web?
17 Julio 2019, 12:00 PMCita de: torrealba2719 en 16 Julio 2019, 12:24 PMNo. Es como preguntar si es posible saber cuanto pesan todos los ciudadanos de una ciudad. No es algo que se tenga precalculado (tal vez si el site de hospedaje que lleva la cuenta del espacio ocupado por el cliente), pero no es un dato accesible.
...sera posible saber cuanto pesa la pagina completa?? ya que se ira descargando en html pagina por pagina..
Eso implica que el único modo de saberlo es recorriendo las páginas y haciendo la suma pertinente. Ten en cuenta que es fácil pretender proteger un sitio contra esto a base de generar ficheros vacios de varios GB. así perderías horas total para descargar nada (pero no es habitual encontrar sitios con tal protección).
#1436
Java / Re: clases hijas que al ser instanciadas tienen el mismo valor del atributo estatico
17 Julio 2019, 10:58 AM
Un campo debe ser estático, cuando sin importar la instancia ese valor deba mantenerse siempre así. Y a lo sumo ser cambiado desde donde se puede (pero para todas las instancias), de no ser así entonces sería preferible que fuera una constante.
Para entenderlo lo mejor es exponer un ejemplo:
He crado una interfaz vehículo... de la que luego he implementado una clase 'bicicleta', la clase bicicleta expone uel miembro estático "número de ruedas", cuyo valor evidente es 2... pués una bicicleta siempre tiene dos ruedas, si tiene otra cantidad será otro tipo de vehículo, no una bici... Si más tarde implemento una clase Triciclo, igualmente a ese campo le asignaría 3 ruedas, y si fuera 'coche' 4....
Ahora bien, supongmaos que tenemos un valor "Kilometros" (recorridos), carece de sentido que ese miembro sea estático... debe ir cambiando contínuamente.
Luego en tu diseño debes saber cuando un campo tiene que ser una constante, cuando estático y cuando variable.
En tu ejemplo, "saldo", es una cantidad que va a estar variando contínuamente, luego carece sentido de ponerle el atributo estático.
El uso más claro para el atributo 'static' suele verse en los métodos/funciones.
Supongamos que independientemente de cual sea la clase de vehículo creado, hay un método Pintar(color), si para todos los tipos de vehículos el método va a hacer siempre lo mismo, se hace estático, lo que en la práctica implica que solo existirá una copia de ese método en memoria y que es compartido por todos y que por supuesto no retiene datos de ninguno en específico, toma lo que se le da, hace el trabajo y lo entrega... internamente (sobre sí, no modifica nada que luego haría fallar algo, por ejemplo no importaría que internamente tuviera un campo que contara cuantos vehículos ha pintado y que se autoincremente con cada invocación, pués eso no interfiere con el trabajo que debe hacer).
Dicho de otra manera, cuando un miembro o método usa el atributo 'static' existe una única dirección para ese miembro/método en todas las instancias y es la misma. si no es 'static' cada instancia posee una dirección de memoria propia del miembro/método es decir es particular.
Es algo así como que en cada ciudad hay un solo alcalde... pero en cada casa habrá (por poner un ejemplo), una madre, un padre y un hijo, ...pero el alcalde, es el mismo para cada casa de dicha ciudad. Así, los miembros/métodos estáticos son compartidos por todas las instancias.
Aquí una ligera explicación (los ejemplos no son precisamente buenos, pero el texto inicial sí):
https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html
Releyéndote, me parece entenderte mejor, pués aclaras que el saldo no es el de un cliente cualquiera si no el del cajero... lo cual por supuesto interesa proteger...
Bien en caso así, nota que lo que necesitas es el "static int SaldoInicial = 900" y luego otro miembro llamado (por ejemplo) "int saldoActual"
Ahora tu externamente operas con tu métodos 'depositar/extraer', pero estos alteran solo el 'SaldoActual' no el 'SaldoInicial'...
Un ejemplo en pseudocódigo para no perderse en detalles del lenguaje y hacerlo engorroso con 500 palabras superfluas...
Como se ve se opera con 'saldoactual'. El campo "saldoActual" inicialmente vale 0, pero al consultarlo suma siempre el valor 900 del campo "saldoInicial", el depósito queda a cero, cuando saldoActual = -900, pués -900 + SaldoInicial = (900-900) = 0
en el mensaje de 'no queda saldo... directamente s ele podría decir cuanto saldo queda, haciendo las cuentas pertienentes
Por último, nota además como tanto el saldoInicial como el SaldoActual están protegidos para solo ser leídos y no sobreescritos (con de solo lectura, no se proveen métodos de escritura), la única manera de escribir un nuevo valor en SaldoActual es a través de las operaciones: Depositar y Extraer. Y en cuanto a SaldoInicial, lo lógico es que cuando llegare el furgón blindado, si pudiera de nuevo ser modificado (si no, sería una constante), pero para eso debe hacerse con su propio método en su clase y siendo dicho método no accesible por las instancias...
Para entenderlo lo mejor es exponer un ejemplo:
He crado una interfaz vehículo... de la que luego he implementado una clase 'bicicleta', la clase bicicleta expone uel miembro estático "número de ruedas", cuyo valor evidente es 2... pués una bicicleta siempre tiene dos ruedas, si tiene otra cantidad será otro tipo de vehículo, no una bici... Si más tarde implemento una clase Triciclo, igualmente a ese campo le asignaría 3 ruedas, y si fuera 'coche' 4....
Ahora bien, supongmaos que tenemos un valor "Kilometros" (recorridos), carece de sentido que ese miembro sea estático... debe ir cambiando contínuamente.
Luego en tu diseño debes saber cuando un campo tiene que ser una constante, cuando estático y cuando variable.
En tu ejemplo, "saldo", es una cantidad que va a estar variando contínuamente, luego carece sentido de ponerle el atributo estático.
El uso más claro para el atributo 'static' suele verse en los métodos/funciones.
Supongamos que independientemente de cual sea la clase de vehículo creado, hay un método Pintar(color), si para todos los tipos de vehículos el método va a hacer siempre lo mismo, se hace estático, lo que en la práctica implica que solo existirá una copia de ese método en memoria y que es compartido por todos y que por supuesto no retiene datos de ninguno en específico, toma lo que se le da, hace el trabajo y lo entrega... internamente (sobre sí, no modifica nada que luego haría fallar algo, por ejemplo no importaría que internamente tuviera un campo que contara cuantos vehículos ha pintado y que se autoincremente con cada invocación, pués eso no interfiere con el trabajo que debe hacer).
Dicho de otra manera, cuando un miembro o método usa el atributo 'static' existe una única dirección para ese miembro/método en todas las instancias y es la misma. si no es 'static' cada instancia posee una dirección de memoria propia del miembro/método es decir es particular.
Es algo así como que en cada ciudad hay un solo alcalde... pero en cada casa habrá (por poner un ejemplo), una madre, un padre y un hijo, ...pero el alcalde, es el mismo para cada casa de dicha ciudad. Así, los miembros/métodos estáticos son compartidos por todas las instancias.
Aquí una ligera explicación (los ejemplos no son precisamente buenos, pero el texto inicial sí):
https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html
Releyéndote, me parece entenderte mejor, pués aclaras que el saldo no es el de un cliente cualquiera si no el del cajero... lo cual por supuesto interesa proteger...
Bien en caso así, nota que lo que necesitas es el "static int SaldoInicial = 900" y luego otro miembro llamado (por ejemplo) "int saldoActual"
Ahora tu externamente operas con tu métodos 'depositar/extraer', pero estos alteran solo el 'SaldoActual' no el 'SaldoInicial'...
Un ejemplo en pseudocódigo para no perderse en detalles del lenguaje y hacerlo engorroso con 500 palabras superfluas...
Código [Seleccionar]
satic int SaldoInicial = 900
int SaltoActual = 0
getSaldoInicial{
devolver SaldoInicial
}
getSaldoActual{
devolver (SaldoActual + SaldoInicial)
}
void Depositar(int cantidad){
Si (cantidad >0) // no quremos que deposite valores negativos, para el caso mejor declarar 'cantidad' como un entero sin signo, así siempre será positivo.
SaldoActual += cantidad
fin si
}
void Extraer(int cantidad){
Si (cantidad > 0) // no queremos que extraiga valores negativos, para el caso mejor declarar 'cantidad' como un entero sin signo, así siempre será positivo.
Si (getSaldoActual -cantidad) >0)
SaldoActual -= cantidad
Sino
Mensaje "no queda suficiente saldo en depósito en el 'cajero', para realizar la transacción (intente con una cantidad menor)..."
fin si
fin si
}
Como se ve se opera con 'saldoactual'. El campo "saldoActual" inicialmente vale 0, pero al consultarlo suma siempre el valor 900 del campo "saldoInicial", el depósito queda a cero, cuando saldoActual = -900, pués -900 + SaldoInicial = (900-900) = 0
en el mensaje de 'no queda saldo... directamente s ele podría decir cuanto saldo queda, haciendo las cuentas pertienentes
Código [Seleccionar]
void Extraer(int cantidad){ // no queremos que extraiga valores negativos, para el caso mejor declarar 'cantidad' como un entero sin signo, así siempre será positivo.
int tmp
Si (cantidad > 0)
tmp = (getSaldoActual - cantidad)
Si (tmp >0)
SaldoActual -= cantidad
Sino
tmp = (cantidad - getSaldoActual) //cantidad solicitada es mayor que cantidad en depósito.
Mensaje "No queda en depósito la cantidad solicitada, el máximo que podría extraer ahora mismo del 'cajero' es: tmp ..."
fin si
fin si
}
Por último, nota además como tanto el saldoInicial como el SaldoActual están protegidos para solo ser leídos y no sobreescritos (con de solo lectura, no se proveen métodos de escritura), la única manera de escribir un nuevo valor en SaldoActual es a través de las operaciones: Depositar y Extraer. Y en cuanto a SaldoInicial, lo lógico es que cuando llegare el furgón blindado, si pudiera de nuevo ser modificado (si no, sería una constante), pero para eso debe hacerse con su propio método en su clase y siendo dicho método no accesible por las instancias...
#1437
Ingeniería Inversa / Re: Desbloquear contraseña de apertura de Excel o metodo para hacerlo
17 Julio 2019, 10:49 AM
Primero amenazadlo con denunciarlo a la policía y exigirle daños y perjuicios (monto que le perseguirá toda su vida) ...quizás solo con la amenaza se avenga a las buenas y dé la contraseña, de lo contrario, presentad denuncia.
Un empleado es custodio de su trabajo, por ello es lícito que use contraseñas, pero si se va de la empresa, la custodia es cedida/transferida de nuevo a la empresa (al nuevo empleado que ocupe su puesto) y por tanto el empleado que se va debe aportar cuanta documentación sea precisa. En todo caso, él podrá exigir un papel firmado, donde se alegue que entrega todo conforme, incluída contraseña...
...puede que su resentimiento a entregarla sea por que esté tapando algo sucio de lo que no quiere que la empresa se entere, así que cuanto antes procedais primero a notificarle que estais dispuesto a denunciarlo y demandarlo por daños y perjuicios a la empresa, antes podreis tener acceso.
Si al final hizo algún daño, y vosotros accedeis a la fuerza (violando la contraseña), al contenido, fácilmente podría su abogado alegar que él lo dejó todo bien y que después vosotros (quienes sena 'vosotros'), hicieron cambios a aposterior hasta el punto de que forzaron la contraseña... y ahí es bastante probable que tengais las de perder, ya dependería más de la tontuna del propio juez.
Un empleado es custodio de su trabajo, por ello es lícito que use contraseñas, pero si se va de la empresa, la custodia es cedida/transferida de nuevo a la empresa (al nuevo empleado que ocupe su puesto) y por tanto el empleado que se va debe aportar cuanta documentación sea precisa. En todo caso, él podrá exigir un papel firmado, donde se alegue que entrega todo conforme, incluída contraseña...
...puede que su resentimiento a entregarla sea por que esté tapando algo sucio de lo que no quiere que la empresa se entere, así que cuanto antes procedais primero a notificarle que estais dispuesto a denunciarlo y demandarlo por daños y perjuicios a la empresa, antes podreis tener acceso.
Si al final hizo algún daño, y vosotros accedeis a la fuerza (violando la contraseña), al contenido, fácilmente podría su abogado alegar que él lo dejó todo bien y que después vosotros (quienes sena 'vosotros'), hicieron cambios a aposterior hasta el punto de que forzaron la contraseña... y ahí es bastante probable que tengais las de perder, ya dependería más de la tontuna del propio juez.
#1438
Criptografía / Re: Manuscrito Voynich. El santo grial de la criptografía.
16 Julio 2019, 15:34 PM
No veo adecuado considerar que quien escribiera el texto, tratarlo como si fuera una persona con la psicología de una persona de hoy día... Hay varias consideraciones a tener en cuenta.
- Si fuera algo como un libro de un herrero, para qué iba a guardar secretos? ....de tenerlos para qué los iba a publicar? ...de ser un herrero, de seguro que ni sabría dibujar ni mucho menos leer y escribir, cuanto menos inventarse una escritura. Así que olvida la idea de que el contenido se trate de cosas banales y triviales y que fuera elaborado por 'un cualquiera'. Forzosamente debía ser alguien muy culto.
- No es adecuado hacer suposiciones de que fuera una sola persona, aunque no veo nada malo en empezar partiendo por esa idea, siempre que no se la considere como inamovible. Los monjes acostumbraban a escribir libros, y desde luego no era raro que un mismo libro se escribiera por varios monjes... los monjes dedicaban años a la caligrafía, luego la similitud del trazo entre uno y otro monje no era mayor que tu misma escritura en diversos momentos de tu día a día... esto es, cuando tienes prisas tu letra cambia respecto de cuando no tienes ninguna, cuando estás iracundo de cuando estás feliz, cuando estás nervioso de cuando estás relajado, cambia incluso cuando tienes sueño, etc... todas son tu letra pero con ligerísimas diferencias.
- Obviamente concuerdo en que no se usó un algrotimo matemático complejo en extremo para hacer una traducción. Pero la traducción y la escritura no tienen porqué reflejarse en la fluidez de la escritura. Es más que probable que fuere elaborado en dos fases... pudo haberse consignado primero con mayor lentitud en un boceto la traducción lo que habría que escribirse, y luego en una segunda fase la transcripción 'a limpio', ser más fluída.
Por lo que conjeturar que la fluidez en la escritura es decisiva, es demasiado suponer al ignorar que cualquier artista, siempre esgrime bocetos que son los que le llevan tiempo... por supuesto no debe algo tan complejo que traducir una palabra suponga 10 minutos, aunque sea primero escrito en un boceto. Yo creo que es más ingenioso que elaborado, más alegórico que matemático.
- Incluso aunque la escritura fuera elaborada por una única persona, ésta pudo haber encargado los dibujos a otra de confianza... llegando al dibujo final a través de esbozos previos... La lástima es que no hay forma de confirmar que un dibujo corresponde al mismo puño que el que hizo la letra, incluso aunque hubiera algún cierto margen de error. Sin embargo de ser la misma y única persona quien elaborara tanto el texto como los dibujos, es forzoso asumir que estaba más cultivado en conocimientos y arte de lo que cabría suponer si son dos personas distintas. Cuanto más admitados que sea culta quien lo elaboró, cabe suponer que tanta más complejidad o imaginación ha sido capaz de elaborar para ello.
...en mi opinión la forma más sencilla de errar es ir con ideas preconcebidas de cómo se ha procedido en su elaboración, especialmente cuando quienes lo hicieron vivieron en unas fechas en las que sus problemas cotidianos (los existenciales siempre han sido y serán los mismos) eran muy distintos a los de hoy día... Hay que mirar el texto, saber dónde y en qué fecha fue escrito y hacer comparaciones con otros textos del mismo lugar y época para dictaminar diferencias... en aquelllas fechas no había prisas editoriales para entregar a la imprenta y empezar a vender para recaudar la inversión, así hacer un libro manuscrito es un proceso que podría durar incluso años y al igual que hoy día un autor descarta parte del texto y lo tira a la basura, también era frecuente tener que rehacer algún pergamino por culpa del vertido accidental de tinta o por que alguna pluma hacía malos trazos, etc...
- Si fuera algo como un libro de un herrero, para qué iba a guardar secretos? ....de tenerlos para qué los iba a publicar? ...de ser un herrero, de seguro que ni sabría dibujar ni mucho menos leer y escribir, cuanto menos inventarse una escritura. Así que olvida la idea de que el contenido se trate de cosas banales y triviales y que fuera elaborado por 'un cualquiera'. Forzosamente debía ser alguien muy culto.
- No es adecuado hacer suposiciones de que fuera una sola persona, aunque no veo nada malo en empezar partiendo por esa idea, siempre que no se la considere como inamovible. Los monjes acostumbraban a escribir libros, y desde luego no era raro que un mismo libro se escribiera por varios monjes... los monjes dedicaban años a la caligrafía, luego la similitud del trazo entre uno y otro monje no era mayor que tu misma escritura en diversos momentos de tu día a día... esto es, cuando tienes prisas tu letra cambia respecto de cuando no tienes ninguna, cuando estás iracundo de cuando estás feliz, cuando estás nervioso de cuando estás relajado, cambia incluso cuando tienes sueño, etc... todas son tu letra pero con ligerísimas diferencias.
- Obviamente concuerdo en que no se usó un algrotimo matemático complejo en extremo para hacer una traducción. Pero la traducción y la escritura no tienen porqué reflejarse en la fluidez de la escritura. Es más que probable que fuere elaborado en dos fases... pudo haberse consignado primero con mayor lentitud en un boceto la traducción lo que habría que escribirse, y luego en una segunda fase la transcripción 'a limpio', ser más fluída.
Por lo que conjeturar que la fluidez en la escritura es decisiva, es demasiado suponer al ignorar que cualquier artista, siempre esgrime bocetos que son los que le llevan tiempo... por supuesto no debe algo tan complejo que traducir una palabra suponga 10 minutos, aunque sea primero escrito en un boceto. Yo creo que es más ingenioso que elaborado, más alegórico que matemático.
- Incluso aunque la escritura fuera elaborada por una única persona, ésta pudo haber encargado los dibujos a otra de confianza... llegando al dibujo final a través de esbozos previos... La lástima es que no hay forma de confirmar que un dibujo corresponde al mismo puño que el que hizo la letra, incluso aunque hubiera algún cierto margen de error. Sin embargo de ser la misma y única persona quien elaborara tanto el texto como los dibujos, es forzoso asumir que estaba más cultivado en conocimientos y arte de lo que cabría suponer si son dos personas distintas. Cuanto más admitados que sea culta quien lo elaboró, cabe suponer que tanta más complejidad o imaginación ha sido capaz de elaborar para ello.
...en mi opinión la forma más sencilla de errar es ir con ideas preconcebidas de cómo se ha procedido en su elaboración, especialmente cuando quienes lo hicieron vivieron en unas fechas en las que sus problemas cotidianos (los existenciales siempre han sido y serán los mismos) eran muy distintos a los de hoy día... Hay que mirar el texto, saber dónde y en qué fecha fue escrito y hacer comparaciones con otros textos del mismo lugar y época para dictaminar diferencias... en aquelllas fechas no había prisas editoriales para entregar a la imprenta y empezar a vender para recaudar la inversión, así hacer un libro manuscrito es un proceso que podría durar incluso años y al igual que hoy día un autor descarta parte del texto y lo tira a la basura, también era frecuente tener que rehacer algún pergamino por culpa del vertido accidental de tinta o por que alguna pluma hacía malos trazos, etc...
#1439
Criptografía / Re: Manuscrito Voynich. El santo grial de la criptografía.
15 Julio 2019, 16:22 PM
Si quieres aventurarte a investigarlo, mi consejo es que primero repases lo que otros hayan hecho ya, para no perder el tiempo.
Hay varios documentales... supongo que por youtube podrán encontrarse algunos. Algunos se centran en la Historia del documento... esa parte prácticamente no ayuda demasiado, salvo para reconocer países y fechas y en base a ello documentarse con las tipografías de la época y lugar. Interesan más los documentales que tratan las teorías de su cometido, aunque quí tampoco ayuda demasiado ya que la teoría que sobresale precisamente es una que dice que fue creado por un embaucador para estafar al noble de turno, lo cual es poco más o menos que admitir que es falso, luego admitiendo tal posibilidad supondría perder el tiempo y estaría de más decir algo...
A poco que se analice el documento se observa que pasa un análisis estadístico de lo que efectivamente sería un texto coherente, por lo que esa teoría de la estafa, cae con un simple estudio. Es imposible que una época en la que la criptografía era muy limitada se fueran a dar condiciones de lo que científicamente varios siglos después, se esperaría de un documento auténtico.
Otras teorías tiran por un 'viajero' sea del tiempo o del espacio, que procedente de otro lugar simplemente fuera un libro de 'su cultura'. Tampoco me atrae esta teoría pués hay suficientes elementos culturales nuestros como para que no se dé tal cuestión.
Mi teoría personal es que alguien describe por medio de parábolas operaciones de alquimia. En el texto se daría todo con detalle y en las imágenes de modo figurado, parabólico para terminar de entender el texto. Bajo mi punto de vista estudiar el texto abstrayéndose de las imágenes no conducirán a nada provechoso.
En esas indagaciones previas que yo hice, pués por ejemplo encontré una fuente (tipografía), que recoge precisamente los diferentes signos que aparecen, lo que facilita hacer una transcripción a ficheros (en vez de tener que trabajar con imágenes) y tener que escribir un programa para detectar adecuadamente cada símbolo...
Enlace de descarga para la fuente: E.V.A. (European Voynich Alphabet)
https://workupload.com/file/pdV75Xzj 42kb. aprox.
Un par de imágenes...
Una vez que hagas una transcripción (por ejemplo de una página), a un fichero de texto, pués al menos ya tendrás asequible hacer análisis de frecuencia...
En fin la primera fase es precisamente hacer una transcripción a algo manejable, la fuente te facilita bastante la tarea... (aunque creo recordar que eran al menos 2 fuentes, sin embargo en este quipo solo tengo instalada ésa).
Hay varios documentales... supongo que por youtube podrán encontrarse algunos. Algunos se centran en la Historia del documento... esa parte prácticamente no ayuda demasiado, salvo para reconocer países y fechas y en base a ello documentarse con las tipografías de la época y lugar. Interesan más los documentales que tratan las teorías de su cometido, aunque quí tampoco ayuda demasiado ya que la teoría que sobresale precisamente es una que dice que fue creado por un embaucador para estafar al noble de turno, lo cual es poco más o menos que admitir que es falso, luego admitiendo tal posibilidad supondría perder el tiempo y estaría de más decir algo...
A poco que se analice el documento se observa que pasa un análisis estadístico de lo que efectivamente sería un texto coherente, por lo que esa teoría de la estafa, cae con un simple estudio. Es imposible que una época en la que la criptografía era muy limitada se fueran a dar condiciones de lo que científicamente varios siglos después, se esperaría de un documento auténtico.
Otras teorías tiran por un 'viajero' sea del tiempo o del espacio, que procedente de otro lugar simplemente fuera un libro de 'su cultura'. Tampoco me atrae esta teoría pués hay suficientes elementos culturales nuestros como para que no se dé tal cuestión.
Mi teoría personal es que alguien describe por medio de parábolas operaciones de alquimia. En el texto se daría todo con detalle y en las imágenes de modo figurado, parabólico para terminar de entender el texto. Bajo mi punto de vista estudiar el texto abstrayéndose de las imágenes no conducirán a nada provechoso.
En esas indagaciones previas que yo hice, pués por ejemplo encontré una fuente (tipografía), que recoge precisamente los diferentes signos que aparecen, lo que facilita hacer una transcripción a ficheros (en vez de tener que trabajar con imágenes) y tener que escribir un programa para detectar adecuadamente cada símbolo...
Enlace de descarga para la fuente: E.V.A. (European Voynich Alphabet)
https://workupload.com/file/pdV75Xzj 42kb. aprox.
Un par de imágenes...
Una vez que hagas una transcripción (por ejemplo de una página), a un fichero de texto, pués al menos ya tendrás asequible hacer análisis de frecuencia...
En fin la primera fase es precisamente hacer una transcripción a algo manejable, la fuente te facilita bastante la tarea... (aunque creo recordar que eran al menos 2 fuentes, sin embargo en este quipo solo tengo instalada ésa).
#1440
Programación Visual Basic / Re: Aplicación Visual Basic que truena
15 Julio 2019, 15:42 PM
Instala el servicepack sp6 de visual Studio. El servicepack, no va a dañar nada funcional, sino al contrario haría que si algo operaba con el sp6, y uego no está presente si que diere problemas, luego instalarlo, debería solventarlo.
No das los detalles que realmente importan... pero al menos es de suponer que un programa más o menos complejo tendrá librerías compiladas al mismo tiempo,.. sería adecuado cuando compiles que señales la compatibilidad adecuada al caso. "compatibilidad de versión"... esto es, repasa adecuadamente las propiedades del proyecto.
Justo acabo de compartir el archivo en otro mensaje, para instalar... copio y pego aquí:
Es normal que no te dejen operar en el equipo de producción si allí funciona todo bien, no pueden arriesgarse a que alguna prueba lo dañe... Lo adecuado, sería crear una imagen del disco duro de ese equipo, reproducirla en otro idéntico, y ahí sí, ya podrías operar sin miedo a dañar nada... como es copia idéntica cuando funcione el nuevo sistema sin problemas podría asegurarse que también lo haría en el equipo de producción, aunque igualmente aconsejo antes de hacer cambios, crear una imagen del equipo al momento actual... también sería adecuado que te prestaran 2 o 3 equipos viejos para probar en remoto, igualmente sería conforme que fueran una imagen de sendos equipos reales y así se vería como afecta.
Ten en cuenta que compilar un mismo proyecto siempre arrojará un ejecutable distinto aunque todo lo demás fuera igual (por cuestión de la fecha). En cuanto a la variación de tamaño del ejecutable, perfectamente puede obedecer a la configuración de la compilación, por ejemplo si en las propiedades del proyecto eliges compilar para código reducido o código rápido, etc... generará ejecutables de diferentes tamaños. Eso sí, no compiles a p-code, compila a código nativo, por cuestión de eficiencia.
También podría variar el tamaño si se hayan añadido/eliminado mensajes de texto (por ejemplo basta el simple mensaje del 'about', que hacía referencia al autor/es previo/s para que varíe 1-3kb.).
El modo más adecuado de hacer cambios en sistemas complejos es hacerlo en fases... primero x cosa cuando funcione se hace el siguiente cambio. Si algo falla al menos queda claro que fase contiene los errores y minimiza donde encontrarlos. Pretender hacer 25 cambios (nuevo programa, nuevas BDs, nuevas conexiones, nuevos S.O., etc...) te complica las cosas, porque cuando algo no depende de tí, la info que provea del problema, pués eso 'no depende de tí'...
...dicho de otro modo, prueba primero a que el programa funcione con los viejos medidores (esto te asegura que la versión del que tienes el código fuente, está completo y libre de errores, quien sabe si esa era una versión previa con errores que luego se corrigieron en una nueva versión de la cual no se posee el código fuente)... Si ahora el programa que tú compilas funciona bien con los viejos medidores y con todo lo viejo, puedes asumir que el código fuente es correcto y es a partir de ahí que debes hacer los cambios (copia del proyecto para trabajar en la nueva copia), para operar con los nuevos medidores.
Y si ahora hay problemas ya sabes que cosas pueden ser descartadas y en cuales centrarte... en fin procede en pasos lógicos que descarten desde el origen que tengan problemas y por tanto dar por sentado que los errores están en partes donde no están. en proyectos grandes es fácil que un problema afecte a distintas partes, pero entendiendo el error queda claro como y dónde solucionarlo, pero si ni siquieras llega uno a czar el errror se va a ciegas... subiendo escalones uno a uno, cuando uno se rompa y te caigas, ya sabes que ese escalón falla, se arregl y se sigue adelante...
No das los detalles que realmente importan... pero al menos es de suponer que un programa más o menos complejo tendrá librerías compiladas al mismo tiempo,.. sería adecuado cuando compiles que señales la compatibilidad adecuada al caso. "compatibilidad de versión"... esto es, repasa adecuadamente las propiedades del proyecto.
Justo acabo de compartir el archivo en otro mensaje, para instalar... copio y pego aquí:
Citar
Aquí las descargasque señalé ayer...
https://workupload.com/archive/CrtCf8Z
Accesible las 2 siguientes descargas:
1 - VB60SP6-KB957924-v2-x86-ESN.msi - 9'80Mb. Actualización acumulada para vb6 - sp6 (español). Contendrá todas las librerías que pudieran faltarte...
2 - vb6cli - Problemas de licencia de controles.rar - 26kb. leer el txt que viene dentro, para tener claro su cometido...
Es normal que no te dejen operar en el equipo de producción si allí funciona todo bien, no pueden arriesgarse a que alguna prueba lo dañe... Lo adecuado, sería crear una imagen del disco duro de ese equipo, reproducirla en otro idéntico, y ahí sí, ya podrías operar sin miedo a dañar nada... como es copia idéntica cuando funcione el nuevo sistema sin problemas podría asegurarse que también lo haría en el equipo de producción, aunque igualmente aconsejo antes de hacer cambios, crear una imagen del equipo al momento actual... también sería adecuado que te prestaran 2 o 3 equipos viejos para probar en remoto, igualmente sería conforme que fueran una imagen de sendos equipos reales y así se vería como afecta.
Ten en cuenta que compilar un mismo proyecto siempre arrojará un ejecutable distinto aunque todo lo demás fuera igual (por cuestión de la fecha). En cuanto a la variación de tamaño del ejecutable, perfectamente puede obedecer a la configuración de la compilación, por ejemplo si en las propiedades del proyecto eliges compilar para código reducido o código rápido, etc... generará ejecutables de diferentes tamaños. Eso sí, no compiles a p-code, compila a código nativo, por cuestión de eficiencia.
También podría variar el tamaño si se hayan añadido/eliminado mensajes de texto (por ejemplo basta el simple mensaje del 'about', que hacía referencia al autor/es previo/s para que varíe 1-3kb.).
El modo más adecuado de hacer cambios en sistemas complejos es hacerlo en fases... primero x cosa cuando funcione se hace el siguiente cambio. Si algo falla al menos queda claro que fase contiene los errores y minimiza donde encontrarlos. Pretender hacer 25 cambios (nuevo programa, nuevas BDs, nuevas conexiones, nuevos S.O., etc...) te complica las cosas, porque cuando algo no depende de tí, la info que provea del problema, pués eso 'no depende de tí'...
...dicho de otro modo, prueba primero a que el programa funcione con los viejos medidores (esto te asegura que la versión del que tienes el código fuente, está completo y libre de errores, quien sabe si esa era una versión previa con errores que luego se corrigieron en una nueva versión de la cual no se posee el código fuente)... Si ahora el programa que tú compilas funciona bien con los viejos medidores y con todo lo viejo, puedes asumir que el código fuente es correcto y es a partir de ahí que debes hacer los cambios (copia del proyecto para trabajar en la nueva copia), para operar con los nuevos medidores.
Y si ahora hay problemas ya sabes que cosas pueden ser descartadas y en cuales centrarte... en fin procede en pasos lógicos que descarten desde el origen que tengan problemas y por tanto dar por sentado que los errores están en partes donde no están. en proyectos grandes es fácil que un problema afecte a distintas partes, pero entendiendo el error queda claro como y dónde solucionarlo, pero si ni siquieras llega uno a czar el errror se va a ciegas... subiendo escalones uno a uno, cuando uno se rompa y te caigas, ya sabes que ese escalón falla, se arregl y se sigue adelante...