I did an install of the linked beta a few days ago without TI-Connect installed and found this bug: TILP's driver files expect C:\Program Files (x86)\Common Files\LPG Shared\drivers\usb\x86\libusb0.dll to be named libusb0_x86.dll instead.

I just renamed the DLL instead, but I guess that works too . Glad to help.

IOW, the .inf files need adjustment. Thanks for the report

It may not make a difference, but I would lean towards changing the installed filename rather than changing the inf file.

In my previous post introducing a build, I stated that the development for the TILP II 1.17 cycle was considered finished... but then, there was need for much more development

It's high time another build was made, and I had just enough time to package and upload a new build this morning. The build is untested.

* refreshed the installer at http://tiplanet.org/beta/setup.exe . (unusual URL, the ticalc.org FTP is still experiencing trouble)
* the patchset against SVN HEAD is http://tiplanet.org/beta/tilp_patchset_20130321_0840.tar.bz2 (note: patch 4 introduces a build failure, I have fixed it locally but haven't had time to refresh the patchset before leaving).
* as usual, the install script is https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

Highlights since the previous beta build, more than two months ago:
* fixed TILP under Windows XP, broken due to libarchive automatically configuring itself to use a function not exported on that version of Windows;
* some 84+CSE support: hardware version, temporary kludge for sending 84+CSE pictures (Benjamin Moody)
* the 8 feature + bugfix patches from the previous patchset, detailed in the two previous posts about new builds, have been pushed to SVN;
* more compiler (Clang) warning fixes;
* export more functions which were previously internal, e.g. the 83+ family DBUS commands (where the useful memory page dump command was added - astute readers could think that it might be related to the 84+CSE), or functions and data structures from the DUSB family;
* fix a crash reported by Deathrider with wrong TI-86 files;
* when communicating with 84+ through DUSB, allow variables with the same name but different types, by Benjamin Moody;
* add known 84+CSE hardware version, and plausible default model for unknown hardware versions;
* install_tilp.sh: add ready-made `apt-get install` command line for Debian & derivatives (OK, who wrote "at last ?" )
* more USB-related fixes for the tilp installer, by Benjamin Moody;
* try to fix a BSOD triggered by dhahelper (Benjamin Moody & myself);
* remove some MinGW special-casing, as discussed above (Benjamin, Jonimus, myself)

As you can see, a sizable part of the work was done, or at least reported, by Benjamin

EDIT in 2021: updated the link to the *nix install script.

after a quick compile and testing, all seems well on this end. thanks =)

I have just released TILP II 1.17, GFM 1.07 and the associated libraries

Guess what... many changes since TILP II 1.16 (quite a bit more than between any two consecutive releases from years past, in fact), the most noteworthy of which are:
* conversion of TILP from Glade to GTK+Builder: the bulk of the work was done by Jon Sturm, it opens the door to further improvements on the code base.
* Initial, incomplete TI-84+CSE support: OS upgrades, FlashApps, pictures and possibly certificate files are supported (provided the files are renamed from *.8c? to *.8x?), background images not supported.
* new TI-Z80 ROM dumper, with improved 82/85 support, 84+ Flash unlocking, etc.
* USB scan at startup (options.auto_detect) enabled by default (but old config files are not updated, obviously), to match the behaviour of TI-Connect and TINC(L)S.
* no more cmd window for TILP on Windows: the output is now properly redirected to a file even when there's no such window (by Benjamin Moody).
* other features: raw mode external linking, loading libusb-win32 dynamically, tons of previously (wrongly) internal libticalcs functions now exported to user programs so that they no longer need to copy and paste thousands of lines of code if they merely want to implement a new command not yet implemented by libticalcs, Nspire remote control primitives, 83+ DBUS memory page dump primitive, initial TI-80 VSC support, etc.
* bugfixes: more warnings, more crasher bugs, more undefined behaviour fixed (clang is a valuable tool !); upstream fixes to ease downstream packagers' job.

Special thanks to Benjamin Moody and Jon Sturm for their contributions and code reviews !
More changes to come: switching to Git full-time, first-class 84+CSE support, new TI-Z80 commands, further modularization / cleanups / hardening / improvements of the code base, etc.

Here are the source tarballs: libticonv, libtifiles, libticables, libticalcs, tilp, gfm.
Here are the Windows installers: tilp, gfm.

-A built-in TI-84 Plus C Silver Edition ROM dumper that supports direct USB linking that is also failsafe from any computer CPU spikes (unlike Jonimus' silverlink dumper)

The modified DBUS (legacy I/O) and DUSB (DirectLink) ROM dumpers are in my mailbox, I need to apply them (and another, prerequisite patch from Benjamin)
I hope to be able to test the dumpers on a real 84+CSE soon.

-The ability to get a screen capture while in 160x240 resolution mode. TI-Connect only works in 320x240 mode (in 160x240 it says "Error getting screen shot").

I definitely see why that would be useful, but I'm unsure we could implement that out of the box:
* if the root cause of the screenshot while in 160x240 mode failing is that the calculator's OS just doesn't handle screenshots of size not equal to 320x240, it could prove hard to implement 160x240 size screenshots;
* if the root cause lies on the computer side (TI-Connect refuses the data because it doesn't have the appropriate size), that should be easier.

Pending further examination, the 160x240 screenshot feature request is now written down in the TODO list

Whenever I try getting a calc capture in normal mode, it works perfectly (takes around 20 seconds). When I try in 160x240 mode, it waits like 30-60 seconds, doing absolutely nothing, then it throws "Error getting screen shot" at me. I tried several times too, and even removed the cable/put it back in before retry.

As for TilEm I'M out of luck because the only compatible ROM dumper that exists doesn't run on my computer and I can't find any ROM anywhere (not that the latter is really right nor legal, anyway).