A bug, my hack of a fix and two little gripes

[PhotonDemon]

Hi,

The bug:

While playing with packaging an XD image as a Windows NT service, I came upon a small bug. The value for startUpClassName is saved in the package instructions but is lost when the instructions are used again. The selected and saved name:

The saved name.

startUpClassNameGood.gif (7.45 KiB) Viewed 199 times

The value displayed when using the instructions again:

The wrong name.

startUpClassNameBad.gif (7.89 KiB) Viewed 199 times

I think the buggy code is here:

Code: Select all

initializeFor: aPackager
   "ACTION
      This message is sent to the packaging instructions immediately
      after the packager is initialized with the information in the receiver.
      The receiver has an opportunity to perform any special initialization
      that is required.

      For a single image, add all the applications in the image and all of the
      feature applications to the list of applications to package. Set the
      startUpClassName based on the features in the passive image.

   PARAMETERS
      aPackager <EpPackager>
   "

"   aPackager sourceImageBaseApplications do:[:anApp |
      aPackager addApplicationNameToPackage: anApp name]. "
   (self abtFeatureApplicationNamesFor: aPackager) do:[:anAppName |
      aPackager addApplicationNameToPackage: anAppName].
   aPackager startUpClassName: (self featureStartUpClassNameFor: aPackager)


The fix:

I think the fix is to change the last line to:

Code: Select all

   aPackager startUpClassName isNil ifTrue: [aPackager startUpClassName: (self featureStartUpClassNameFor: aPackager)].


If there is a saved value for startUpClassName, it is left alone.

There are four (I think) implementations #initializeFor: than have the same last line and therefor I think the same problem. They would all need to be changed or the fix moved into #featureStartUpClassNameFor:.


The gripes:

Both gripes have to do with image size. After loading things into an image, I like to clean things up by using the "Options" menu item "Clean Up Image". I know there are warnings about this but I'm not cleaning up after testing or messing up the image, just after loading things. Right after the clean up, I save the image and all looks fine. The size of the image seems okay, say 13.7MBs. If I repeat the clean up (without doing anything else) and save the image, the size jumps to say 13.9MBs. If I do it again, it jumps another 200KBs to say 14.1MBs.

I know, all I have to do is not clean up twice but it does point out that something funny is going on.

The second gripe has to do with the size of a packaged XD image. If I package one of my apps as an NT service from the main image, I get an image size of about 1MB. When I package the same app as an XD image as an NT service, I get an image size of about 1.7MBs. Both images seem to work fine. This is also not a big deal but I am wondering if there isn't something odd here. Maybe this is normal for XD images or maybe I need to do some work removing more stuff.

Lou

[wembley]

Lou -

I'll start with your 2nd gripe:

There is a fundamental difference (by design) between packaging from a development image and packaging from an XD image, and the size difference you see is the result of this difference.

- When you package from a development image, you are using a reduced runtime packaging algorithm. This means the packager uses the provided rules about inclusion/exclusion/initialization/etc., together with its own hueristics, to reduce the size of the packaged image as much as possible.
- When you package from an XD image, you are using a non-reducing packaging algorithm. This means that every application identified in the packaging instructions is completely included in the packaged image. This makes packaging much simpler since most of the packaging rules are uninteresting in this packaging mode.

[PhotonDemon]

Hi John,

- When you package from an XD image, you are using a non-reducing packaging algorithm. This means that every application identified in the packaging instructions is completely included in the packaged image. This makes packaging much simpler since most of the packaging rules are uninteresting in this packaging mode.

Fair enough. I suspected as much but thought I would mention it. I hope my characterization as "little gripes" wasn't too strong. The sizes were not so large as to be a problem, it just made me a little concerned.

I am worried about the size of the main image. With VAST 5.5.2 when the dev image grew, it often meant something was wrong and it was time to load things into a clean image.

Thanks, Lou

[wembley]

Lou -

Remember (or notice) that there is no shared code between the development image and the XD image. This means that an XD development image has n + 1 (where n is the number of XD images you have created) copies of all the base classes.

[PhotonDemon]

Hi John,

Remember (or notice) that there is no shared code between the development image and the XD image. This means that an XD development image has n + 1 (where n is the number of XD images you have created) copies of all the base classes.

Got it. Thanks.

I think I haven't been clear about my main image size concern. The image I'm talking about doesn't have any XD images in it. I start with a clean image, if I change a setting, like the Transcript window font and save the image it grows by about 0.2MBs. If I clean things up by using the "Options" menu item "Clean Up Image" and save the image it may grow again by another 0.2MBs.

If I load some apps via configuration maps (I've started to use them more and more), when everything is loaded I save the image. Its size may look good or it may look too big. It isn't consistant. If I run "Clean Up Image" and save the image it may drop to a reasonable size or it may grow by about 0.2MBs.

The really odd think is that running "Clean Up Image" twice in a row without doing anything other than saving the image in between often grows the image

Lou

[g.cotelli]

John,
the startUpClass fix proposed it's Ok? I'm having the same problem doing XD Packaging and if it's Ok I will include this fix now.

Thanks,
Gabriel