Re: [gtk-win32] Let's start some discussion.

[Jerome Haltom <wasabi larvalstage net>]

Alright, I'm going to do my short dissertation on what *I* would
(planned) to do, in the perfect world, where I had all the time in the
world. I've been looking at this situation as a semi-side-liner for 3
years now or so.

I am a typical Windows developer. I work for a small business, and write
applications for that business in the various RAD tools Windows (or
others) have introduced over the years. I've developed in Visual Basic
5, 6. I've had a brief stint with Delphi. I've done very limited amounts
of Java desktop application stuff. The last 3 years I've been doing
nothing except for C# and .Net.

I also administer the networks at the companies I have worked for.
Active directory, etc, blah. Some large deployments. Some small.

And then in my free time I seek to replace all of that with open source.

So, in attempting to use more open source technologies on Windows, my
first attempt was to attempt to develop applications in Java using the
Java-Gnome bindings. Java at the time still had a pretty large Windows
mind share, and Java-Gnome was just getting going. I never got the
application deployed. Changed jobs in between working on it, but it left
me with an addiction to Gtk. What a wonderful toolkit compared to the
other stuff I'd worked with. My main problem with Java-Gnome was
compiling it myself, and figuring out how to distribute the results
across the MS network. Java-Gnome was apt-get installable on Debian, but
Windows? Pssh. I got it running, after doing the compiling myself using
MinGW and such. Spent way more time on it than I should have. Barely got
it running, but had no end of issues getting the Java-Gnome JNI bindings
to compile. I left the job shortly after.

Next place I went to was once again a pure MS shop. But at this
time, .Net was well entrenched. I still missed Gtk sorely.
System.Windows.Forms has nothing compared to it... and of course, I
really want to write applications that can run on free platforms. So, I
started looking into solutions again.

And there was Mono! Gtk# works wonderfully on Linux. Wonderfully enough
on Windows. So, I started working in it more actively.

The problems I face today are deploying the application I create across
the Windows network. We use Active Directory to push out .MSI installer
files to the workstations, including updates. All of our software is
pushed this way. Office, all the major applications. The third party
stuff we buy all comes with .MSI files we can deploy this way.

Except Mono and Gtk#. So, I spent a few days trying to understand the
build process enough again to package Gtk# up in MSI files. Eventually I
ran out of time and had to move on to other things.

So, that's my life story.

Now, where do I think this should go? Well, end results, regardless of
technical challenges and such is I think we need installer files which
integrate into a Microsoft shop. That means MSI files. I have no love
for MSI as an installer technology. In fact I really hate it. It's
terrible. But in this world, MS sets the rules. If you want traction you
follow them. It's what the developers expect. If we want to get Gtk used
by Windows developers (and we do, it means they can be exposed to Linux)
then we need to fit in here. My own experiences are a lesson in this
way... I've been unable up to this point to get it working "right!"

Windows Installer is the general "brand name" these things go by. It's
basically a system service that does package management. It's archaic by
Linux standards. Two file types are involved. .msi files and .msm
files. .msi files are double clickable in the UI, and they open an
installer window. You can also deploy .msi files using Active Directory,
so the application will automatically install on reboot for all of the
computers in your office. You can deploy updates to these applications
by just deploying a newer .msi file. Each end user application should
have a single .msi file (sometimes with associated .cab files, but these
are not required.)

.msm files are called Merge Modules. They are essentially .msi files,
but which are able to be encapsulated in other .msi files. You cannot
double click on a .msm file and install it. Traditionally, libraries are
distributed as .msm files. For instance, if I was to go to Microsoft's
web site, and download, oh, Microsoft Foo they would give me an
installer in .msi format. It would be called the "Microsoft Foo SDK" or
some such. Installing it would result in the shared libraries for the
product being installed wherever they are supposed to (Common Files,
usually), and a .msm file installed to my disk.

As an application developer, I would write my program that linked to
MSDE in Visual Studio. When I was ready to publish and distribute my
application, I would use VS to make a new "setup and installer project".
This is basically just a GUI tool to produce a .msi file for my product.
At some point I would instruct VS to include the .msm file that
Microsoft Foo placed on the disk in the output. When I built the project
I would end up with a single file:  MyProject.msi.

Opening and installing MyProject.msi would include the shared libraries
for Microsoft Foo and my product. Now, if another product was installed
that also included Microsoft Foo, only one copy would be installed.
Because they would have used the same .MSM file to create their project.
If Microsoft deployed hotfixes to Microsoft Foo, I could either install
them from Microsoft, or obtain them from the vendors for either project.
This all works wonderfully in the closed source world, where the only
person who can possibly produce the .msm is the vendor.

If I wanted to publish MyProject.msi to the network, I would do so.
Whatever was required would be included. No need to really manage
dependencies and such.

As for parallel installs? Well, MsFoo1.msm and MsFoo2.msm do not have to
be related in any fashion. They can be the same product from the same
vendor, but with different UpgradeIds, installed to different locations.
They would coexist. Applications could include either.

So where would we start on this? First we'd have to decide on how we'd
like to break up our different software. Our software is more fine
grained than most Windows software. Gtk+ isn't just Gtk+. It's built on
top of Pango, Glib, gettext, Cairo and others. Exactly who should be
responsible for what portions of this stack? My personal preference lies
with keeping the Windows distributable for a given shared library as
closed to that library as possible. I would desire each of Gtk, Pango,
Glib, gettext and Cairo to have their own separate merge modules,
maintained in their own respective source repositories. It means there
is one canonical location to go to to get the redistributable for each
of these. There cannot be an argument over whose version is better if
there is a version in upstream.

We'd need to decide on where we will install this stuff, and how.
Traditionally our software likes to be single-rooted. That is, we choose
a single root directory and install all versions into that one directory
under /lib and such. If we're going to handle parallel installs of
different versions of Gtk, which itself depends on different versions of
pango, glib, etc, we need to make sure we can fit all of these
combinations into one sub directory. There is also the Windows linker to
consider. You can only really append version names to the libraries:
gtk-2.10.dll, for instance. Each application which depended on
gtk-2.10.dll would only be able to function with gtk-2.10, no later
version. Is this acceptable? It is as long as we get parallel installs
working. There is no symlinking of one version to another version name.

Common Files\foss\bin\gtk-2.10.dll
Common Files\foss\bin\glib-2.12.dll
Common Files\foss\bin\pango-1.16.dll
Common Files\foss\share\icons\

Who would determine the name of the directory, and how would we get
everybody to agree?

Can all resources fit into one directory structure? For instance gtk
stock icons? Can we have different versions of Gtk putting their stock
icons in the same directory?

I don't really believe this idea is feasible. Unless every sub directory
and every file had a version number append to it, there would be
conflicts.

Another option, which has it's own issues, is to have each library
maintain it's own root, and deal with the bugs that pop up. For
instance, install gtk, pango, and glib into a set of directories like:

Common Files\gtk\2.10
Common Files\pango\1.16
Common Files\glib\2.12

This is certainly the easiest way to deal with simple file conflicts,
but it introduces some obvious problems: linking it all together. An
application which expected a certain version of it's libraries would
have to have some way to specify it's library search path. Additionally,
I'm unsure how our software likes situations like these. They'd all have
to load their resources from different paths.

Now, as for building .msi and .msm files. Most Windows developers I'm
aware of use Visual Studio itself, since it has pretty wizards and
stuff. Or a commercial third party package. Since obviously you are not
going to use any of those, that leaves WiX.

wix.sf.net

WiX is a small open source program which will generate msi and msm
files. You feed it a fairly long and wordy XML document, describing what
files it should package, where they should be installed, and assigning
two GUIDs for each file plus 8.3 file names, and it will build you a
package. It's tedious to write these XML files. I'd recommend an
approach more like running a shell script to spew XML snippets into the
middle of a template. WiX, to my knowledge, will not run on Mono.

So this is where I left off at this point. I didn't have the time to go
through the process of compiling and testing all of this. But it is most
certainly the way I would suggest approaching the problem.

I think you can argue all day for or against using InnoSetup, NSIS, or
Windows Installer. You can bring up all the technical merits of each,
and get nowhere. I cannot deploy NSIS or InnoSetup files across my
company, packaged along with my Gtk apps I want to develop, and have it
work in any sane manner. I would need to buy third party deployment
tools, or write my own. If that was required, I would not be using Gtk
for the task.

Sorry for the huge super sized e-mail. =)

</end>