I and multiple others didn't, even on 64-bit Windows 10 Developer Preview.
However, on 8/8.1 and 10, one needs to use Zadig to self-sign the CAT file, as mentioned above. A signed driver binary is no longer enough.

As hinted above, the signed drivers of the libticables version accompanying TILP II 1.16 made unsigned driver mode superfluous
TILP II 1.16 was released in November 2011...

QuoteHaving access to the root of documents would still be sort of useful,

When I implement support for > 1 level of folders in TILP, I'll have a better idea of what it takes to achieve access to files at the root of the documents hierarchy.

Quotealso setting the target directory from the command line (I use tilp in scripts, especially for ndless projects).

You'd better using titools for scripting
TILP's CLI is very limited indeed, and it was worse before a suggestion of mine, implemented as part of Romain's last release.

QuoteAlso maybe this conversation should be split. *prods Eiyeron*

On the one hand, the discussion has strayed from the original question, but on the other hand, the original question, and a followup question by the original poster, have been answered.

QuoteWaaaait. TI gave you calculators for making a competitor of their software?

Yes, TI EdTech did give calculators to Romain, and does it for me.
libti*/gfm/tilp is effectively complementary to TI-Connect / TI-Connect CE / TI-Nspire Computer (Link) Software: it works on Linux across many ISAs, to begin with, whereas they don't target anything but Windows and MacOS X (which libti*/gfm/tilp target as well, of course). I very much doubt TI considers libti*/gfm/tilp as any kind of serious competitor to their offerings (and even if they were... it means that they have to improve their products !).
Providing hardware to one third-party developer at a time costs them several dozens of dollars (production cost) divided by number of models (less than one on average) per year. The fact that there's a set of programs (developed by people who are doing it for no fee, during their spare time) which can communicate with TI graphing calculators on platforms they don't target (and also platforms they target) gains them far, far more than several dozens of dollars per year

HP has a different approach to helping third-party developers: more information, less free hardware. But HP is helping third-party developers nevertheless, because it makes perfect business sense.

QuoteThe one thing that still needs improvement is Nspire support tho.

Not just that
The todo/wish/bug list is far more lengthy than that. Its contents are not a secret, several important items have been posted here and there over time. It's privately distributed to several persons who act on it, but not public (at least for now), because it's large and presented in an unattractive way (a 30+ KB plain text file containing verbatim excerpts from private e-mails; yes, done items are being trimmed once in a while), and changes often.

QuoteLinking works fine but you can't access the whole fs.

* support for > 1 level of folders was recently refreshed to HEAD, improved, then added to the experimental branch in the tilibs repository (currently the first commit of that branch), but it's not readily accessible to most users until I work again on the TILP UI part of the change at some point, which is the reason why 1) it remains on the experimental branch and 2) I don't communicate much about it.
* accessing files at the root of the documents hierarchy isn't done, but users seldom do that;
* accessing files outside the documents hierarchy is not allowed by the calculator-side implementation of the commands. Not any longer, that is; OS 1.x made it possible to dump the OS through a dumb directory traversal flaw.

QuoteThen how was TILP possible to make?

Given that the official driver is not a valid option, for licensing and functionality reasons, then things were made differently.
Namely, by using specific third-party drivers (as strongly hinted by my previous message). The specifics of those drivers have varied over time, and for USB devices, settled to libusb before I became the maintainer in 2009.
I contributed a patch to upstream libusb-win32, so that it provides a built-in way to handle buggy devices (read: devices which don't respect the USB standards), such as some TI graphing calculator models handled by libticables. Previously, these devices' peculiarities were handled through an unsigned fork of the libusb-win32 driver. The fact that the signed libusb-win32 driver could fulfill the purpose, after my patch, is what solved the driver issues for USB cables on 64-bit Windows 7 in TILP II 1.16. Then, Microsoft found it smart to annoy driver developers even more, in Windows 8/10, where having a signed driver binary is no longer enough, the CAT files also need to be signed. Another manual step based on Zadig, left to the user...

QuoteBy reverse engineering the protocol used by the calcs. It's far from being an easy task though.

Yeah, reverse-engineering both the cable and calculator protocols. TI EdTech does not provide official documentation about these protocols, but does obviously not attempt to prevent people from documenting them and making programs for platforms they don't want to support. In fact, they help the process a bit, by providing some cables and calculators to the developer of the libti*/gfm/tilp stack, formerly Romain Liévin and nowadays myself, at no cost.
I bought only 5 TI graphing calculators out of the ~25 I have. I don't have every single model: for instance, I have neither 92+, nor V200. 15 were picked up from Romain Liévin, a number of those were given to him by TI. My CX CAS and 84+CSE were given to me by TI, pending other models.

QuoteTiLP was also maintained by very skilled programmers with years of experience beforehand.

I know you probably didn't imply that it no longer is, and Streetwalrus beat me to stating that it still is, indeed
As a number of other old-timers of the calculator communities (this also occurs in the HP community), I started programming on a regular basis on (in fact, for) calculators, and became a professional software developer.

Quote(although dev has slowed down a lot as of lately apparently, it works much better than TI connect for me).

After a burst of activity leading to the release of TILP II 1.17 in March 2013, development slowed down somewhat indeed, though there were always bursts of activity every few months, if you look at the commit history. That was largely due to my day job, especially from October - November 2013.
However, development picked back up a lot since December 2014, with several major new features, especially improved 84+CSE support by Benjamin Moody, a new USB probing API by Benjamin as well, 83PCE/84+CE(-T) support (nearly complete, ROM dumping is pretty much the only missing feature) and 82A support (that calculator model sucks), both mostly by myself. Of course, besides hundreds of bugfixes, 99% of them invisible and fixing more or less minor bugs, which usually don't happen / are not an annoyance (e.g. memory leaks) under normal conditions, otherwise they'd have been reported and fixed a long time ago. The libti*/gfm/tilp code base is just like most code bases: it works well, but it's full of bugs (well, less so nowadays).
The TILP beta-testing topics are on TI-Planet and Cemetech.

QuoteHow do I integrate TI's device driver into a Windows 10 universal app?

You don't, for at least two obvious reasons:
* a permanent one: licensing/copyright;
* a potentially transient reason: platform support. That is, for now, TI's drivers do not support all of the platforms which could be targeted by an universal app.

QuoteYou can use your own driver, though you'd need to uninstall TI's driver

Not necessarily, as shown by libticables' drivers based on libusb: libticables' drivers and TI's drivers can work side by side if the user performs manual installation of the libusb-win32 filter driver for the targeted devices
I downloaded the very first Windows 10 developer preview, and successfully checked TILP's operation on that version. I just hope the final version will behave the same (that is, it won't be even more obnoxious wrt. driver requirements).

QuoteI feel like making a calculator linking software App for Windows 8\10 in Visual Basic that would compete with TI-Connect and TILP

Wow. This is an extremely bold aim, given the size and difficulty of the task of writing proper calculator linking software

For more information, see my long post at http://cemete.ch/p235167#235167 . In fact, I wrote that post, then I was made aware of that topic, so I expanded the content on Cemetech to widen the audience and perspective.

QuoteThe game works great and I was able to fix a few problems with KnightOS's C support while making it.

Small projects, especially for new platforms / environments, usually have that effect. In 2011, advancing an old Lua port to the TI-68k/AMS series, and partially porting "p14p" python-on-a-chip to the same, yielded improvements in GCC4TI.
That's also why in 2010, I suggested the making of a demo (in the demoscene sense) for the Nspire platform.

Exactly. Though there still exists a market for science professionals (in a wide sense), on which HP's older calculator models hold significant presence, for most users, programmable calculators have become an artifact of the worldwide school systems' silliness.

But we're straying off-topic

QuoteAs for Nspire, I heard that it's a major PITA to setup an Nspire environment compared to a HP PPL, TI-84+ BASIC or even ASM one

There's a pre-built SDK for Windows, a build script for *nix, and a pre-built Docker-based version of the SDK for Linux. Could be worse
I didn't check when the pre-built SDKs were last updated, that said.

QuotePlus the lockdowns discourages many people from doing Nspire dev.

Yeah. Why bother deal with a closed, underpowered platform such as the Nspire (or even the Prime, more open, but still without usable access to native code because nobody bothers and also still way underpowered) when you can do far more with a much cheaper ARM-based development board ?
The power-price-openness gap between calculators and real computing platforms keeps only widening over time. Even some Chromebook models are only barely more expensive than the Nspire CX CAS / Prime; Chromebooks can somehow run standard Linux (instead of / in addition to Linux-based ChromeOS, that is), and unlike the dev boards, they feature all three of screen, battery and (full-featured) keyboard.

The fact that very few TI-Z80 programmers use C is a consequence of the fact that the Z80 was not designed for C. The few C compilers targeting the Z80 ISA generate poor code which makes even mildly experienced Z80 ASM programmers laugh at the missed optimizations, which waste both space and time.
The eZ80 is a newer design, with several features making it a somewhat better target for C than the Z80 is, but still nowhere as suitable a target as the 68000, ARM and in general, most ISAs designed since the late 1970s.

Indeed. But getting users to buy new calculators is precisely the goal

Getting back to a slightly older post:

Quote from: DJ Omnimaga on April 06, 2015, 08:03:05 PM
Wow TI, really? They're locking down Z80 calcs too?

Unless it's to give people incentive to pay more and go with the CE instead. But I hope it's not in response to the hacking of the CE discussions going on.

In the industry, development cycles for new products, even those which are small modifications to existing ones, take months. The 82A was already locked down long before the recent availability of the 84+CE, and the subsequent, unsurprising quick reverse-engineering

QuoteFor Z80 calcs, the only color emulators available are jsTIfied and WabbitEmu

There's also TilEm, which got some 84+CSE support long before WabbitEmu did