I am writing a web application on a Unix server for Windows users. 
The app delivers a bundle of PowerPoint files that are zipped using a
Perl WinZip module.  The size of the archive varies depending on the
files chosen by the user.  Currently the user has to download the
archive and launch winzip.  I'd like to provide a self-extracting
winzip archive as an .exe FOR Windows FROM a Unix (Solaris) platform
without introducing any additional software (using only perl and tools
available on a standard Solaris system).  I think the approach would
involve prepending the zip file with a binary stub that looks like a
winzip self-extracting file.  Can someone explain how to do this?

---

Request for Question Clarification by efn-ga on 01 Oct 2005 08:52 PDT

The first place to look for this function would be the module that you
use now to create the zip file.  From what I have been able to find,
it looks like "WinZip" is the name of a shareware program that runs in
Windows, and not the name of a generally available Perl module.  Is
that really the name of the Perl module you used?  If not, what is the
name?

If that module does not have this function, the next easiest solution
would be to find one that does.  Are you open to installing another
Perl module?  Since you said using only Perl and no additional
software, I can't tell if another Perl module counts as additional
software.

Creating new software to generate a self-extracting Windows executable
file on Solaris is certainly possible, but would be a lot more work
than finding an off-the-shelf solution.

--efn

---

Clarification of Question by iron_jon-ga on 01 Oct 2005 11:11 PDT

efn-
My apologies for not including this in the original post -

we're using Archive::Zip.  I'm unable to get the version number for
the pm at present.

i think the good folks at winzip might take issue with the notion that
they're selling 'shareware' but certainly it's common practice to use
the evaluation copy long beyond expiry.  Recent versions of Windows
include an extractor for winzip (.zip) files so we can assume our
users can unpack zipped files (as opposed to .tgz or .sit or what have
you)

to clarify as much as i can - we can probably 'use' a not-yet-installed
perl module (by including the code in our project) as long as it is
pure perl.  'install'ing may be possible but is at the whim of the IT
gods that rule the production servers.  i am but a lowly contractor
with ssh access to the dev server. on the other hand, the installed
perl library is fairly vast.

you're response inspired me to look at the Archive::Zip docs again and
there is an example script in the distro called selfex.pl.  Here are
the comments from that file:

# Shows one way to write a self-extracting archive file.
# This is not intended for production use, and it always extracts to a
# subdirectory with a fixed name.
# Plus, it requires Perl and A::Z to be installed first.
#
# In general, you want to provide a stub that is platform-specific.

the example is a self-referential way of implementing self-extraction
- it prepends the zip with perl code that uses Archive::Zip to unpack
the file.  We can't count on Sales people using the app to have Perl
and Archive::Zip installed on their Winders notebook, nor would we
want to ;)

---

Request for Question Clarification by maniac-ga on 03 Oct 2005 18:32 PDT

Hello Iron_jon,

I am running a few tests to confirm proper operation of the self
extractor from "info-zip" on an Archive::Zip generated file. I will
provide the results by this time tomorrow. If the tests work, I will
provide a step by step method of modifying your .zip files generated
by Archive::Zip on a Solaris system to self extract on a Windows
system (I assume you don't need Windows 3.x, but if so, please
indicate).

In the mean time, could you confirm that the license at
  http://www.info-zip.org/pub/infozip/license.html
is acceptable for your application?

The license is quite liberal, allowing free redistribution of both
source and binary (in this case, the latter) as long as you preserve
the copyright notice (already in the binary) and don't call it
Info-zip (or the other variants listed in the license).

  --Maniac

---

Clarification of Question by iron_jon-ga on 04 Oct 2005 07:18 PDT

maniac -

the license looks acceptable.  let me know how your tests go.

I've never seen a requirement to support win 3.x and really?  i mean
come on.  not an issue.

i'm unclear of the correct protocol here since there are two answers
pending and both seem like they could work.  maniac's approach is more
along the lines of what i was thinking of, but efn's approach gets to
the heart of the matter as well.  i guess it's really an issue for ga
or the 'experts' since i pay only once, but i'm curious how this
works.

---

Request for Question Clarification by maniac-ga on 04 Oct 2005 09:04 PDT

Hello Iron_Jon,

Due to the price offered and the clarification, I will post this first
as a "Request for Clarification" to allow you to confirm the solution
and adjust the price of the question / post a second question if
necessary.

To answer your latest clarification, there is only "one" (or no)
answer to any question. If you want to pay two researchers, you need
to have two questions - this has been done before by other customers.
If you want to do this, adjust the price on this question to what you
consider my answer is worth to you and post a second question with the
remaining amount - mentioning that efn-ga should answer it. In this
way, I can answer this question and efn-ga can answer the other
question so you get both answers and we both get paid.

To answer the specific question:
  - how can I create a self-extracting archive on Windows on a solaris platform

I did some searches using phrases like
  winzip self extracting
  zip self extracting solaris
and found products like

[1] WinZip Self Extractor
  http://www.winzip.com/prodpagese.htm
which appears to do what you ask (and a lot more) but has some
licensing fees and possible legal encumberances. It does not appear to
identify the capability to be used on Solaris, but based on how the
other utilities that work, it may be adaptable to your use.

[2] Funduc Software FS ZIP Extractor
  http://www.funduc.com/fszipx.htm
which has a nice user interface for creating self extracting archives
on Windows but also has a "manual mode" described as...
   COPY /B "C:\Tools\FsZipX\FsZipX.exe" /B 
     + "C:\My Documents\Example.zip" /B 
     "C:\My Documents\Example.exe"
(I split the command into several lines to fit, this would be a single
command on windows)
which is simply the process of a "binary" copy where two files are
concatenated to produce the self extrating archive. The equivalent
command on Solaris (any Unix actually) would be
  cat FsZipX.exe Example.zip > Example.exe
(replace the file names with paths to the files)
There is a free download on this site at
  http://www.funduc.com/ftp/fsx.zip
the license is included in the zip file which gives you the right to
copy / distribute the self extractor software with your product but
does not allow you to charge a fee or include in a commercial product
without prior approval from Funduc.
     
[3] Zip Fusion
  http://www.skaro.net/zipfusion/
Again, another file extractor that is "freely available" but has
license and registration requirements that may make it unsuitable for
your use.

[4] Info-Zip
  http://www.info-zip.org/pub/infozip/
or perhaps more specifically, UnZipSFX which is included with the
Unzip package described at
  http://www.info-zip.org/pub/infozip/UnZip.html
Download the Windows (not Solaris) version - make sure you get the
generic Windows version like this copy
  http://www.mirrorservice.org/sites/ftp.info-zip.org/pub/infozip/WIN32/unz552xN.exe
and extract the files using any of the available unzip programs on
Solaris. Yes - you can extract the files using a Solaris utility
program, even though it is a self extracting archive for Windows.

Included in the zip file is the man page, also on line at
  http://linuxcommand.org/man_pages/unzipsfx1.html
which describes the same cat command (the first example) mentioned in
[2] above. It is this process I used to generate a Windows self
extracting file on a Unix system (and the subject of the testing I did
this morning).

Based on your response, the license terms are reasonable and based on
my testing this is certainly the solution I suggest (though others may
do as well).

I also suggest you try this solution to confirm it works for you.
Please provide the results in another clarification so I can either
explain further or properly answer the question.

  --Maniac

---

Clarification of Question by iron_jon-ga on 06 Oct 2005 09:56 PDT

Thanks Maniac - let's see if we have a solution and then I'll take
care of protocol...

I'll respond to each possibility below:

[1] WinZip Self Extractor
  http://www.winzip.com/prodpagese.htm
which appears to do what you ask (and a lot more) but has some
licensing fees and possible legal encumberances. It does not appear to
identify the capability to be used on Solaris, but based on how the
other utilities that work, it may be adaptable to your use.

---- I started here, of course, but WinZip only works on Windows. 
gzip is supposed to have a self-extracting mode but it seems the
version we have on our  Solaris servers doesn't do this, which would
be the simplest of all solutions.

[2] Funduc Software FS ZIP Extractor
  http://www.funduc.com/fszipx.htm
which has a nice user interface for creating self extracting archives
on Windows but also has a "manual mode" described as...
   COPY /B "C:\Tools\FsZipX\FsZipX.exe" /B 
     + "C:\My Documents\Example.zip" /B 
     "C:\My Documents\Example.exe"
(I split the command into several lines to fit, this would be a single
command on windows)
which is simply the process of a "binary" copy where two files are
concatenated to produce the self extrating archive. The equivalent
command on Solaris (any Unix actually) would be
  cat FsZipX.exe Example.zip > Example.exe
(replace the file names with paths to the files)
There is a free download on this site at
  http://www.funduc.com/ftp/fsx.zip
the license is included in the zip file which gives you the right to
copy / distribute the self extractor software with your product but
does not allow you to charge a fee or include in a commercial product
without prior approval from Funduc.

---- Once again, I believe this software only runs on Windows.  If we
could have a Windows server in production I wouldn't have to go
through all this trouble in the first place but no chance of this and
i can't really blame them.
     
[3] Zip Fusion
  http://www.skaro.net/zipfusion/
Again, another file extractor that is "freely available" but has
license and registration requirements that may make it unsuitable for
your use.

--- purchasing the license for commercial use is not really an issue. 
I'm investigating if i can put the packaged stub at the beginning of
the zip file on solaris and have it self-extract on windows.

I can make a really nifty-looking self-extracting exe with ZipFusion
but there aren't any specific directions on how to 'build' one
yourself.  I'm guessing you prepend the zip file with zf.exe and
append it with the config file but can't try that yet.

[4] Info-Zip
  http://www.info-zip.org/pub/infozip/
or perhaps more specifically, UnZipSFX which is included with the
Unzip package described at
  http://www.info-zip.org/pub/infozip/UnZip.html
Download the Windows (not Solaris) version - make sure you get the
generic Windows version like this copy

------ I believe I tried this product before and had problems
appending the stub reliably.  a sample would be helpful.

Dear iron_jon,

I have tested the following procedure under SunOS 5.8, and I am
confident that it will work under older versions of Solaris as well.


1. Download the following file to your Solaris account. This is your magic stub.

http://plg.uwaterloo.ca/~mlaszlo/answers/sfx32.dat


2. Make a .zip file using the zip command. For example,

  zip stuff.zip file1 file2 ... fileN

or

  zip stuff.zip dir1

where dir1 is a directory containing a bunch of files.


3. Concatenate the stub and the zip file, in that order, to make a
.exe file. Like so:

  cat sfx32.dat stuff.zip > stuff.exe


4. Run zip with the -A switch to adjust data offsets past the stub.

  zip -A stuff.exe


5. You're done! Send the .exe to your people and let them extract away.


Regards,

leapinglizard

---

Request for Answer Clarification by iron_jon-ga on 07 Oct 2005 10:33 PDT

Thanks leapinglizard - this looks like exactly the right thing,
however, I'm having some trouble with my archive.  When I did the zip
-A command I got the following:

> zip -A sb_test.exe
        zip warning: extended local header not found for setup.exe

zip error: Zip file structure invalid (sb_test.exe)


so I checked the zip file itself : 

> zip -T storybuilder.zip
        zip warning: extended local header not found for setup.exe

zip error: Zip file structure invalid (storybuilder.zip)

The above zip and thousands like it have been downloaded and opened
around the world this year, so I'm sure that the format is 'valid'
though I'm now not convinced it is 'correct'.  I looked around to see
what an 'extended local header' was and how a valid zip file could be
missing one.

I found this helpful link: http://www.onicos.com/staff/iz/formats/zip.html
which describes the zip format, in particular:

ZIP format
Byte order: Little-endian

Overall zipfile format:
[Local file header + Compressed data [+ Extended local header]?]*
[Central directory]*
[End of central directory record]

....

Extended local header:
Offset   Length   Contents
  0      4 bytes  Extended Local file header signature (0x08074b50)
  4      4 bytes  CRC-32
  8      4 bytes  Compressed size
 12      4 bytes  Uncompressed size

Since we build the zip files with Archive::Zip i checked to see if
there was anything addressing 'extended local headers' in the pod and
there is nothing explicitly mentioning such but there seems to be a
few ways to tweak the zip file contents for offsetting headers.  Since
this is not part of the original question, I will research the issue
myself a while.  However, I can't validate this answer until I can
resolve the problem so if you have any insight into it, let me know. 
Thanks.

---

Request for Answer Clarification by iron_jon-ga on 07 Oct 2005 11:21 PDT

Aha!  I've found the answer to my extended headers problem:

from: http://search.cpan.org/~smpeters/Archive-Zip-1.16/lib/Archive/Zip.pod

writeToFileHandle( $fileHandle [, $seekable] )

    Write a zip archive to a file handle. Return AZ_OK on success. The
optional second arg tells whether or not to try to seek backwards to
re-write headers.

We WERE writing to STDOUT which does not allow Archive::Zip to
re-write headers since it can't seek backwards.  Changed this to
writing temp files and allowed seeking and voila, a zip with valid
headers!

furthermore, completed the steps leaping lizard set out and created a
self-extracting exe on the development server that I could download
and run on my windows box.

So, the answer is complete.  thanks to all of you for contributing. 
i'm not really done with this problem since I still have to make the
exe palatable to our users, but this is a huge step.  I'm going to go
back and see if i can get the zipfusion stub (which allows kool
konfiguration options) to work like sfx32.dat did but I'm close enough
to finish it on my own.

Thanks again...

---

Clarification of Answer by leapinglizard-ga on 07 Oct 2005 13:33 PDT

I'm glad everything has worked out to your satisfaction.

leapinglizard

the answer addressed everything I requested in a completely
understandable way.  My only reason for using 4 stars instead of 5 is
that I did not include some aspects of the question in my original
asking that would have made this a great answer.

Thanks for your clarification.

If the file is self-extracting, it shouldn't matter if it uses zip or
some other form of compression, since the decompressor is built into
the file and doesn't require anything on the client's system.  You
might want to adjust your question accordingly.  That is, you might
want to specify that you will accept a solution that takes a bunch of
files and packages them into a self-extracting Windows executable file
by some means other than first creating a zip archive file, then
converting it to a self-extracting file.

I haven't been able to find an off-the-shelf solution.  The closest I
found was a free C++ program that you could build in Solaris and run
on the web server to create self-extracting executable files for
Windows.  That is, it would do the compression and packaging a zip
archiver would do, as well as making the output an executable
self-extractor.  It uses non-zip compression.  I don't think Solaris
comes with a C++ compiler, so even if you accepted the non-zip part,
this wouldn't qualify as an answer.  However, if you have or can get
access to a C++ compiler and you think it does qualify, please post a
clarification saying so, and I will post an answer about this program.

Note to other researchers:  I waive professional courtesy.  If you can
answer this question, go for it.

yes, your point that the particular sort of compression is not
important as long as the extraction is automatic is well taken.  we
need some sort of compression because we're sending large files to
users all over the world, sometimes connecting over dial-up and any
extraction has to be native to windows since that's the target client.
 so be it modified that 'winzip' compression is not a requirement for
an answer.

I'm checking with the team to see if the c++ solution is acceptable.

OK - I have verified that we have g++ (gcc version 2.95.2 19991024
(release)) installed on our development machine and I compiled a
helloworld program to test it.

So how would this solution work?

The way the solution I mentioned would work is:  You download some C++
source code and build it on Solaris into executable program that runs
on Solaris.  Then you copy the executable program somewhere where the
web server can run it.  Then you rig your web server Perl script so
that instead of packaging files into a zip archive with the
Archive::Zip module, it runs this compiled C++ program, specifying the
same files as input and some temporary file as the output.  Then Perl
script should send that file out to the web client.

There could be problems with this do-it-yourself approach, depending
on your experience and environment.  You could have trouble getting
the program to build or to run properly.

Compared to this approach, I think Maniac's (and your original)
approach of just gluing two files together is simpler and less risky,
so if you can build sufficient confidence that it will work through
the clarification process and testing, I'd recommend that you buy his
answer.  But thanks for your interest in mine.