This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Lionel Debroux
1
« on: December 09, 2013, 02:06:19 am »
ccya965041: you found nothing new, TI-Planet found them weeks ago and forwarded information about them to other sites  If you install OS 3.6.0.546 to your calculator, you will lock it to that version, without any possibility to downgrade to even OS 3.2.4.1237, let alone OS 3.1.0.392 (the latest one with arbitrary native code execution, and thereby much increased power and usefulness)...
2
« on: November 22, 2013, 01:51:37 am »
The instructions that I know of are at http://desowin.org/usbpcap/tour.html . Only steps 1 and 2 are required on your side, step 3 is my job  Step 4 is an option, but then, you'd have to install Wireshark and produce files from Wireshark, which is more complicated. Thanks.
3
« on: November 21, 2013, 11:29:40 am »
To be clearer than the last paragraph of critor's post: admins, make DJ_O cool down, or face reduced newsing activity by critor & Adriweb (and thereby reduced activity of your entire board). Lower activity due to a single person out of his mind is the last thing the community needs, needless to say.
4
« on: November 21, 2013, 11:12:45 am »
DJ, how about you stop polluting topics and spouting nonsense about language wars ? As he tried to explain you (but you won't listen) critor's post wasn't aimed at creating a war.
If anything, the one who created division and war in the topic was you, by having a stupid interpretation of what was written.
5
« on: November 21, 2013, 01:42:19 am »
We don't know for sure, otherwise we'd already have posted weeks ago Lua is no substitute for native code anyway.
6
« on: November 18, 2013, 12:26:30 pm »
The privacy implications of a cloud OS are impressive indeed.
However, assuming Microsoft has such plans, there's already a cloud OS on the marketplace: Chrome OS. The Chromebooks powered by Chrome OS are selling reasonably well, and they're well-behaved enough wrt. installing standard Linux distros (Chrome OS is based on Linux, anyway).
7
« on: November 17, 2013, 03:21:45 pm »
If one knows how to do it, the data can be recovered from the debugger when opening the document in TI's OS running in the third-party nspire_emu emulator.
The data in TNS files uses a TI software patent on XML compression, and TI might sue anyone trying to make another program for turning TNS into cleartext.
8
« on: November 16, 2013, 02:33:30 am »
Also, since the HP Prime supports sub-programs, I decided to split the sprite data into 6 sub-programs. This sucks for people who hate games that uses multiple files, but I seem to get fewer crashes from code editing now. Good I think people will have no choice but to split large programs.
9
« on: November 15, 2013, 03:29:58 am »
The trace shows that there have been a number of silent packet losses during transfer. Besides being fundamentally slow due to usage of HID and delays (even if seemingly still too fast for Windows' crappy USB stack on your computer - maybe some driver or anti-virus is interfering, as Tim Wessman doesn't witness slowness to the extent you do ?), the protocol used by HP isn't robust wrt. packet losses... The computer sends increasing first bytes, but the calculator does not, so packet losses are harder to detect when the calculator is the sender (more precisely, it's basically impossible detect where data was lost, without more intimate knowledge of formats). This means that I'll have to rewrite recv_backup functionality. While triggering recv_file in a loop works most of the time, it falls apart if there are any packet losses. Receiving as much data as the calculator sends, then attempting to split it after the fact, would make it possible to salvage more data, though the heuristics might fail in very infrequent cases. Another usability problem with the current recv_backup implementation is that in case of an error, it destroys any data received from the calculator before returning to the caller. Users would probably rather have partial, corrupted backups than nothing To reduce the risks of your largest programs being lost as a result of a combination of transfer failure (induced by packet losses, statistically more likely on large programs) + calculator-side bugs (some of which require erasing stuff through the maintenance menus), you'll have no choice but to split them somehow. I don't know how.
10
« on: November 14, 2013, 08:28:34 am »
Not that zlib is huge, but FWIW, the Nspire OS itself contains zlib, and a number of zlib functions have been exported by Ndless as syscalls for two years and a half (OSLauncher was the first program to depend on these syscalls) Unless some of the zlib functions MuPDF needs are not available at all in the version embedded into the Nspire's OS, you could leverage the OS's copy of zlib (adding syscalls to the IDC files and Ndless lists if need be).
11
« on: November 14, 2013, 02:26:10 am »
Yeah, nLaunchy has support for:
* "switcher": copying the OS file instead of renaming it, allowing for OS 3.2/3.1, 3.3/3.1 and 3.6/3.1 switching packs (see TI-Planet);
* more OS versions;
* automatic overclocking on newer OS versions, in order to partially undo the speed damage done by TI;
* etc.
It also prevents a stupid way to get rid of nLaunchy from working.
The only proper way to get a calculator ready for testing is to erase all memory contents through the maintenance menu and to reflash it right in the exam testing room. Anything less than that is a leaky half-measure, if less costly, and will crap up at some point. Needless to say, when reflashing calculators right in the exam testing room is implemented, an OS tailored to any exam testing's needs can be reflashed, and the need for CAS / non-CAS difference, PTT, and suchlike artificial limitations, is removed.
12
« on: November 14, 2013, 02:13:32 am »
Thanks.
3: in fact, the calculator produces only PNG images, and one needs to enter 8, 9, 10 or 11 to get screenshots in two resolutions and color depths (all of which need unimplemented color conversion). But only the source code tells that story...
6: could you send me the "trace.txt" file which was created in the same folder ?
Lack of user feedback about operations which are longer than a second or two is a major utilisability no-no, but I haven't implemented any form of progress callbacks yet. When I do, the callback system will be different from that of upstream (EDIT: I mean libticalcs).
Finally, backuping a calculator is slow, due to HID being slow, I can't do anything about that.
In fact, test_hpcalcs is only a test client (derived from test_ticalcs_2), aimed at making small tests and showing how to use the library's functions. If it were to stay the only user-facing tool, it would badly need some documentation indeed. The library aims at being the backend for higher-level GUI and CLI tools; I just hope someone will take on the task of writing a GUI for a backend which largely works...
Offline, I have started implementing error messages and i18n, but I don't think i18n actually works yet, and I think I know why.
13
« on: November 12, 2013, 01:36:47 am »
Most Linux distros have some form of program for creating root file systems. On Debian, for instance, it's debootstrap. IIRC, I posted a howto for debootstrap somewhere in the TI community.
14
« on: November 12, 2013, 01:35:37 am »
The oldest Clickpad hardware revisions had an external NOR Flash chip (like the Clickpad prototypes), and an easy hardware modification makes it possible to tamper with the boot1 in arbitrary ways. There aren't that many such calculators, of course.
On the other models, we cannot make our own boot2, it's signed by RSA keys far too hard to factor (beyond the current state of the art by the leading researchers of the field equipped with public research grid infrastructure) and checked by a boot1 we cannot modify (AFAWCT), nobody published any boot1 exploits.
Arbitrary code execution vulnerabilities in the boot2 make it possible to do nLaunch / nLaunch CX / nLaunchy, though.
15
« on: November 12, 2013, 01:29:06 am »
The third generation of Ndless (Ndless 3.1 targeting OS 3.1) and nLaunch / nLaunch CX / nLaunchy (targeting boot2 1.4 on Clickpad/Touchpad like DowngradeFix and boot2 3.10.16 on CX) exploit the same vulnerability, but Clickpad/Touchpad boot2 3.1.131 and OS 3.2.0.1212 to 3.6.0.546 are not vulnerable to that hole.
|
Show Posts