A progress bar?  Sure, that would be easy enough to do.  I guess I should point out, though, there are two distinct parts to app signing: MD5 hashing, and the Rabin algorithm or "signing" proper.  The MD5 calculation takes time proportional to the size of the application, and will be significantly faster on an 83+ SE or 84+ due to hardware acceleration (I'm not sure about the Nspire, but it's probably comparable to the 84+.)  The Rabin algorithm, in contrast, will take almost exactly the same amount of CPU time regardless of the application.  So the two parts aren't directly comparable.

OK, I was just joking.  I wasn't really expecting Quigibo to have thought of that, just trying to point out, in a slightly facetious way, that it would have been nice if he had.

Like I said over in the Mimas thread, I've been experimenting a bit to see how practical it would be to sign apps on the calculator.  So I figured I'd take a look at how Axe generates applications.

(App signing on the calc is never going to be instantaneous (except maybe on the Nspire in ARM mode), so you probably don't want to do it every time you build an app, but it would be nice to have it as an option when you want to distribute your app to others.)

Thus, a few points:
1. It seems that when Axe generates an app, the "signature" is filled with zeroes.  It would make life a lot easier, from my perspective, if you used FF bytes instead (and since the signature is invalid either way, it shouldn't matter what you put there initially.)

2. App signatures on the 83+ must begin with the bytes 02 2D 40 (followed by 66 bytes of data), not 02 0D (the latter is used for OS signatures as well as for app signatures on the 89/92+.)

3. Does Axe deal with the 55-mod-64 bug?  (An application must not be exactly 55 bytes long mod 64; if it is, it can't be installed on a TI-73 or 83+ BE due to a bug in the boot code.  So if an app is 55 bytes mod 64, RabbitSign will add an extra byte to the end, and increase the app length field accordingly.  This would be easy to do at the time the app is compiled, and hard to do later.)

4. Only tangentially related to app signing, but does Axe deal with the FF-at-the-start-of-a-page bug?  (If you have FF at the beginning of any app page, the OS will set the entire page to FFs when apps get defragmented.  I wrote a program to patch the OS and fix this bug, but it's best to avoid that if at all possible.)

Well, it's somewhat theoretical at this point; I'm still working out the bugs in the math routines.  But apart from the hyper-optimized multiplication and remainder code, the only real trick is pre-calculating as much as you can (e.g., pre-calculating the pseudo-square-roots of 2.)

SirCmpwn, I apologize for my earlier comment.  It came out somewhat harsher than I intended.  Looking at the zip file you linked me to, it does appear to include a number of other people's programs (mine, BrandonW's, Wabbitemu, PindurTI...), and I don't see any source anywhere.  It also appears to include TASM, which is very much non-free.  If you're going to use Sourceforge, you know, one of the rules is that you're supposed to release the source code at the same time as the binaries.  And copyright issues aside, I personally would appreciate a little bit of credit when you distribute my programs.  That's all I'm going to say on the matter.

Quote from: FloppusMaximus on October 11, 2010, 07:27:18 pm

Will do.  I always keep backup copies of the old versions of my programs, in case I ever need to know what was changed when.

You know, TI Developer does that for you

I think I'll stick with what works for me.  I probably should start using a VCS, though.

(Also, uh... is that a giant bundle of Windows binaries, all with different licenses, some free software, some not, none with source code, and not even a readme file to tell you where they all come from?)

Correct me if I'm wrong, but I believe BrandonW's re-signing program is only for signing OSes, not apps.  App signing uses the Rabin algorithm, which is substantially faster than RSA if implemented correctly.

Creating apps with Mimas is certainly doable, but would involve a fair amount of code (and multipage apps even more so.)  So the eternal question is, how much is it worth in terms of code size?  Like I said in my initial post on UTI, I'm already pushing the limits of what a 2-page application can do; would it be better to increase this to 3 or even 4 pages (and include all the incredible features I can think of), or would it be better to keep it smaller and simpler, so that it's still reasonably usable on the 83+ BE?  Or would it be better for me to try to implement extra features as plugins?

(By the way, I guess I should mention that you can already create single-page applications with Mimas... you'd just need an external tool to install them into Flash.)

Oh, and no, Mimas can't assemble itself (not yet, anyway), due to the lack of macros.  And of course the fact that you don't have enough RAM to store the entire thing.

Yes, at the very least I'll release a new version this weekend with a few bug fixes.

I wasn't really thinking very hard about the version number, but you can read 0.1 as "hasn't been completely tested" (it has been tested quite a bit, but it's also a rather large and complex program!) and "internals may be subject to change."  (It's possible that I'll need to make incompatible changes to the file formats, so you won't be able to use newer files with the older assembler.  Of course, I'll do my best to support older files with each new version of the assembler.)