Addendum to what fortytwo wrote: before using , 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 ? Smile

I also think we should remove the checks for the old config file in program files and just inform people that old configs will be ignored in the new version. This should solve the issue of someone running as admin once and writing the config in program files and if they try to do it again failing. It might annoy a few XP users and people on Vista/7 who have UAC disabled but for security and future compatibility it needs to be done.

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 ?

We also need to look at making libusb-1.0 based libticables builds on windows possible because it currently appears that due to a change in the driver signing requirements may make libusb-win32's libusb0.sys not an option on Windows 8 machines. While 1.0 doesn't work with the filter driver the latest git does work with our current libusb0.sys standard driver as well as WinUSB which is installed by default or available via Windows Update on all machines running Vista or newer. (XP is a separate download but available at least)

A good suggestion, but clearly TILP II 1.18 material.

As I've mentioned on IRC I have also gotten Proof Of Concept driverless Blacklink / $4link support on windows working but it is far too slow to be usable atm. It works, slowly, with my TI-86 at least, but the faster calcs such as the TI84+SE seem to give up faster than I can toggle the lines with my current code. I have some ideas to speed it up namely only switching the lines I need rather than switching all of them all the time. Espcially since via the Windows Comm API, namely EscapeCommFunction, can only switch one of the out lines at a time so its currently two outputs per write rather than one. Inlining my helper function would also perhaps help but I have a feeling the API call is the biggest slowdown. I already had to remove the delay in order to not have it timeout every time.

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

Having a git tree to work off of would be grand we really need to get that setup, svn just doesn't really cut it for this sort of thing and the branching/merging is horrid.

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).

Finally on the subject of moving to git. Since tilp is basically the main consumer of libti* moving to a single large git tree maybe wouldn't be the worst.

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.

Two, one for the libs and one for the GUI would also be a an option, either way a unified autoconfig setup would and should be integrated if we make that move.

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.

But we really need to remove configure and other autoconf generated files from the VCS tree. To facilitate easy testing something like mesa's would be an easy way to facilitate this.

`autoreconf -i -f` is usually good enough as an

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.
tilp.exe - Entry Point Not Found

The procedure entry point _ctime64_s could not be located in the dynamic link library msvcrt.dll.

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 Smile
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. Wink

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)
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 Smile
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:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);
Redirection to ~/.tilp.log is a Windows-only thing, because the Windows console sucks (horrible slowdown) Smile
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 Very Happy

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 . (unusual URL, the FTP is still experiencing trouble)
* the patchset against SVN HEAD is (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 .

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;
* add ready-made `apt-get install` command line for Debian & derivatives (OK, who wrote "at last ?" Razz)
* 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 Smile

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 Smile

* refreshed the installer at .
* the patchset against SVN HEAD is .
* as usual, the install script is .

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 Smile
* 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:
Thanks, I read last night's discussion between Jonimus and you on #cemetech in my logs Smile
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>
Lionel Debroux wrote:
<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 since Chrome complained about malware when I downloaded's version of TILP.)
I have just released TILP II 1.17, GFM 1.07 and the associated libraries Smile

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:


$ objdump -p libticalcs2-11.dll | grep ti73
        [ 109] ti73_recv_ACK
        [ 110] ti73_recv_CTS
        [ 111] ti73_recv_RTS
        [ 112] ti73_recv_SKP
        [ 113] ti73_recv_VAR
        [ 114] ti73_recv_VAR2
        [ 115] ti73_recv_XDP
        [ 116] ti73_send_ACK
        [ 117] ti73_send_CTS
        [ 118] ti73_send_DEL
        [ 119] ti73_send_DUMP
        [ 120] ti73_send_EOT
        [ 121] ti73_send_ERR
        [ 122] ti73_send_KEY
        [ 123] ti73_send_RDY
        [ 124] ti73_send_REQ
        [ 125] ti73_send_REQ2
        [ 126] ti73_send_RTS
        [ 127] ti73_send_SCR
        [ 128] ti73_send_SKP
        [ 129] ti73_send_VAR
        [ 130] ti73_send_VAR2
        [ 131] ti73_send_VER
        [ 132] ti73_send_XDP
hmm well exports seems to disagree

D:\Gtk+\lib>dumpbin /exports libticalcs2-11.dll
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file libticalcs2-11.dll

File Type: DLL

  Section contains the following exports for libticalcs2-11.dll

    00000000 characteristics
    50CB60CA time date stamp Fri Dec 14 11:24:26 2012
        0.00 version
           1 ordinal base
         143 number of functions
         143 number of names

    ordinal hint RVA      name

          1    0 000197E4 cmd_r_copy_file
          2    1 000194C9 cmd_r_del_file
          3    2 000196BD cmd_r_del_folder
          4    3 00018A83 cmd_r_dev_infos
          5    4 00018D96 cmd_r_dir_attributes
          6    5 00019158 cmd_r_dir_enum_done
          7    6 00018F28 cmd_r_dir_enum_init
          8    7 00018FD8 cmd_r_dir_enum_next
          9    8 00019F2D cmd_r_echo
         10    9 00019B0F cmd_r_file_contents
         11    A 000199B4 cmd_r_file_ok
         12    B 00019368 cmd_r_get_file
         13    C 00018852 cmd_r_login
         14    D 000195C3 cmd_r_new_folder
         15    E 00019C8E cmd_r_os_install
         16    F 00019DC1 cmd_r_progress
         17   10 00019A41 cmd_r_put_file
         18   11 0001990D cmd_r_rename_file
         19   12 00018BE4 cmd_r_screen_rle
         20   13 00018958 cmd_r_status
         21   14 000196D8 cmd_s_copy_file
         22   15 000193EA cmd_s_del_file
         23   16 000195DE cmd_s_del_folder
         24   17 000189E8 cmd_s_dev_infos
         25   18 00018CB3 cmd_s_dir_attributes
         26   19 000190CC cmd_s_dir_enum_done
         27   1A 00018E4E cmd_s_dir_enum_init
         28   1B 00018F43 cmd_s_dir_enum_next
         29   1C 00019E89 cmd_s_echo
         30   1D 00019A4A cmd_s_file_contents
         31   1E 00019928 cmd_s_file_ok
         32   1F 00019287 cmd_s_get_file
         33   20 00019FCC cmd_s_keypress_event
         34   21 000194E4 cmd_s_new_folder
         35   22 00019CFC cmd_s_os_contents
         36   23 00019BD0 cmd_s_os_install
         37   24 00019173 cmd_s_put_file
         38   25 000197FF cmd_s_rename_file
         39   26 00018B45 cmd_s_screen_rle
         40   27 000188B0 cmd_s_status
         41   28 0001BB71 dbus_recv
         42   29 0001B8C4 dbus_send
         43   2A 0001BD14 dusb_recv
         44   2B 0001BBD8 dusb_send
         45   2C 0001D246 nsp_addr_assign
         46   2D 0001D19D nsp_addr_request
         47   2E 0001CDE6 nsp_recv
         48   2F 0001D4ED nsp_recv_ack
         49   30 0001DA3F nsp_recv_data
         50   31 0001D71B nsp_recv_disconnect
         51   32 0001CB0A nsp_send
         52   33 0001D301 nsp_send_ack
         53   34 0001D841 nsp_send_data
         54   35 0001D5E9 nsp_send_disconnect
         55   36 0001D3AC nsp_send_nack
         56   37 0001D44D nsp_send_nack_ex
         57   38 0001D69F nsp_session_close
         58   39 0001D141 nsp_session_open
         59   3A 0001D03E nsp_sid2name
         60   3B 0001CFE8 nsp_vtl_pkt_del
         61   3C 0001D0D1 nsp_vtl_pkt_new
         62   3D 0001D061 nsp_vtl_pkt_new_ex
         63   3E 0001F0AE ticalcs_cable_attach
         64   3F 0001F0F6 ticalcs_cable_detach
         65   40 0000386C ticalcs_calc_change_attr
         66   41 00003684 ticalcs_calc_del_var
         67   42 00002B30 ticalcs_calc_dump_rom_1
         68   43 00002BB8 ticalcs_calc_dump_rom_2
         69   44 00002074 ticalcs_calc_execute
         70   45 00001F24 ticalcs_calc_features
         71   46 00002D22 ticalcs_calc_get_clock
         72   47 0000220A ticalcs_calc_get_dirlist
         73   48 00002321 ticalcs_calc_get_memfree
         74   49 0000394C ticalcs_calc_get_version
         75   4A 00001F54 ticalcs_calc_isready
         76   4B 000035D0 ticalcs_calc_new_fld
         77   4C 00002909 ticalcs_calc_recv_app
         78   4D 0000350F ticalcs_calc_recv_app2
         79   4E 000023E5 ticalcs_calc_recv_backup
         80   4F 00002F32 ticalcs_calc_recv_backup2
         81   50 00002E82 ticalcs_calc_recv_cert
         82   51 00003AA3 ticalcs_calc_recv_cert2
         83   52 00002A80 ticalcs_calc_recv_idlist
         84   53 00002146 ticalcs_calc_recv_screen
         85   54 000019C6 ticalcs_calc_recv_tigroup
         86   55 00003DAA ticalcs_calc_recv_tigroup2
         87   56 000025FF ticalcs_calc_recv_var
         88   57 000031F9 ticalcs_calc_recv_var2
         89   58 0000278E ticalcs_calc_recv_var_ns
         90   59 0000338C ticalcs_calc_recv_var_ns2
         91   5A 00003741 ticalcs_calc_rename_var
         92   5B 00002859 ticalcs_calc_send_app
         93   5C 00003462 ticalcs_calc_send_app2
         94   5D 00002495 ticalcs_calc_send_backup
         95   5E 0000303B ticalcs_calc_send_backup2
         96   5F 00002DD2 ticalcs_calc_send_cert
         97   60 000039F6 ticalcs_calc_send_cert2
         98   61 00001FDC ticalcs_calc_send_key
         99   62 000029CD ticalcs_calc_send_os
        100   63 00003C38 ticalcs_calc_send_os2
        101   64 000016F6 ticalcs_calc_send_tigroup
        102   65 00003CE5 ticalcs_calc_send_tigroup2
        103   66 00002545 ticalcs_calc_send_var
        104   67 0000313C ticalcs_calc_send_var2
        105   68 000026D4 ticalcs_calc_send_var_ns
        106   69 000032CF ticalcs_calc_send_var_ns2
        107   6A 00002C72 ticalcs_calc_set_clock
        108   6B 000126BC ticalcs_clock_date2format
        109   6C 00012654 ticalcs_clock_format2date
        110   6D 00012751 ticalcs_clock_show
        111   6E 0001A150 ticalcs_dirlist_destroy
        112   6F 0001A1BC ticalcs_dirlist_display
        113   70 0001A7DC ticalcs_dirlist_flash_used
        114   71 0001A734 ticalcs_dirlist_ram_used
        115   72 0001A91A ticalcs_dirlist_ve_add
        116   73 0001A68C ticalcs_dirlist_ve_count
        117   74 0001AB5B ticalcs_dirlist_ve_del
        118   75 0001A556 ticalcs_dirlist_ve_exist
        119   76 0001ACBC ticalcs_error_get
        120   77 0001F142 ticalcs_handle_del
        121   78 0001EFD7 ticalcs_handle_new
        122   79 0001F042 ticalcs_handle_show
        123   7A 0001F1B8 ticalcs_keys_73
        124   7B 0001F1C9 ticalcs_keys_83
        125   7C 0001F1DA ticalcs_keys_83p
        126   7D 0001F1EB ticalcs_keys_86
        127   7E 0001F1FC ticalcs_keys_89
        128   7F 0001F20D ticalcs_keys_92p
        129   80 0001EFBD ticalcs_library_exit
        130   81 0001EE88 ticalcs_library_init
        131   82 0001F2F5 ticalcs_memtype_to_string
        132   83 0001F220 ticalcs_model_to_string
        133   84 0001F289 ticalcs_pathtype_to_string
        134   85 0001E51D ticalcs_probe
        135   86 0001DF6A ticalcs_probe_calc
        136   87 0001E3FE ticalcs_probe_usb_calc
        137   88 0001F236 ticalcs_scrfmt_to_string
        138   89 0001F30F ticalcs_string_to_memtype
        139   8A 0001F22B ticalcs_string_to_model
        140   8B 0001F2A2 ticalcs_string_to_pathtype
        141   8C 0001F24F ticalcs_string_to_scrfmt
        142   8D 0001F18B ticalcs_update_set
        143   8E 0001EFCD ticalcs_version_get


        1000 .CRT
       11000 .bss
        3000 .data
        8000 .debug_abbrev
        1000 .debug_aranges
        7000 .debug_frame
       66000 .debug_info
       22000 .debug_line
       1B000 .debug_loc
      EC8000 .debug_macinfo
        3000 .debug_ranges
        2000 .debug_str
        2000 .edata
        2000 .idata
       15000 .rdata
        6000 .reloc
        1000 .rsrc
       20000 .text
        1000 .tls

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? Razz
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 4 of 7
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum