Quote:
I'm clearly missing something with your idea of bootstrap code embedded in the main script. The service code is 3400+ lines with 23 UDFs - any piece could be updated.


Maybe I'm not explaining myself very well. Here is a short example:
 Code:
BREAK ON

; Variable definition
$sKey_BootStrap="HKLM\foo\bar"
$sVal_BootStrap="BootStrapCode"
$sBootStrapCode='Shell @@SCRIPTEXE+" "+@@SCRIPTDIR+"/"+@@SCRIPTNAME $$PPID=Dispatcher"'

; Write bootstrap code
; Every instance of this script will re-write the bootstrap code.
; This means that when a new version of the script is release the
; bootstrap process will automatically be updated with new code.

$=WriteValue($sKey_BootStrap,$sVal_BootStrap,$sBootStrapCode))

; BOOTSTRAP SECTION START-------------------------------------------
; If this is the boostrap instance of the script
; just keep running the bootstrap code.

If IsDeclared($PPID)=0
	While TRUE
		$=Execute(ReadValue($sKey_BootStrap,$sVal_BootStrap))
	Loop
	Exit 0 /* NotReached */
EndIf
; BOOTSTRAP SECTION END---------------------------------------------

;
; Main script.
; If any of the script below is changed the bootstrap process will be unaffected.

If $PPID="Dispatcher"
	; This is a primary dispatcher process which will create the workers
Else
	; This is a worker process
EndIf

Exit 0


The process works like this:
  • The primary (boostrap instance) of the script is started.
  • It writes the bootstrap payload code to the registry.
  • As the variable $PPID is not set it starts an infinite loop which reads the payload code from the registry and then executes it.
  • The payload code just starts another instance of the script setting variable $PPID to "Dispatcher"
  • The "Dispatcher" instance of the script starts creating the real worker processes.


So to update running code all that you need to do is:
  1. Overwrite the script with the new version.
  2. Wait for the worker processes to complete.
  3. Optionally kick off a dummy no-op worker.
  4. Exit the dispatcher script


When the dispatcher script exits it is immediately restarted by the bootstrap prcess, only now of course it will pick up the new version of the file so your new code is activated.

The reason for triggering a dummy worker before exiting the dispatcher is that the dummy worker will update the bootstrap payload code in the registry with whatever is in your new file. This means that even your initial boostrap process will get the updated code, the *only* thing you cannot change is the basic While Loop construct.

Because the bootstrap code is so simple and self-updating it isn't affected by you changing anything else in the file. The bootstrap process will continue to run with the stale version loaded in memory, but that doesn't matter because it doesn't use any of the changeable code. Any new instance of KiXtart which is launched will pick up the new file and UDF's contained.