BugFix for ImageStripper

The coping and updating of the version resource is done before the
preStripScript is executed which is to early, because all changes in the pre
strip script to version resource do not get into the executable. I just
moved the code of copyAndUpdateStub after the preStripScript. Another
solution would be to move the preStripScript to the beginning of the method.

Now the stub is not present during the execution of the preStripScript, so
fiddling with the EXE in a preStripScript wouldn't work any more. I don't
know if anyone used this. To have this ability also, the copyAndUpdateStub
method would have to be split into two portions.

I found the bug because I use a preStripScript to copy the version
information from a class into the file and product versions and to update
other version information in the version resource.


!ImageStripper methodsFor!

stripAndSaveNotifying: notifier
 "Strips the image and saves an executable file according to the
configuration held by the
 receiver. Notification messages are sent to notifier in the form of
#status: messages.
 N.B. This method is in the 'must not strip' category to prevent the
receiver pulling the rug
 out from under its own feet!!"

 | stubFile developmentMethods path |

 ["Check stub file exists before we get too far"
 stubFile := self checkedStubFilePath.
 path := self executablePath.
 "CHA FIX: This must be after the runPreStripScript, otherwise updates to
the version resource from the pre strip script are not written to the stub.
stubFile := self copyAndUpdateStub: stubFile to: path."
 developmentClasses := self developmentClasses.
 developmentMethods := self developmentMethods.
 self
  closeAllDevelopmentTools;
  runPreStripScript.
 stubFile := self copyAndUpdateStub: stubFile to: path.
 self
  notifyClassesOfStrip;
  collectGarbage.

 "Before closing the change log, ensure all external structures have been
sized in case they are referenced from methods
  in the change log."
 self defineExternalStructuresNotifying: notifier.
 self closeChangeLog.

 "These methods must be stripped BEFORE redundant packages, as they may
cause pre-requisites we don't want
  in the deployed application"
 self stripNotRequiredMethodsNotifying: notifier.
 self stripRedundantPackagesNotifying: notifier.
 self logRemainingPackages.

 "... and make sure we've garnered all the info we require from development
structures
  to allow these to be removed immediately. This must be done before we
disable the
  package manager."
 self logPreservedClasses.
 self logPreservedMessages.
 self disableDevelopmentSystem.
 self installRuntimeSessionManager.
 self assert: [SessionManager current isRuntime].

 "#finishedWith: doesn't remove methods unless a run-time session manager is
installed so we
  can only start throwing stuff away now"
 self initialTidy.

 "Before we can remove any classes, we must ensure isChanged properties are
removed"
 self clearChangedProperties.
 self disableClassChangeFlagging.
 self prepareExternalStructuresNotifying: notifier.
 self stripDevelopmentSystemNotifying: notifier.
 self finishedWith: #stripDevelopmentSystemNotifying:.
 "BUG CHA: We already have a RuntimeSessionManager here which initializes
some variables
 lazy such as resourceLibrary. The removing of Development classes however
accesses the resoucrelibrary,
 so that the RuntimeSessionManager gets initialized at Deploy time instead
of runtime yielding to
 to a wrong resource library (e.g. in the case, where the resource library
path is initialized to the image name
 with the method an overwritten method #defaultResLibPath). As this is not
the only variable initialized
 lazy, it is not clear whether other variable might experience the same
problem.
 Solutions either of:
 a) Set the RuntTimeManager as late as possible (then finishedWith has to be
changed)
 b) Deinitialize the variables on image startup in method #onStartup:"

 "Empty the receiver's class' method dictionary"
 self class class methodDictionary: MethodDictionary new.
 self stripRedundantClassesMethodsAndResources: false notifying: notifier.
 self stripDuplicatesNotifying: notifier.
 self finishedWith: #stripDuplicatesNotifying:.
 self stripDevelopmentClassesAndMethods: developmentMethods notifying:
notifier.
 self finishedWith: #stripDevelopmentClassesAndMethods:notifying:.
 developmentMethods := nil.

 "Have another go at finding redundant stuff now dev. classes out of the
picture, but
  this time strip resources too"
 self stripRedundantClassesMethodsAndResources: self stripRedundantResources
  notifying: notifier.
 self destroyAndRemoveProgressNotifying: notifier.

 "Some of the libraries may no longer be required."
 self closeExternalLibraries.

 "Necessary to clear these before other class meta-info in order to allow
GUID to be stripped by
 before the ClassBuilder is removed."
 self stripClassGuidsNotifying: notifier.

 "One last go with the progress dialog removed"
 self stripRedundantClassesMethodsAndResources: self stripRedundantResources
  notifying: notifier.

 "Class removal will no longer be possible after the next message is sent.
This is the point to insert any
 debug trace to determine why a class remains in the image"
 self stripClassBuilderNotifying: notifier.
 self stripClassInfoNotifying: notifier.

 "And one final go at the methods that might be hanging around because of
class stripping code"
 self
  finishedWithAll: #(#stripClassBuilderNotifying: #stripRedundantResources
#stripRedundantClassesMethodsAndResources:notifying:
#addClassesReferencedByClass:andResources:to: #stripClassInfoNotifying:).
 self stripRedundantMethodsNotifying: notifier.
 self foldEmptyMethodDictionariesNotifying: notifier.
 self finishedWith: #foldEmptyMethodDictionariesNotifying:.
 self stripSystemDictionaryNotifying: notifier.

 "Remove as much as we can of the remainder of ImageStripper in case it
hangs around"
 self finishedWithStripping.
 self shrinkHashedCollections.
 self shrinkSymbolTable]
   on: Error
   do:
    [:x |
    "Trap all errors"
    self notify: notifier status: x description.
    self onError: x]
   on: Notification
   do:
    [:n |
    "Route all notifications to the notifier"
    self notify: notifier status: n description.
    n resume].
 SessionManager current inputState queueDeferredAction: (MessageSend
    receiver: self
    selector: #saveExecutable:
    arguments: (Array with: path)).
 self finishedWithAll: #(#onError: #stripAndSaveNotifying:)! !
!ImageStripper categoriesFor: #stripAndSaveNotifying:!must not
strip!operations!public! !

"Carsten Haerle" <[hidden email]> wrote in message
news:41124c6b$0$27055$[hidden email]...
> The coping and updating of the version resource is done before the
> preStripScript is executed which is to early, because all changes in the
> pre
> strip script to version resource do not get into the executable. I just
> moved the code of copyAndUpdateStub after the preStripScript. Another
> solution would be to move the preStripScript to the beginning of the
> method.

This is by design .If you want to update the version resource
programmatically, you should subclass ImageStripper and override the
#versionResource method, e.g.

versionResource
 | verString |
 verString := MyApp versionString.
 ^(super versionResource)
  productVersion: verString;
  fileVersion: verString;
  yourself

Then select your custom image stripper in the deployment wizard.

Regards

Blair

Could you give me a short explanation why this design was choosen?  If you
say it's by design then why should one want to prevent preStipCode to modify
the version resource?

"Blair McGlashan" <[hidden email]> schrieb im Newsbeitrag
news:[hidden email]...

"Carsten Haerle" <[hidden email]> wrote in message
news:41186638$0$29868$[hidden email]...
> Could you give me a short explanation why this design was choosen?  If you
> say it's by design then why should one want to prevent preStipCode to
> modify
> the version resource?
>

It is not the intention of the design that you be prevented from modifying
the version resource in the pre-strip script as such, but that is a
side-effect of the performing the stub generation before anything else. This
latter was done at user request during the 5.0 beta if I recall correctly. I
can't remember the exact reason and it is not recorded in our change control
system. However no significant effort is involved in employing the
workaround for which I provided the necessary code, so I don't really think
it is worth investigating further.

Sorry

Blair

Blair,

> It is not the intention of the design that you be prevented from modifying
> the version resource in the pre-strip script as such, but that is a
> side-effect of the performing the stub generation before anything else. This
> latter was done at user request during the 5.0 beta if I recall correctly.

Might it have been to avoid excluding exe deployment on 9x?  I recall a
debate on the subject, but not when it occured.  Some things, such as
DLL deployment (new to 5.x, right??) require NT/2k for deployment, but
not everything.

IIRC, I suggested having some other features (icon replacement??) that
were easy to do on NT/2k be optional on NT/2k and unavailable on 9x.
The thought being that one could work on 9x, but NT/2k would allow more
things to work.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]