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

[Jerome Haltom <wasabi larvalstage net>]

Hmm. Actually, the first time I played with Gtk was 4 years ago now...
I'm getting old. =(

On Mon, 2007-05-07 at 08:19 -0500, Jerome Haltom wrote:
> 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>
> 
> _______________________________________________
> gtk-win32-list mailing list
> gtk-win32-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-win32-list