TiEmu - a TI89(ti)/92(+)/V200 emulator.

(Sorta like I already do with libxml and libglade which I just download,
unzip and drop into the GTK+ directory if they aren't already there as
they're supposed to. Hey folks, libglade is the recommended way to use
Glade and has been for years, it's even the only way with Glade 3, are you
all drawing your UIs by hand in code? Or do you think dropping libglade
into each application directory is a solution? Why do you still ship GTK+
runtimes without libglade? The gladewin32.sourceforge.net runtime packages
are the only ones I can recommend because they actually contain what's
needed, I support the others out of necessity, but IMHO they're all
broken.)

What I could also do, of course, is to simply "fix" the GTK+ installation
by adding the PATH entry if it isn't there yet.

So that explains how Pidgin does it.
TiEmu doesn't have a launcher, the main executable is registered directly
in the start menu.

We can do the AppPath magic, but entering GTK+ into the PATH is what all
the other GTK+ runtime packages around do, so I don't know how many other
programs break with the Pidgin package (which adds the registry keys as if
it was one of those GTK+ runtimes, but omits the PATH entry). I'm sure
TiLP, GFM and TilEm all break. TilEm doesn't even use an installer which
could be used to register AppPath, it's just a ZIP package.

So basically this is doing things optimally vs. doing things compatibly,
tough tradeoff.

And I know different versions of GTK+ are likely to conflict, we get some
reports of this, I always close them as invalid and clearly state that ONE
AND ONLY ONE version of GTK+ has to be on the system, with reinstalling the
operating system as the suggested fix. I don't see a valid reason for
having zillions of copies of GTK+ around anyway (and absolutely hate
programs which dump private copies of GTK+ into some directory instead of
using a shared runtime, they are the ones causing those conflicts -
Pidgin's "semi-shared" runtime is interesting, but I'm not convinced I like
it either, given the compatibility implications).

Response from http://developer.pidgin.im/ticket/5651 :
---
04/28/2008 12:40:44 PM changed by datallah ¶
owner changed from lschiere to datallah.
component changed from unclassified to winpidgin (gtk).
pending set to 1.

In general, it is best to avoid polluting the System Path with stuff that
is likely to conflict (as some components of the GTK+ runtime are likely to
do). It would cause all sorts of problems for other programs if we did
this.

The best thing to do would be for the TiEmu installer to add an AppPath
(or to make the launcher not depend on GTK+ and fix the path at runtime
(like what pidgin does)).
---

Can the TiEmu installer do this?

Filed this in Pidgin's bug tracker at
http://developer.pidgin.im/ticket/5651 .

I looked at Pidgin's gtk-installer.nsi and I have come to the conclusion
that it's Pidgin's GTK+ runtime installer which appears to need fixing. The
GTK+ runtime installer is supposed to add "$INSTDIR\bin" to the system PATH
(HKCU\Environment\PATH). Again, I have no idea how Pidgin itself locates
the GTK+ DLLs, but other apps (such as TiEmu) definitely can't find them if
they aren't in the PATH, and I don't see how I could fix this in TiEmu
because the OS isn't even loading the executable. I could only hack around
it in the TiEmu installer and I think getting Pidgin's GTK+ runtime
installer fixed is a better solution.

Supposedly, this kind of configuration shouldn't allow the packaged
libraries to conflict with installed libraries. It was designed to allow
programs to run of USB drives, for example, without installing anything on
the host system.

I don't think that's a good idea, I've seen all sorts of strange problems
caused by having more than one GTK+ version installed on a Window$ system
at a time.

One possible solution could be to use a "portable" installation, such as
described for Pidgin on
http://developer.pidgin.im/wiki/Using%20Pidgin#RunningWindowsPidginFromaUSBDrivePortableMode
- this will allow TiEmu to use a different Gtk+ runtime than on the system,
but that might be overkill.

Hmmm, anything we can do for this? I'd really like to fix this sooner
rather than later, but with no idea as to what's wrong, I can't really do
anything about it. :-(

I'm afraid I really don't understand what's going on. :-( Apps built
against an older glib (as TiEmu is) should still work with the latest one
(that's why the DLL name is still the same). I have no idea why it fails to
load the library.

Nope, I'm not setting any search paths. Probably the search path isn't the
problem if the Gtk+ installer sets it up automatically. Pidgin finds it
just fine.

If you think DLL hell is bad, try installing multiple versions of Cygwin
:), but that's for another thread...

How does Pidgin find its libraries? Are you setting a per-application DLL
search path on pidgin.exe?

TiEmu currently expects the DLLs to be in the system-wide global library
search path, and all the GTK+ runtime installers we've previously
encountered set it up that way, so this has never been a problem before.

(I hate that operating system. Always in DLL Hell. I don't understand how
it got the reputation to be easy to install software on!)