Como escribir información dentro del exe?

[Chefito]

Bueno, ya lo he arreglado. Una pequeña condición en el código vbs de que si no hay ningún dato no añada nada, deje el archivo exe original y solucionado .
Aquí dejo el código vbs indentado. Lo he añadido en un archivo de texto en el rar del post anterior.

Código: Seleccionar todo

'función que te indica si existe un proceso en ejecución. Utilizo el objeto WScript.Shell. Tambien utilizo información de Windows.
'Si el proceso existe da true, y si no da false. Encontrada en: http://www.davidsuarez.es/2008/09/saber-si-un-proceso-se-esta-ejecutando-visual-basic-script-vbs/
Function ExisteProceso(NombreProceso)
  Set WshShell = WScript.CreateObject ("WScript.Shell")
  Set colProcessList = GetObject("Winmgmts:").ExecQuery ("Select * from Win32_Process")
  For Each objProcess in colProcessList
    If objProcess.name = NombreProceso then
      ExisteProceso = True
    Else
      ExisteProceso = False
    End if
  Next
  Set WshShell = Nothing
  Set colProcessList = Nothing
End Function

'Esta función transforma los datos string a binario para luego poder insertarlos directamente en el exe.
'Utilizo el objeto ADODB.Stream con todas sus posibilidades para trabajar con ficheros binarios y de texto.
'Stream_StringToBinary Function
'2003 Antonin Foller, http://www.motobit.com
'Modificada por chefito
Function Stream_StringToBinary(Text)
  Dim BinaryStreamLocal, DatosResult
  Set BinaryStreamLocal = CreateObject("ADODB.Stream")
  BinaryStreamLocal.Type = adTypeText
  BinaryStreamLocal.CharSet = "iso-8859-1"
  BinaryStreamLocal.Open
  BinaryStreamLocal.WriteText Text
  BinaryStreamLocal.Position = 0
  BinaryStreamLocal.Type = adTypeBinary
  BinaryStreamLocal.Position = 0
  DatosResult=BinaryStreamLocal.Read
  BinaryStreamLocal.close
  Stream_StringToBinary = DatosResult
End Function
	
Const adTypeText = 2
Const adTypeBinary = 1
Const fichero = "' & @ScriptFullPath & '"
Dim BinaryStreamFile, BinaryStreamDato, BinaryStreamAux, TrozoFile, TrozoDato, ContBucle, ContinuarScript, Datos
	
ContBucle=0
ContinuarScript=True
Datos="' & $txt & '"'
	
'bucle. Si existe el proceso de nuestro exe no sale del bucle. Tiene un contador para parar el bucle si al cierto tiempo sigue detectando el proceso.
'$Scriptvbs &= 'Set WshShell = WScript.CreateObject("WScript.Shell")' & @CR

Do While ExisteProceso("' & @ScriptName & '")
  WScript.Sleep 50
  '$Scriptvbs &= 'WshShell.Sleep=50
  ContBucle=ContBucle+1
  If ContBucle=60 Then		'cada 20 es un segundo de espera antes de dar el error y salir del script
    ContinuarScript=False
    MsgBox "No se han podido guardar los datos",16,"Error al grabar los datos"
    Exit Do
    '$Scriptvbs &= 'WScript.Quit
  End If
Loop
	
'si se ha cerrado el proceso bien y ha salido del bucle, entra en esta condición que contiene todo el código de inserción de los datos al exe.
If ContinuarScript Then
  Set BinaryStreamAux = CreateObject("ADODB.Stream")
  BinaryStreamAux.Type = adTypeBinary
  BinaryStreamAux.Open
  Set BinaryStreamFile = CreateObject("ADODB.Stream")
  BinaryStreamFile.Type = adTypeBinary
  BinaryStreamFile.Open
  BinaryStreamFile.LoadFromFile Fichero
  TrozoFile=BinaryStreamFile.Read(' & $SizeExe & ')
  binarystreamFile.position=0
  binarystreamAux.write TrozoFile
  	
  If Datos<>"" Then
    TrozoDato=Stream_StringToBinary(Datos)
    Set BinaryStreamDato = CreateObject("ADODB.Stream")
    BinaryStreamDato.Type = adTypeBinary
    BinaryStreamDato.Open
    binarystreamDato.write TrozoDato
    binarystreamDato.position=0
    binarystreamDato.copyto binarystreamAux
    BinaryStreamDato.close
  End If
  	
  binarystreamAux.savetofile fichero,2
End If
	
BinaryStreamFile.close
BinaryStreamAux.close

'código para borrar el propio fichero vbs. Utilizo el objeto Scripting.FileSystemObject.
Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
fso.DeleteFile "' & @TempDir & "\Aplicacion.vbs" & '",True
Set fso=Nothing		

Piensa que en el código hay algunas variables que paso desde AutoIt y estas partes no funcionarían en un archivo .vbs . Podría obtener esta información perfectamente en vbs, pero prefiero pasarselas por AutoIt.

Saludos.

[Ximorro]

Bueno, lo del tamaño del EXE es que yo suelo hacer bastantes pruebas, voy haciendo mejoras, ampliaciones... si cada vez que compilo tengo que hacer lo del tamaño es un poco rollo.
Compilando una vez y ya está, dices, ¿y en desarrollo? no te ha tocado recalcular el numerito en varias pruebas.
Además si se programa lo del tamaño se hace una vez, no hay que volver a cambiarlo ni modificando ese programa ni cuando te llevas esas funciones a otro.
En fin, cuestión de gustos...

Hombre, lo del int con el tamaño de los datos (65kb si lo interpretas sin signo), si te parece poco se pone un long de 4 bytes (que son 4GB). De todas maneras yo estas técnicas sólo las usaría para datos pequeños, si te ves escribiendo megas en un EXE creo que mejor te pasas a archivos externos de configuración...

Yo haría lo del tamaño de los datos al final del archivo, pero al menos también se podría hacer un programa, en AutoIT por supuesto, que compile, mire el tamaño del exe, modifique el au3 original él solito, y recompile

Hombre, no he dicho que tenga la misma funcionalidad, sino casi, y estaba pensando en mi versión con BAT que comprueba que se libera el EXE, no el original, se puede hacer que no consuma CPU comprobando cada segundo (lástima no tener un Sleep en BAT), con VBS es genial que puedes parar milisegundos pero en BAT no sé si se podrá, de todas maneras por lo que he visto entre cerrar el programa y hacer el MOVE no suele tardar ni un segundo...
También se puede poner en un FOR en vez de un bucle infinito para que intente un número fijo de veces y si acaba el FOR... ¿se puede sacar un mensaje MsgBox desde un BAT? Aún tendré que hacer un vbs, aunque sea infinitamente más sencillo que el tuyo
Creo que la diferencia fundamental es que escribes directamente en el EXE original, eso es lógicamente más eficiente que copiar el EXE original para crear una copia modificada.

Veo que has modificado el código, has quitado la repetición en la creación de BinaryStreamDato
Has cambiando la estructura, ahora lo entiendo un poco mejor, por cierto, ¿los close de BinaryStreamFile y BinaryStreamAux no tendrían que estar dentro del IF donde se abren?

Creo que ahora entiendo un poco mejor el lío (para mí) del Aux, el Dato y el File... oye, ¿¿no estás reescribiendo TODO el archivo?? Primero lees en BinaryStreamFile todo el archivo, luego lees a TrozoFile todo el EXE sin datos, lo escribes en Aux, le añades los datos... y escribes TODO el resultado con savetofile.
¿Estás seguro de la eficiencia de todo esto? ¿No se podría hacer un equivalente a Open-FileSetPos-Write(SoloLosDatos)? Vaya, realmente yendo al grano a escribir en el sitio sin tocar lo demás, creo que sí lees y escribes todo...

Una sugerencia, al final cuando borras en vez de usar a piñón fijo @TempDir & "Aplicacion.vbs" sería interesante usar $pathFileVBS (que incluso yo calcularía a partir del nombre del EXE), así es más cómodo de cambiar el nombre, al hacerlo sólo en un sitio (o ninguno, si usas el nombre del exe)

Jo, la verdad es que me he mareado un poco con los streams, igual he dicho un montón de tonterías, mejor me lo explicas...

[Ximorro]

Ah, ¡y gracias por indentar el código!
Por cierto, una tontería... ¿WScript.Sleep y WshShell.Sleep hacen lo mismo?

[Chefito]

Compilando una vez y ya está, dices, ¿y en desarrollo? no te ha tocado recalcular el numerito en varias pruebas.

No te voy a mentir . Al final lo he tenido que compilar varias veces. Pero tampoco tantas . Trabajaba aparte con el código vbs, y hasta que no me funcionó bien no lo añadí.

Además si se programa lo del tamaño se hace una vez, no hay que volver a cambiarlo ni modificando ese programa ni cuando te llevas esas funciones a otro.
En fin, cuestión de gustos...

Jajajaja......pues eso, cuestión de gustos . Cada técnica tiene su lado bueno y su lado malo comparándolas .

Hombre, lo del int con el tamaño de los datos (65kb si lo interpretas sin signo), si te parece poco se pone un long de 4 bytes (que son 4GB). De todas maneras yo estas técnicas sólo las usaría para datos pequeños, si te ves escribiendo megas en un EXE creo que mejor te pasas a archivos externos de configuración...

Jejejeje....tu lo decías en modo binario, y yo creía que estabas hablando de introducir 2 dígitos en modo ascii (1 por byte). Por eso pensé que el tope de caracteres solo podría ser 99 . Una pequeña confusión .

Yo haría lo del tamaño de los datos al final del archivo, pero al menos también se podría hacer un programa, en AutoIT por supuesto, que compile, mire el tamaño del exe, modifique el au3 original él solito, y recompile

Jejejeje....eso sería otra idea. Un poco rollo pero interesante.

se puede hacer que no consuma CPU comprobando cada segundo (lástima no tener un Sleep en BAT), con VBS es genial que puedes parar milisegundos pero en BAT no sé si se podrá, de todas maneras por lo que he visto entre cerrar el programa y hacer el MOVE no suele tardar ni un segundo...

Mmmmmmm.....la verdad es que no tengo ni idea si se podrá hacer una parada al estilo sleep en batch de alguna forma.
Lo que si se puede es reducir el tiempo de comprobación. Con el ejemplo del cronómetro que te dí en un post anterior (http://foro.elhacker.net/scripting/cron ... msg1040920) puedes ver que se podrían hacer comprobaciones cada décima o centésima de segundo. Cambia el valor de las variables (set mirror1=%time:~-2,1% , set mirror2=%time:~-2,1%) para ver las décimas de segundo, o %time:~-1,1% para las centésimas .
Para hacer esto supongo que con las décimas te sobre. Al ser un bucle se carga un poco el procesador, pero como va a ser muy poco tiempo, a mi parecer, no pasa nada .
Lo del mensaje....puffffff. Te podría servir el comando MSG. Un ejemplo: Abre una consola y pon: msg * este es mi mensaje....chefito es genial ;). Este mensaje se enviaría a todas las sesiones del servidor especificado. Mira la ayuda que hay parámetros muy interesantes. Desde que se cierre el mensaje a los tantos segundos hasta especificar a quien enviarselo según nombre de usuario, nombre de sesión, etc. Estos datos los tendrías que sacar con AutoIt o en batch. Supongo que los prefieras sacar en AutoIt y luego añadirlos al código batch .

Veo que has modificado el código, has quitado la repetición en la creación de BinaryStreamDato
Has cambiando la estructura, ahora lo entiendo un poco mejor, por cierto, ¿los close de BinaryStreamFile y BinaryStreamAux no tendrían que estar dentro del IF donde se abren?

Sí, lo he modificado algo .
Respecto a lo del If.......mmmmm....mmmmm.....fallo técnico . Gracias por avisar. Ya está corregido. Demasiados cambios en el código. Algo se me tenía que pasar jajajajaja.

Creo que ahora entiendo un poco mejor el lío (para mí) del Aux, el Dato y el File... oye, ¿¿no estás reescribiendo TODO el archivo?? Primero lees en BinaryStreamFile todo el archivo, luego lees a TrozoFile todo el EXE sin datos, lo escribes en Aux, le añades los datos... y escribes TODO el resultado con savetofile.
¿Estás seguro de la eficiencia de todo esto? ¿No se podría hacer un equivalente a Open-FileSetPos-Write(SoloLosDatos)? Vaya, realmente yendo al grano a escribir en el sitio sin tocar lo demás, creo que sí lees y escribes todo...

Se tiene que hacer así. Ya probé a intentar modificarlo sobre él mismo y no pude. Sobreescribe el fichero, pero si no llega al final, deja el final. Me entiendes no? Una pena. Por esta causa tube que utilizar un stream auxiliar. A lo mejor hay alguna manera y no se como. Por desgracia yo no lo se todo .
Este objeto no lo había utilizado nunca así. Se suele utilizar para acceso a base de datos. Recuerda que ADO significa Objeto de Acceso a Datos.....sean base de datos (lo típico) o ficheros o cualquier otro acceso a otros datos.
Ya sabemos la evolución no?. Yo empecé accediendo a bbdd con DAO, luego RDO, ADO, y ahora ADO .net.

Una sugerencia, al final cuando borras en vez de usar a piñón fijo @TempDir & "Aplicacion.vbs" sería interesante usar $pathFileVBS (que incluso yo calcularía a partir del nombre del EXE), así es más cómodo de cambiar el nombre, al hacerlo sólo en un sitio (o ninguno, si usas el nombre del exe)

Vale vale, si te gusta más así lo cambio . Lo del nombre paso de hacerlo. Si lo quiere hacer alguien que lo haga . Lo del nombre no tiene tanta importancia. No necesariamente tiene que ser igual que el del programa. Lo puse así porque queda más bonito .

Por cierto, una tontería... ¿WScript.Sleep y WshShell.Sleep hacen lo mismo?

Sí, hacen lo mismo. Con el primero accedo directamente, con el segundo hay que crear el objeto y acceder a él. Luego lo tendrías que destruir.
Es más que otra cosa ahorro de escribir código.
Si no lo hubiese tenido que poner claro para que la gente lo entendiera, seguramente hubiese reducido al máximo el tamaño de los nombres de las variables, y el valor de las constantes directamente......entre otras cosas que pudiese reducir . Más que nada para hacer el archivo vbs lo más pequeño posible.

Saludos.

[Ximorro]

Interesante lo del cronómetro, pero también me fuerza a hacer un BAT, no vale con un CMD /C, para eso lo hago en vbs, que tiene eso y mucho más, ja, ja.

¡Ya lo creo que interesa lo del msg!, está chulo lo del time-out para que desaparezca solo. Hombre yo haría un msg %USERNAME% en vez de msg *, por si acaso

Lo de los streams... así no parece muy eficiente, yo estaba con la ilusión que se iba a la posición exacta a escribir los datos pero hay que reescribir todo el archivo... ¿No hay en vbscript funciones específicas para manejar archivos. Si estuviera lo equivalente en AutoIt a FileSetPos y Write ya estaría...

No tengo ni idea de vbscript pero buscaré a ver...

Qué extraño lo de WshShell.Sleep, estando el otro de acceso directo desde el lenguaje, quizás es por si se usa desde otros lenguajes que no tengan un Sleep... como te descuides WScript.Sleep usa internamente el Sleep del objeto Shell, ja, ja.

Joer, ciertamente no hay manera de ejecutar comandos vbs fuera de archivo, he probado redireccionamientos por todos lados, pero nada, no se puede crear el archivo "al vuelo", tipo cmd /c, eso sería genial...

[Chefito]

Bueno bueno, he descubierto que cerrando el objeto stream y volviendolo a abrir se borra la información:

Código: Seleccionar todo

binarystream.close
binarystream.open

Gracias a esto no tendría que crear el objeto auxiliar para trabajar. Podríamos meter la información de la variable trozo en el mismo stream .
Y si aun nos queremos ahorrar otro stream, pues sacamos el código de la función Stream_StringToBinary, y en vez de que nos devuelva una variable con la información en binario, que luego hay que meter en un nuevo objeto stream, al sacarlo, podemos utilizar directamente este objeto stream.
Con todo esto se reduciría a trabajar con dos objetos stream en vez de cuatro.
No voy a reescribir el código y demás porque estoy harto de editar el post (o posts) y resubir el archivo rar .
Quien quiera cambiarlo ahí queda eso. También lo he dicho como información, por si alguien trabaja con esto........que lo sepa .

¡Ya lo creo que interesa lo del msg!, está chulo lo del time-out para que desaparezca solo. Hombre yo haría un msg %USERNAME% en vez de msg *, por si acaso

Pues sí, mejor así .

Joer, ciertamente no hay manera de ejecutar comandos vbs fuera de archivo, he probado redireccionamientos por todos lados, pero nada, no se puede crear el archivo "al vuelo", tipo cmd /c, eso sería genial...

Yo creo que no se puede. Si se pudiese se podría meter todo el código en una línea, ya que el separador de líneas en vbs son los dos puntos .

Saludos.

[ParSalian]

Hola, sé que el post es antiguo y todo eso, pero lo he encontrado buscando otras cosas (hoy que no va el sitio de autoitscript no sé por qué he pasado por autoit.es), y quería hacer un par de comentarios, por si sirvieran (o sirviesen) de algo:

Respecto a lo de la pausa antes de ejecutar algo... desde el au3 compilado se puede hacer el run asíncrono ese antes de salir, llamando al propio ejecutable pero con la línea de comandos específica de Autoit:
ProgramaCompilado.exe /AutoIt3ExecuteLine "sleep(5000)"
(siempre, claro, que no se haya incluido en el código la directriz #NoAutoIt3Execute)
Es la opción que he usado un par de veces que me ha hecho falta... soy vago ^^

Respecto a lo de escribir información en un exe, hay una solución que he empleado en el trabajo, pero única y exclusivamente porque el sistema de ficheros de los servidores con que trabajo es NTFS, y NO muevo los ficheros por entornos no-NTFS. Vamos, me limito a usar los ADS (alternate data stream) del NTFS. Con eso, el problema se reduce a esto:

Código: Seleccionar todo

$Ini = @ScriptName & ":Flujo.txt"

If FileExists($Ini) Then
  $Texto = FileRead($Ini)
  MsgBox(0,0,$Texto)
Else
  FileWrite($Ini,@YEAR & @MON & @MDAY & @HOUR & @MIN & " --> PRUEBA")
  MsgBox(0,0,"No hay datos")
  EndIf

Obviamente tiene MUCHAS limitaciones (olvídate de pasar los datos a un usb en fat32, o a un linux, aunque sea para luego ponerlo en otro servidor, son difíciles de ver "a pelo", la probable desaparición en sistemas futuros - http://support.microsoft.com/kb/105763/en-us) pero para determinadas situaciones vienen bien. Desde luego, NO para distribuirlo online (explícale a un usuario que si no tiene NTFS la configuración tendrá que guardarse de otra manera o no guardarse)

Por lo demás, aprovecho este mi primer post para decir que me sorprende la capacidad de trabajo que tiene la peña... soy vago a más no poder, y de hecho parte de culpa de usar autoit es de mi vagancia... con 4 líneas hago lo que otros compañeros expertos en visual se tiran 2 páginas de código para escribir

[Chefito]

Antetodo bienvenido. Me alegra que te pasaras por nuestro/vuestro foro de AutoIt en español aunque solo fuese casi de casualidad .
Como habrás podido comprobar aquí habemos gente que nos defendemos bastante bien en AutoIt. Entre todos intentamos aprender más y mejor.
Estoy deacuerdo contigo de que autoit es para facilitar y simplificar muchas cosas, pero, por lo menos a mí, me gusta esprimir los lenguajes a más no poder .
En este post se discutió un tema bastante complicado, y era el de añadir datos para luego poder recuperarlos en el propio exe compilado. Se mostraron dos técnicas bastante válidas. Una se basaba en algo de batch y otra en vbscript utilizando el objeto stream. Espero que te hayan gustado .

Respecto a lo de la pausa antes de ejecutar algo... desde el au3 compilado se puede hacer el run asíncrono ese antes de salir, llamando al propio ejecutable pero con la línea de comandos específica de Autoit:
ProgramaCompilado.exe /AutoIt3ExecuteLine "sleep(5000)"

Y yo te pregunto....y esto para que sirve en este caso? Lo que nos interesaba es intentar averiguar cuando se cerraba el programa principal para poder introducirle los datos. Lo intentábamos desde códigos que no necesitasen guardarse en un archivo (ejecución de una línea de batch) o si se guardaba en un archivo que se pudiese borrar a sí mismo sin muchas complicaciones (ejemplo....vbs o batch). Pero según creo, la forma que tu dices sería para ejecutar otro archivo AutoIt compilado con 5 segundos de retraso. Es otra posibilidad que ya se discutió. Pero siempre se tendría que apoyar el programa principal en otro secundario, el cual no se podría borrar nunca.
O querías decir otra cosa y me estoy equivocando?

Respecto a lo de escribir información en un exe, hay una solución que he empleado en el trabajo, pero única y exclusivamente porque el sistema de ficheros de los servidores con que trabajo es NTFS, y NO muevo los ficheros por entornos no-NTFS. Vamos, me limito a usar los ADS (alternate data stream) del NTFS

Pufffff esto me supera. No entiendo esta técnica que dices. No comprendo como puedes escribir en un archivo binario (.exe) datos de la forma que tu lo haces con el código de debajo . En ese código más bien veo que modificas un archivo de texto y nada más .
Yo utilicé el objeto ADODB.Stream para manejar archivos binarios. No conozco el ADS.
Además, para algo particular que sepas que no se va a mover de los sistemas de archivos NTFS pues no pasa nada, pero si quieres que funcione en todos los sitios, incluidos discos duros y pen externos (sabemos que casi todos tienen el sistema fat32), como tu bien dices, esta técnica no funcionaría .

con 4 líneas hago lo que otros compañeros expertos en visual se tiran 2 páginas de código para escribir

Estoy deacuerdo contigo .

Saludos.

[ParSalian]

Gracias por la bienvenida, Chefito :)

"Lo que nos interesaba es intentar averiguar cuando se cerraba el programa principal para poder introducirle los datos. Lo intentábamos desde códigos que no necesitasen guardarse en un archivo (ejecución de una línea de batch) "

A lo que me refería (pero no he probado, y ahora veo el error en mi lógica) era a que en vez de ejecutar un BAT con un ping al localhost a modo de demora antes de hacer el borrado, se podría simplemente llamar al mismo exe que genera el bat autoborrable con una pausa. Me explico, desde el AU3 que ha de automodificarse (llámese X.EXE) hablábais de hacer un BAT que esperara un poquito, hiciera nosequé, y luego se autoborrara, llámese X.BAT. Ese "que esperara un poquito" (lástima no tener un sleep en bat como decía Ximorro) es lo que yo sugería hacer con una autollamada, algo como en el X.Exe:
FileWrite("X.Bat","@Echo off")
FileWrite("X.Bat",'X.Exe /AutoIt3ExecuteLine "sleep(5000)"')
FileWrite("X.Bat","del X.Exe")
FileWrite("X.Bat","del X.Bat")
Run("X.Bat")
Y bueno, jugando a cambiar la demora del Sleep(5000) por el tiempo que estimáramos o por un ProcessWaitClose... pero claro, esto ya tendría la pega de que existiría dos veces el proceso X.Exe ^^ [ídem para sacar un msgbox desde un bat, teniendo el au3 compilado: X.exe /AutoIt3ExecuteLine "MsgBox(64,'Info','Peaso MsgBox')"]

Respecto al otro punto, lo de los ADS, en realidad NO escribo datos en un fichero binario. Sólo uso una funcionalidad del NTFS que permite "vincular" un fichero B a otro fichero A, de manera que vayan siempre unidos (y además, en apariencia, el fichero B no exista al hacer un dir, por ejemplo... has de saber que está ahí y cómo se llama para poder usarlo). Puedes probar el código que puse, de hecho no hace falta ni compilarlo. No es incrustar el INI en el EXE, pero se parece ^^ Ya dije que para determinadas situaciones y entornos viene bien, pero no en general, era más un apunte curioso al estilo de los datos sin sentido de uno de los becarios de Bones

(supongo que no leí en profundidad, tengo la manía de hacer estas cosas "personales" cuando mi chica ya duerme... y entonces ando yo despistado)

[Ximorro]

¿Has probado tu método? El problema principal es que no puedes modificar ni borrar un exe que está en ejecución. ¿Estás seguro que entre la llamada a
X.Exe /AutoIt3ExecuteLine "sleep(5000)"
y
del X.Exe
el ejecutable ha sido liberado para escritura (en este caso borrado, que no es lo que queremos, si ves el post lo que queremos es añadirle datos)
Sí, se espera los 5 segundos, o el tiempo que pongas, pero durante ese tiempo X.exe está en ejecución, con lo que estamos en la misma. Lo de esperar un tiempo antes de borrar o modificar era precisamente para que ese archivo no estuviera en ejecución, si lo usas para ejecutar la pausa el método no nos sirve...


Lo de los datos en stream sí es una alternativa nueva a nuestros métodos ¡muy bien pensado!. No me gusta mucho la idea porque no mola tener datos "invisibles", añades info extra a los archivos de manera invisible al explorador o los DIR. Además sólo funciona para NTFS, en discos duros no será problema, ¿pero qué pasa si le pasas el archivo a un amigo por un USB o CD? ¿se pasa el stream de un archivo si lo adjuntas a un mail para mandarlo por correo?
De todas maneras lo de manejar datastreamers es una idea nueva, ¡felicidades!
¿Estás metido en el tema? Yo de esto sólo sé que existe y poco más. Te propongo un programa que muestre los datastream de los archivos de un directorio, o algo así. Será de mucha utilidad para que sepamos qué información hay oculta en nuestros archivos
Y sí, también sirve para añadir datos a un exe, teniendo en cuenta las restricciones de que el archivo no debe salir del sistema NTFS.

[Jonny]

Hola:

Este tema ya es viejo... Pero lo recordaba, porque me interesó eso de que un ejecutable se borre a sí mismo.

Y hoy, he buscado este tema, precisamente para ver cómo se hacía.

A mí la idea del Pin al localhost, no me gusta demasiado; aunque, si fuera la única forma...

Pero se puede retrasar el comando del, en la consola, sin crear archivos en el disco duro, ni hacer pin's al Localhost.
¿Qué os parece esto?:

Código: Seleccionar todo

Run(@Comspec&" /c timeout /t 5 /nobreak & del /f /q "&@ScriptDir&"\"&@ScriptName, "", @SW_HIDE)
Exit

el "5", que hay después del /t son los segundos del delay. Por lo demás, supongo que entendéis bien el comando, que únicamente elimina el archivo que lo ejecuta (podría haber optimizado la ruta...), forzando su eliminación, y en modo silencioso, para que no pida confirmación.
El /nobreak, que pertenece al comando "timeout", es para que ejecute el siguiente comando ("del") sin esperar que se pulse una tecla.

Esto lo he descubierto, buscando cómo hacer un delay en batch. Lo que no sé, es si el comando "timeout" estará disponible en todas las versiones de Windows... Al menos, en Windows 7 sí lo está.

Lo que más me ha costado (casi toda una tarde) ha sido poder ejecutar más de un comando; porque sin separarlos con el "&", el comando "timeout" da un error.

Mi idea desde el principio, era separar los comandos con un salto de línea, pero efectivamente no funciona: Sólo se ejecuta el primer comando.
Luego, me he centrado en digamos, imprimir el salto de línea (mal hecho, porque es lo mismo que hacerlo desde AutoIt). Pero pensé que si lo ponía en el comando, podría funcionar; pero no, no hay manera.

Al final, en una página de Microsoft, he visto que con &, se pueden separar comandos, e incluso hay parece, varias formas de separarlos: Como lo he hecho yo, condicionándolos...

Y al final, el resultado (probado) es el código de arriba, que tras x segundos elimina el archivo que lo ejecuta.

Yo también prefiero comprobar si el proceso está activo, y si no lo está, eliminar el ejecutable. Pero con etiquetas y goto's... no me ha funcionado lo de separar los comandos con el &. Pero cuando no tenga sueño, quizás haga pruebas, a ver si se puede hacer algo; porque según he visto en ésa página de Microsoft, se puede condicionar un comando, al resultado de la ejecución de un comando anterior, y cosas así. Si eso es realmente así, quizás no haga falta usar el goto, para comprobar si se ha cerrado el proceso...

Bueno... Espero que le sirva a alguien, porque con el tiempo que hace ya de este post... Desde luego, a Chefito y Ximorro, no creo que les interese ya :)

Salu2!

[Dany]

@Jonny eso se le conoce como MeltFile. creo que he hecho algunas funciones no re cuerdo donde las deje.


saludos

[Jonny]

Ah, no había oído nunca eso de "meltfile".

Lo puse, porque como Ximorro quería una forma distinta del pin a Localhost, sin crear archivos en el disco duro... Por si le da por pasar por aquí, y ver el post :)

Es mejor comprobando cuando está cerrado el proceso del archivo que se quiere manipular, pero... Eso es más difícil, hacer en una línea, sin pasar por el disco duro :)

Salu2!