Mensajes

Pero si sigo tus instrucciones puedo desactivarlo,pero el modem va a seguir emitiendo ondas a toda mi casa?justamente eso no quiero.gracias. Solo quiero que quede funcionando internet por cable. Gracias.

Si desactivas el wifi, (teóricamente) no emite ondas... solo podrías funcionar a través del cable ethernet (aunque puedas elegir entre 2 conectores, el USB suele ser más cómodo).

...y es raro que el tipo que vino a instalarte el aparato no supiera desactivarlo... se supone que además de instalarlo te lo configura para que tengas red... si sabe configurarlo (que tiene alguna complejidad relevante), sabrá desactivar el wifi (que es una complejidad simple comparado con configurarlo).

intente acceder a 192.168.1.254 desde mi navegador para desactivar el wifi y no puedo acceder.

Prueba en tu navegador con la dirección: 192.168.1.1
Pero vamos, no necesitas andar tanteando, si tienes acceso a internet, mira la configuración de red del PC o el móvil con el que te conectes, pués ahí figura... como: "Default Gateway" (o "Puerta de Enlace" si viene en español).
También el manual del aparato señala tanto la direccion que trae de fábrica así como alias y contraseña. Aunque se pueden cambiar...

O quizá la 192.168.1.1 (A veces)

Yo diría que casi siempre... en los últimos 20 años, siempre me he encontrado ese valor como el valor por defecto de fábrica. En los 90, la más común que me encontraba era 192.168.0.1

[no tenemos ni idea de si la inteligencia es algo muy común en el Universo]

En un comunicado, el investigador del IAC y director del Museo de la Ciencia y el Cosmos de Tenerife, Héctor Socas, recuerda que "no tenemos ni idea de si la inteligencia es algo muy común en el Universo o si, por el contrario, es extremadamente infrecuente".

Mi apuesta es que sí... que el Universo fue concebido para la vida y la vida para la inteligencia.

La distancia galáctica entre especies de seres inteligentes, quizás sea una especie de salvaconducto, para dar tiempo a que una civilización inteligente, tenga tiempo de evolucionar hacia una especie respetuosa y no destructiva y macrófaga de otras especies menos evolucionadas...

Nosotros (como especie) estamos muy próximos a ese punto, en el que la inteligencia y 'especie respetuosa' están por moverse y evolucionar o mantenerse y autoaniquilarse... Quiera el Universo que si la especie humana no evoluciona, tampoco tenga oportunidad de salir del planeta para J0D35 la vida a otras especies fuera del planeta...

Te deseo suerte para que salgas seleccionado... y más suerte para que salga todo bien.

Por mi parte, como suena el dicho, prefiero: "estar con los pies en tierra (firme)".

Las situaciones explicadas son los casos hipotéticos más comunes que uno se va a encontrar. El caso concreto exacto que a tí se te presente, pués será eso, el caso concreto que tienes entre manos.
Comprenderás que sin más datos que una pintoresca explicación no pueda hacerse otra cosa que dilucidar las posibles causas más frecuentes. Que por supuesto no tiene por qué coincidir con tu caso o el de otra persona.

Diferentes versiones de dlls, tipo API, funcionarán correctamente siempre que la firma de las funciones (que se invoquen) coincidan (con compatibles). Todavía un programa puede molestarse en asegurarse por tener una versión específica, o solo limitarlo a que sea mayor o menor de x versión... son casos menos frecuentes, que suelen remitirse a dlls que son nativas del propio programa (posteriores versiones tienen cambios incompatibles mientras mantienen el mismo nombre para la dll) o bien porque parten de una versión nueva de un programa antiguo que funciona con una configuración antigua (que solo funcione con versiones específicas de dichas dlls).

Incluso habrá revisiones que un porgrama puede hacer sin llegar a verificar un hash completamente (que será más o menos costos en tiempo), y solo se moleste en verificar (por ejemplo) la fecha, versión, tamaño, o ciertos bytes dentro de la librería ...y además puede mantener esa verificación para varias versiones de dlls que acepte (no solo para 1 fichero).

En fin es cuestión de lo que el programador haya ingeniado... descubrir el modo exacto con que proceda un programa solo puede descubrise metiéndose con el programa y las dll en cuestión, no por un par de párrafos escritos. Pero las ideas vertidas, te dan para no quedarte estancado si no se te ocurren opciones (que supongo es la razón por la que abriste el hilo), revisar e ir descartando opciones hasta dar con el problema exacto...

[para empezar]

Justo en el foro donde has abierto este mensaje, unos mensajes más arriba verás que pone 'sección fija' o así, es un hilo tratando el tema con lo que buscas.
Como te dicen más arriba, la pregunta no es procedente por obviedad aplastante...

Ante la remota posibilidad de que no sea la pereza lo que seguramente te mueva a hacer la pregunta te pego el enlace:
https://foro.elhacker.net/foro_libre/guia_quiero_ser_hacker_por_donde_empezar-t430974.0.html

Después de leerte como mínimo los primeros mensajes, puedes bucear (con paciencia) en el foro... para empezar cualquier pc que tengas es suficiente, no te molestes en adquirir nada de hardware por el momento (si ya tienes algo), prima adquirir el conocimiento primero... luego ya con ese nivel mínimo de conocimientos, tendrás la orientación (más o menos) adecuada, y entonces tú mismo podrás respoderte sobre cuales puedan ser tus necesidades en materia de hardware, en función de hacia donde decidas orientarte.

La explicación que da Musk, no creo que sea cierta, suena como un poco más  a casual (una excusa barata preferible a...), cuando la realidad, me parece que se acerca más a la torpeza...

Mi primera impresión al ver el vídeo, es que fue un sobrecalentamiento de los motores a causa de los gases expandidos en la propulsión, que al momento de posarse, la zona ocupada por la propia nave, estaba sobrecalentada...

...vamos es casi la misma situación del mítico juego 'Lunar Lander', solo que en el juego, (cuando fallabas en el aterrizaje) la destrucción era debido a un choque por la velocidad de impacto al tratar de aterrizar... salvando la distancia entre la 'velocidad de impacto' y la 'velocidad de disipación del calor bajo el propio cohete', para mi es un fiel reflejo.

En las últimas decenas de metros antes de tocar suelo, se debería apartar las toberas de escape graduando el ángulo hacia afuera a medida que va descendiendo.

En efecto... las dll tipo API, es como bien señala Tincopasan y tú mismo...

Me faltó señalar que '...la otra situación que puede darse con las dll...' que omití precisamente porque ya había respuesta dada, aunque al escribir el mensaje me pareció que era como mucho deducible, ahora al releerme no me parece tan obvio, así que gracias por añadir la diferenciación para impedir que induzca a cierta ambigüedad.

hola
Tengo un crack de un programa con un dll. Tiene dentro unas imágenes de recursos que se acoplan al programa crackeado que no me gustan, así que decidí editar los recursos y eliminar o reemplazar las imágenes por las verdaderas del programa original. Lo edité con ResourceHacker, PE Explorer, Visual Studio C++.

Cuando lo edito el crack no funciona y me da error. Hice una prueba extraje la imagen de recurso y luego la volví a poner tal cual estaba. Idioma, ID todo igual, pero igualmente el crack me daba error. De alguna manera detecta que ha sido editado y lo rechaza, ya que el DLL es usado por un EXE.

Cuando editas una dll que usa un programa y que está registrada (en el registor del sistema), cuando el ejecutable tratade cargar dicho ejecutable se localiza mediante su CLSID, como quiera que dicho valor habrá cambiado con tu modificación 'entenderá' que se trata de una version distinta.

Prueba primero a localizar en el registro la dll y haz copia de la rama/s que la contengan (junto con la dll original), luego registra la dll modificada, se creará un CLSID distinto del previo...
Si el programa instancia la dll por su servidor.nombre (late binding), seguirá teniendo acceso a ella, pero si el programa mantiene referencia a su CLSID (early binding), no funcionará, en cuyo caso tendrías que cambiar (también) en el programa... el CLSID, que referencia la dll (en todas las partes que apareciere), por el nuevo que arroja tras el registro después de editarla.

Otra cosa es que tras las modificaciones, tengas que usarlas en tus programas, simplemente registras la dll, y tu programa la instancia, no importa el CLSID que tenga ahora, porque es el que tu programa tomará... en este caso conviene además cambiar nombres, para evitar que una versión modificada (para uso personal y propio), no malogre el acceso y uso a la misma dll (la original sin modificar), que pueda necesitar uno o más programas del sistema.

... pero al parecer me han dicho que debería haber hecho todo con arrays y que eso está mal, pero que yo sepa lo he hecho con un array, ¿no? ¿Hay alguna otra forma con arrays de hacer esto?

Lo que quieren es que pienses, que sepas cómo sucede, no simplemente que hagas que suceda...

Dicho de otro modo: Quieren que uses bucles y que cambies elementos de un array a otro o dentro del mismo array usando variables temporales e índices entre elementos.
No quieren que utilices métodos de objetos que te faclitan el trabajo... eso para cuando seas profesional ahora toca aprender como hacerlo 'manualmente'.

Tienes que sopesar cual tiene menor coste, lo que depende de:
--- El tamaño del fichero.
--- En qué punto del mismo se localice dicha línea.
En resumen el tamaño del ficheor antes y después de dicha línea.
Además, si no es la única línea a borrar, conviene retrasar la operación, almacenar los datos referentes a su localización y tamaño en alguna estructura de datos y cuando se tenga la info de todas las que se deseen 'borrar' proceder co el borrado de todas en una misma y única operación... porque borrar una sola línea de cada vez tiene un elevado coste.

Hay dos formas de hacer lo que quieres:
1 - Si la línea ocupa pongamos 40 bytes, bajas todos los que estén por encima de la línea exactamente 40 bytes, para cubrir el hueco que ocupaba dicha línea... y sobrescribes los 40 bytes finales del fichero a 'cero' (por ejemplo). El tamaño del fichero sigue siendo el mismo, luego operaciones de tipo 'append' escribirían al final de dicho fichero, sin considerar ese espacio de 40 bytes del final...

2 - El otro modo soluciona el problema antedicho, pero el coste es algo mayor, tanto mayor cuanto más grande sea el fichero y más al final este dicha 'linea 'borrada'..
Creas un fichero nuevo, copias todo el contenido hasta el comienzo de la línea a borrar, y luego todo el contenido tras la linea a borrar, en resumen copias todo excluyendo dicha línea.
...luego al terminar cierras y borras el fichero que contiene la línea que querías borrar., y al nuevo lo renombras con  el nombre que tenía el ahora borrado.
Por supuesto si has leído un fichero enteramente en un array de líneas, la operatoria se puede simplificar, cerrando y eliminando el fichero actual y creando uno nuevo del mismo nombre que el eliminado, ahora escribe todo el contenido que mantienes  en tu array, omitiendo justamente las líneas que se quieran 'borrar'.

Los ficheros ocupan un espacio contínuo en el disco, luego el coste asociado con borrados en medio de un fichero tienen un elevado coste.
Si el fichero mantiene algún tipo de estructura, registros, lo que se suele hacer es simplemente marcar un registro como 'vacío', el contenido del mismo no precisa ser tocado, salvo que contenga algo que por seguridad no pueda dejarse así, en cuyo caso se sobrescribe con contenido aleatorio...

Cuando deba añadirse nuevos registro, siempre lo harán en registros borrados con preferencia a añadirlos al final del fichero.

Si se acumulan demasiados registros sin borrar (cuand esté muy fragmentado), según el diseño... puede interesar 'defragmentar', haciendo exactamente lo que se señala en el apartado '2', copiando el contenido total del fichero a otro, excluyendo los registros vacios...