SPIRAL TALE, KNIGHTS OF HATE Forum

In the CrossTie for this app, you have a self-extract threshold of 1, meaning the installer .exe will be treated as a self-extracting archive. The installer glob says not to run any installer after extracting the archive. There's one "Files to Copy" entry for "Dummy key" which I assume means that you don't really want to copy anything.

So you are apparently using none of the features for supporting self-extracting archives. It seems like a normal installer. Why set the self-extract threshold at all?

I heard the way to extract self-archive by inputting "1" into the threshold.
I don't know another way to extract self-archive.
Please tell me the another way.

If it erases the value self-extract threshold, it doesn't install correctly.
And if it doesn't input any value into the value of "File to Copy", it doesn't install correctly.

I want to create the c4p which executes the following.

1. Download this application's archive from the following URL.
   http://www.enterbrain.co.jp/gamecon/no4/data/stnh.exe
2. Extract all files from stnh.exe. (The stnh.exe is self-archive.)
3. Copy all files into the folder of "Program Files".
4. Add the start menu which calls the program of "Program Files/Stnh/Srpgexec.exe".

This .. won't work like that ; I've tumbled into this before. It's tantamount
to running the installer, but, having to do a filecopy operation as well ; in
other words, the installer isn't an installer =)

...I'm not sure of an answer, either. I suppose, in one way, it looks like a
case for having a secondary install profile as a predependency, wherein the
secondary install profile merely runs the self extractor (as specified by the
installer options in the primary install profile), but, it would have to occur
as a predependency, not post....

@Aric - if we had something like that, it would open up all crossties where
one needed to do such a thing?

Thank you for your replying.

I do not understand a detailed mechanism of crosstie.
I want to know the method of inputting the value.
How does it set the value of the crosstie for this case?
I want a concrete example.

For example.

1.  Download this application's archive from the following URL.
   "http://www.enterbrain.co.jp/gamecon/no4/data/stnh.exe"
   ->Set this url into the "Download URL" on Application Profile.
   2. Extract all files from stnh.exe. (The stnh.exe is self-archive.)  
      ->Set stnh.exe into the "xxxxxxx" on Install Profile.
   3. Copy all files into the folder of "Program Files".
      ->Set "xxxxxx" into the "File to Copy" on Install Profile.
   4. Add the start menu which calls the program of "Program Files/Stnh/Srpgexec.exe".
      ->Set "%StartMenu%/Programs/xxxxx" into the "Lnk Files" on Install Profile.

Hi,

Actually, I did recreate this to verify it behaved the same as other
self-extracting archives like it -- that is, Aric & myself did cross this
ground some time ago wrt some Microsoft 'hotfixes' & other (older) patches
which are distributed as self-extracting .exe files ; it is the same issue...

There is no concrete example as such, only variations .. ie; if the self
extracting archive itself accepts commandline arguments, you can effectively
get it to perform the filecopy operation as such - this is hardly the common
case though. Some self-extractors, for example winrar based .exe extractors,
can be handled by using the 'treatas' flag -- although it's a .exe binary, you
can sometimes pass the <treatas>.rar directive and it will decompress using the
builtin dearchiving routines -- this can be so for other archive types as well.
In those situations, you do not actually call on the crosstie to execute the
installer ; it's treated as a rar archive and normal filecopy in the crosstie
will work in such instances (.cab files are many times handled this way)...

..that, doesn't work with stnh.exe - I checked B)

...hmmm... the only way I can think out a possible way to achieve this currently,
would be having another (virtual) crosstie to call on as a postdependency, which
was itself just a filecopy operation, and call that as a secondary profile...
..then, in the secondary install profile specifications, tell the filcopy crosstie
what to copy where ... or something like this. That will currently fail on the
installed match for the primary profile however, and I'm uncertain if one could
carry that completion into the secondary profile....

Basically, you can't do both 'run exe' & 'filecopy' in the one crosstie profile,
I think perhaps because filecopy is held against the :stop: directive which assumes
no installer ; the logic falls apart when, in effect, you've told it there is
an installer, ergo, no filecopy is expected (nor undertaken, it would be a fork
away from the process progession)...

Does this help explain it further? Post back if you still have queries =)

Cheers!

...there are other examples of the contra case here, which more or less
go on to refute what I posted above - that is, you can perform both 'run
installer exe' and then after having 'extracted from a zip archive' scenarios
with relative ease ; I just did such a crosstie profile for app_id=9015.
There, the installer exe is inside a .zip archive, which is firstly extracted
to /T%ExtractDir% and once finished, the crosstie routine restarts with the
root of the install directory being $%ExtractDir% with the process taking the
value of <installerglob> to be the target installer exe to run...

...that, would not appear to have much to do with your scenario, but, it could
be said the stand alone .zip archive is being treated as a self extracting
installer ... even though it really isn't <grin> ; contextual rather than actual.

...if effect, you want to do something very similar, in context .. that is, treat
the self extracting exe file as a zip archive, but actually execute that file
itself to achieve such. Then ... the cxinstaller process should restart, with
the same root location of $%ExtractDir%, but not try to execute any installer.
Instead, you want the filecopy operation to take place based on that location,
to the specified $%TargetDir% as you would include in the same profile ; this would
also allow installed detection to work properly....

... as the established base logic seems so sound in other ways (and believe, I say
this with surety after having done over 200 of them =), even I do not want to break
or divert the what that is already there, rather add to it ... here, I think the
logical spot to add something to fix this with respect to what is already present,
would be to have another exclusive conditional on <installerglob> ? That is to say,
the current installerglob has 'installer.exe' or :stop: -- if we had another like
:filecopy: that would jump to that section when the process restarts (after extracting
the files from the self extracting exe), and then from $%ExtractDir%, it should all
work to completion in my mind... n'est par? If then one could link the existence of
the :filecopy: flag to mean 'run the selfextracting.exe but pretend it's a .zip', it
may tidy things up quickly...at least, this is how I see/understand the story thus far =)

...mind you, something like this would not only make this app doable in crosstie, it
would also open up many other apps/service packs/hotfixes/other that are bound to be
'out there' for us to discover ... hmmm....

Correct way to go about having such a change (or similar) considered, is to 'get it
into the ticket system', so I'll hoist a wish-list bug on it in a moment - iirc, you're
the 3rd or 4th advocate (counting myself) that have found frustrations here handling
self extracting (particularly .zip based) exe files.

"Files to Copy" should work just fine for a self-extracting archive with Installer Glob set to :stop:. It's just that you have to specify the names of some files to copy and a directory to copy them to.

Thank you for all the reply and detailed explanation.
I understood by your explanation it is difficult to make c4p for this application.
I confirm your explanation and try to make c4p.
However it may not be able to create by my skill.

OK, I think I understand what's going on here.

The exe is a self-extracting archive, but it seems to completely ignore command-line arguments. It always asks the user for a path, which defaults to the current directory.

If you can figure out a way to make it extract the files without showing any UI, it should be possible to make this work without any user intervention. That would be ideal, but I haven't found a way to do it.

Since we're stuck with that UI, there are two possible approaches:

1. Treat the archive as a self-extracting archive, and ask the user not to change the extraction directory. Then use "Files to Copy" with a glob of Stnh and destination of %ProgramFiles%. I've just tested, and this works.

or

2. Ask the user to set the extraction directory to Program Files. This seems to be what you're doing. This works fine, but it means the self-extraction logic doesn't help (and there's no reason to treat it as a self-extracting archive rather than a normal installer).

I would suggest doing it the first way, so that it works for a user who just clicks things without paying attention. Even if you ask the user to set the extraction directory to Program Files, I suggest setting the self-extract threshold and setting "Files to Copy" so it will work for a user who ignores the instructions.

Thank you for the reply.
I confirmed the behavior which the self-extracting archive extract as the usual archive.
However it can't copy any file into the bottle.

I specified the following value into c4p.
I input "Installer Globs:" into ":stop:".
I input "Files to Copy:"-"Glob:" into "Stnh/*".
("Stnh" is extracted folder name.)
I input "Files to Copy:"-"Dst:" into "%ProgramFiles%/Stnh".
I erase all value of "Advanced Installer Extraction Options:" .

You'll still need to set the self-extract threshold to 1.

In my testing, I had "Files to Copy:"-"Glob:" set to "Stnh" and "Files to Copy:"-"Dst:" set to "%ProgramFiles%" (meaning I was copying the folder Stnh instead of all the files in it), but I think it will work either way.

I tried to specify the following value.
I set "1" into the self-extract threshold.
I set "Stnh" into the "Files to Copy:"-"Glob:".
I set "%ProgramFiles%" into the "Files to Copy:"-"Dst:"

However it doesn't copy any files and folder into the ProgramFiles on the bottle.
What value did you set into other options?

The settings I tested are the same as the CrossTie on the website for this app. I don't know why it worked for me and not for you.

I heard this c4p works by 10.x.
But I have 9.x only.
I will confirm after releasing 10.x in Japan.