Addendum to what fortytwo wrote: before using https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh , uninstall all libti* and tilp packages you downloaded from the USC, and install the build dependencies (listed inside the script).


[quote=Jonimus]Lionel, another issue we need to fix before the next windows release is the default file location when built with mingw. When MSVC was the official release compiler this wasn't an issue but now it is built with mingw we shouldn't special case it and default to g_get_home_dir() like we do for other OS's. The relevant code is in tilp_paths.c at line 93. This one has annoyed me for a while and tifreak8x also recently ran into it so I took the time to track it down.[/quote]
I do trust you and tifreak about the fact that there's an issue... but would you be so kind as to explain me how it manifests ?


The new code in tilp_config.c does no longer attempt to write the config to Program Files, so the issue you're pointing shouldn't exist ?


A good suggestion, but clearly TILP II 1.18 material.


OK, thanks for the update on that task. Too bad the API is so slow...


The Git trees created a while ago should do the job (through not as well as the new repo organization), even if at the time of this writing, I haven't pushed the latest SVN commits to the Git tree (I haven't automated the process).


It would be slightly easier for me, but compiling TilEm and TIEmu would therefore require checking out gfm+tilp as well, which is not necessarily what Benjamin & Thibault (for TilEm) and myself (assuming I'm spending some time to give a little love to the unmaintainable pile of patched forks, event loop mixup and fragile build system that TIEmu is) want.


That could work, though the current build scripts do the job and would require little in the way of modifications. IOW, the task of making a unified autoconf setup to stick several autoconf folders together might conceivably be delayed a bit.


`autoreconf -i -f` is usually good enough as an autogen.sh.

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

After installing the latest Beta form the Planet-TI link I get this when trying to run it on Windows XP.
It sounds to me like it may be a bug in mingw or at least how it is packaged on your build system. Are you building with the standard mingw or mingw-w64, perhaps that is a factor?

Meh. The fact that such problems exist shows that I don't test every single Windows build on my minority of Windows computers / VMs, but the fact that they go unreported for months shows that there aren't as many Windows users interested in beta-testing as we could wish...

I used whatever Debian provides as MinGW cross-compiler.
Benjamin's simultaneous, independent analysis sent in an e-mail indicates that this is a dependency of libarchive, and that "configuring libarchive with 'ac_cv_func__ctime64_s=no' should fix this" - so that's what I shall do before producing the TILP II 1.17 RC Windows build

Well great news, as I said in my email (just posting here for others to see) I just got confirmation from benryves on IRC that my serial backend with the TICALCS_DEBUG calls removed matches fastlink in speed on real serial hardware. On Windows 8 no less. This means my speed issues were either related to the debug printing or my USB->Serial adapter. While this won't help parallel link users it will be good news for BlackLink/$4 Link users. No more possiblity for dhahelper driver bugs causing BSOD's.

I'll make a topic with links to DL the DLL and how to test so we can get a better idea of how well it works.

One other comment he made was that dirlist receiving was slower than fastlink due to all of TILP's INFO output. Again this confirms for release builds the console window needs to go. Users can run tilp from cmd if they really need it to help us track down a bug or need help fixing an issue.

Having users just send me ~/.tilp.log has proved a valuable debugging resource for me multiple times (actual bugs, or misconfigurations on the user side, such as not selecting a cable or calculator model properly - even if that should be less frequent now that auto-detection defaults to on), and as the code base currently stands, making the console window go away by switching from console to non-console builds breaks that.

I remain fully open to the console window going away (FWIW, IIRC, I tried some reopen(...), to no avail, but maybe I should have done it sooner or later in the process)... but not to the cost of
1) breaking the functionality of ~/.tilp.log (which users can just send to me / post on a message board)
or
2) requiring users to launch tilp from cmd. If the user is not experienced, it can look scary and require maintainer time holding users' hands.

Patches welcome for keeping the full functionality of writing ~/.tilp.log in non-console builds
If it requires changing logging in libti* (adding a method to trigger redirection to a file, etc.), so be it.

on a related note .tilp.log and .ticables should really be in %APP_DATA% not HOME. I think there should be a glib call to get $XDG_CONFIG_DIR or %APP_DATA%, it might be worth looking into that.

You also want a separate location for the Mac version. Preferably ~/Library/Logs/TILP2/org.ticalc.lpg.tilp.log

The important bit (to get the path for ~/Library or the appropriate equivalent) is this:

Code:

Redirection to ~/.tilp.log is a Windows-only thing, because the Windows console sucks (horrible slowdown)

Seems like having TILP as a console program is an undesirable feature in many cases.

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.

New build tonight, which can probably be considered the TILP II 1.17 release candidate

* refreshed the installer at http://tiplanet.org/beta/setup.exe .
* the patchset against SVN HEAD is http://tiplanet.org/beta/tilp_patchset_20130322.tar.bz2 .
* as usual, the install script is https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

Changes since yesterday's build:
* fixed the silly build failure in patch 4 of patchset that I mentioned yesterday;
* patch 3 of patchset (trying to fix the BSOD triggered by dhahelper) worked, but I improved it;
* really (hopefully) fixed TILP under Windows XP. Benjamin indicated that it's not just _ctime64_s which needs to be forcefully removed from the configure options of libarchive, but also _localtime64_s and _mkgmtime64. For good measure, I also removed _fseeki64 - it's not like libtifiles is going to deal with files whose size can't fit in 32 bits anyway ^^
* added a patch by Benjamin, for redirecting output to ~/.tilp.log under Windows (in a better way).
* stripped libarchive-12.dll, which reduces the size of the decompressed binary from 60 MB to less than 500 KB, and reduces the size of the TILP installer by a megabyte or so...
* now compiling with -mwindows, so that the ugly command-line window is gone
* updated the ChangeLog and RELEASE files.

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

It now works on XP.

At least it opens properly. I won't get time to test the actually sending until later tonight but hey, it opens!

Edit: Tested with my 84+CSE last night and everything seems to be in working order. At least with the things that are supported by the 84+CSE. There are of course some features that are not yet implemented but at least everything that is supposed to work on XP still does.

Just FYI, AntiVir found TR/Crypt.ZPACK.Gen7 in TILP II 1.17RC. I contacted them about a false positive, they've confirmed it and updated their filters.
Their response: http://pastebin.com/w8E1veGp

Thanks, I read last night's discussion between Jonimus and you on #cemetech in my logs
That's not the first false positive from one of the AV software on the TILP or TIEmu installers...


<insert rant about the AV industry milking consumers big money with severely ineffective and defective products, which let lots of viruses install but warn users about harmless open source software>

But on the other hand I'm very surprised that they responded in about 3.5 hours and their filters are already updated.
(To make that clear, I don't use their products, I only uploaded it to virustotal.com since Chrome complained about malware when I downloaded ticalc.org's version of TILP.)

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.

Lionel, are you sure the cmd73 functions are exported on windows? According to VS2010's dumpbin utility they are not which means I'll still have to resort to my hacky stuff for the initial release of the 84+CSE rom dumper.

I won't ask why you're using VS2010. I do see those functions listed among the exports, though:

Code:

hmm well exports seems to disagree


Code:


I have no clue what the issue is then, but I should be able to create the def file from the objdump output so that'll do I guess.

Maybe the issue is that you're looking at a version of libticalcs2 from Dec 14?