If I understand your question right, the answer is "both".
The "wizard" or stub installer is a native application on each platform. C++ I
think. It's purpose is to provide the essential components of a working
application with http/ftp functions and nothing more. The binary itself is
quite small - around .5 mb on Windows including an exe & dll. But the other
half of the answer is that all of the installer related functions are built in
to shared library files, written in javascript I believe. This set of
libraries are a downloadable component seperate from the stub itself, which
means you can often update the installer without updating the stub.
The basic method you'll use to build an installer is pretty easy, if
undocumented. Essentially, you modify the config.ini to use your own values,
and within the config.ini describe the components of the installation you want
the installer to handle. A component can be one or more files. Once you have
the components described, you list them within installer "types", such as
"Full", "Minimim", "Custom", etc.
You then create your components. It is usually a matter of placing your
component files within a folder structure:
\
\install.js
\bin
\bin\myfile1.exe
\bin\myfile2.dll
etc.
The install.js file is a javascript file that tells the installer how to handle
the files. Usually it needs little modification except for file names,
versions, and size information, but apparently you can do some nifty things
with it that I've never needed to do.
When you have the file structure laid out, you just zip it up to retain the
folder structure, rename it from .zip to .xpi ("zippy"), and you're done.
What's really nifty (from my point of view) is that you, the developer, can have
a say in what the installer does even after the customer installs it - at least
for future installations. As a part of each of my installers, I make a
component that is the binaries of the installer stub itself, and another
"config" component that is the config.ini, install.ini, readme and license
files. In each of the installer types, I include the component that has the
config.ini. So each time my customer updates, they get a new set of
configuration files from my server, and the installer becomes a new version
that knows about new things. My customers never even have to open a web
browser to update their software, and certainly don't need to hunt all over my
support site looking for new versions, know how to unzip files, etc. I just
upload new .xpi's to the server and tell them to update using the update icon
in my application. Painless. I'm just bummed the Mac version was killed.
Have fun
Rob Brandt
Business Edge Software
http://www.businessedgesoftware.com
Quoting Kendall Bennett <[EMAIL PROTECTED]>:
> Andrew Schultz wrote:
>
> > XPInstall consists of a couple different parts; one is the install
> > wizard. Although the install wizard for the Mozilla builds just does
> > Mozilla, you can modify it to handle any program by modifying the
> > included config.ini.
>
> Great! How is the installer itself written? Does it go direct to the
> underlying OS such as GDI or GTK or something on Linux? Or does it use
> the cross platform API components that Mozilla is based on. Finally how
> big is the installer binary, and can it be used to build self installing
> executeables?
>
> Thanks!
>
> --
> Kendall Bennett
> Chief Executive Officer
> SciTech Software, Inc.
> Phone: (530) 894 8400
> http://www.scitechsoft.com
>
> ~ SciTech SNAP - The future of device driver technology!
>
> _______________________________________________
> Mozilla-xpinstall mailing list
> [EMAIL PROTECTED]
> http://mail.mozilla.org/listinfo/mozilla-xpinstall
>
_______________________________________________
Mozilla-xpinstall mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-xpinstall
