Ok, I'll add that, but first I need to get unpacking to work.

Ah, indeed. What are your current stumbling blocks to that?

I still haven't decided on the structure of the archives.

Well, what are the things you've considered? You'll at least need the type of each item, the size of each item, the name of each item, and then the contents, correct?

Yes, and the password (if any), and possibly some other information.

So something like this, maybe?

Header:
- Total number of items in installer
- Password, if any
- Name of folder for unpacking
- [ITEMS]

Item:
- Type of item
- Size of item
- Name of item
- Contents of item

If you do this in this format, you will get a long, complicated word stuck in your head. It is called "length-prepended". When I was working on my antivirus's install routines, Kerm drilled that word so far into my head, it came out the other side. lol

All joking aside, this will package all variables needed for a program and the program into a larger program correct? If so, you will need to scan the program to find exactly what stuff it uses. And, you will need to convert the main program into data, as that is what it should be saved as in the archive, then you will need a little bit of code at the beginning of the archive, that when u run it, it unpackages the archive. Or are you going to have your own program do the unpacking. It may be cool, if not now, in the future, to have the archive itself able to unpack. That way, if i send to a friend's calc, the wont need your program to be able to unpack items.

Are you following me, or am I rambling too much?

No, that makes perfect sense. I'm sure he intends to have the archive itself executable with the unpacking code at the beginning, and then have that program be able to delete itself when it's finished unpacking. I thought of another flag you'll probably want on a per-item basis: whether that item should be in RAM or archive.

Umm, no. The only executable part of the archive will run my main program to "unzip" the archive. The unpacking will not be inside the archive, it would waste a lot of memory (adding ~1500 bytes of unpacking code to an already giant archive doesn't sound very memory efficient). I might have it be able to unzip itself in the future. The archive will be deleted after the unzipping, unless the user chooses otherwise.

Kerm, flag added.

It might not be memory-efficient in the short run, but once you consider that after the archive is unpacked it can be deleted it doesn't seem so bad to me. On the other hand, if you keep the 1.5KB installer in RAM and the archive file containing all the items to be unpacked in Archive while you unpack, and read from Flash, then you can have much larger items in the archive.

That sounds like a good idea . But how would I read from Flash considering the unzipper is a Basic/Asm hybrid?

Well, for one thing, the Celtic III routines in Doors CS have no trouble reading from Flash. If that's insufficient, it would be easy to collaborate on some ASM to take care of it.

to elaborate on what Kerm said,

Celtic III, or any asm library for that matter, or pure asm can read from the Flash directly no problem. The issue is writing to it.


Edit: I just repeated exactly what he said. Fail for me.

Well, you mentioned how challenging it is to write to flash compared with reading from it, which I didn't mention.

I'm pretty sure Axe can do both, but it doesn't interact with DCS7 very efficiently.

Axe can read from the Flash, so data for Axe progs does not need be moved into RAM before usage. However, there is no way to write to Flash except creating the variable in RAM, then using the Archive [var] command.

As for DCS7, I'm a little PO'd by its inability to use DCS functions. I would suggest that either Kerm Martian make an Axe set of commands for DCS or that Quigibo provide DCS commands in a later version of the parser. There is one thing, though.

I believe, though I don't remember where I found it, that you can, using a special Axe header, get the program to display a custom icon image in DCS. But, you must have the special header and compile to a Mirage OS program in order for it to work.

Could you post an example program to do that?

To do what? Write to or read from?

By Axe's inability to use DCS functions, you mean? There's something called Axioms that theoretically expose ASM libraries such as DCS libs to Axe programmers, but despite my cries of help for someone to either teach me how to make them or to write DCS Axioms themselves, no one has yet stepped forward.

@ souvik: Here's both



Code:


This may have slight technical issues, but thats the idea.

to write to flash:

see lines 4 + 5 above. The appvar is created in RAM and moved to archive, then read directly from archive.


@ Kerm: Axe programmers do not have access to any of the asm GUI libraries that you coded in DCS.