I'm glad that you posted this, Hayleia, and luckily I have (what I think are) good answers to all but one of your points. Let me also remind you that this is Cemetech, and that "your opinions" are more than welcome; I'm not going to get personally offended just because you have problems with one of my projects, even if you were to hate it altogether. With that said, I'm happy that despite your concerns, you use it anyway and give it to all of your friends. :)
(Hayleia, not to be a pain, but the avatar size limit is 80x80; would you mind a slight scale-down? :)
Anyway, addressing your points!
First problem: automatic writeback.
A fair point. The idea behind Intelligent Writeback is that programs are only written back if they need to be, namely, if anything inside them has changed that needs to be stored. Ideally, programs that perform writeback are only doing so because they need to; if they're using themselves as temporary variables, I generally maintain that they should instead be using safeRAM for that purpose. Needless to say, not every programmer agrees with me on that, and this has been suggested to me in the past. Since I have on the order of 3 bytes free (actually, I managed to get it to 80 bytes, but that will go towards bug fixes, more on that later) in the entire Doors CS app, jam-packed as it is, I don't have the space to add an option to disable writeback entirely, sadly.
That means Garbage collecting everytime I use a big program on my 83+ (on my 84+ it doesn't matter). I am not talking about games, but math programs on tests, when I don't have the time to Garbage Collect each time I quit.
I know there is already Intelligent writeback but I'd like the option "no writeback" too, or "ask if writeback".
Also, we're talking ASM, not BASIC, right? Because BASIC programs don't get written back at all, just copied to RAM and then deleted.
-Another problem is the speed when lauching or quitting a program but I think there is nothing to do here. I'd like to pursue this one further; I generally find it quite fast, so I'd love to see a specific case of this slowdown to try to track it down. Any particular circumstances that seem to make it slow? Quitting, for example, is only slow if writeback needs to occur, otherwise it's instantaneous. So yeah, more details to help me track this down would be appreciated.
-The last one: its size. It is huge. Once again, on my 84+ I don't mind about 3 pages or ROM but on my 83+ (and on my friends' 83+ Razz (yes, I diffused DoorsCS to all of my classmates who own 83+s)), every byte counts. Actually, I mostly use TI-83+ calculators, and I maintain that Doors CS is a perfect shell for such calculators; let me debate it out with you if you disagree, as I'd be very happy to hear some counter-arguments. I consider Doors CS as an app that replaces so many other apps that you actually end up saving space (if you had those other apps). It can replace:
:: MirageOS, CrunchyOS, and your other app shells, since it executes just about every program available and does it more stably and less buggily than its competitors, especially the (in my experience) surprisingly unstable MirageOS
:: xLIB, PicArc, Omnicalc, and Celtic III: If you use any hybrid BASIC programs, Doors CS has all the libraries built-in; I decided to built all these libraries into Doors CS rather than hooking into a separate app for them, because it left me many KB in which to fit a whole bunch of cool Doors CS libraries, such as the much-requested ability to use the Doors CS GUI system from BASIC programs
:: NoShell: HomeRun to the rescue!
Besides all of this, I generally argue that Doors CS's size is a sort of amortization of the programs it runs, making them much smaller. For example, Document DE 6 contained a full GUI, the ability to open and write files in RAM and archive in a sane and safe manner, and full small-font file editing capabilities, all in 800 bytes. How? Because much of that capability is built into Doors CS, of course, so if you want to make your own editor, perhaps something that lets you edit BASIC programs on the fly, or a web browser that implements text input fields, or anything along those lines, you can just plug in all the routines Doors CS provides.
Also, to show that I've spent many, many, many hours painfully optimizing in pass after pass after pass, here's how the space breaks down:
So this is pretty evenly distributed between tons of code to manipulate the VAT in interesting ways (detecttype, vatfind, progchain), execute Associated Program system (ap), run programs (runprog, basicprg), do failure recovery (fldsv), network (calcnet), and handle the main desktop (main, dcslibsp, mouse_p0).
> Page 0: vectors.asm is 1140 bytes long
> Page 0: ionlibsp0.inc is 630 bytes long
> Page 0: dcslibsp.inc is 1102 bytes long
> Page 0: fonts.inc is 1110 bytes long
> Page 0: basicprg.inc is 425 bytes long
> Page 0: detecttype.inc is 600 bytes long
> Page 0: vatfind.asm is 583 bytes long
> Page 0: runprog.asm is 2182 bytes long
> Page 0: progchain.asm is 224 bytes long
> Page 0: calcnet22.asm is 1332 bytes long
> Page 0: ap.asm is 244 bytes long
> Page 0: easteregg.asm is 509 bytes long
> Page 0: mouse_p0.asm is 640 bytes long
> Page 0: fldsv.asm is 478 bytes long
> Page 0: main.asm is 5017 bytes long
The bulk of this page is GUI stuff and libraries. We have the MOS libs, GUI backend fun (apguis, propstring, guimouse, guitools), more GUI frontend fun (startmenu, mouse_p1), the sorting routine, the custom BASIC editor routines, and of course all the sprites and other data needed.
> Page 1: moslibs.asm is 1556 bytes long
> Page 1: ionlibsp1.inc is 511 bytes long
> Page 1: guitools.inc is 2624 bytes long
> Page 1: guimouse.asm is 4232 bytes long
> Page 1: mouse_p1.asm is 684 bytes long
> Page 1: startmenu.inc is 1313 bytes long
> Page 1: cedit.asm is 431 bytes long
> Page 1: apguis.asm is 1784 bytes long
> Page 1: propstring.asm is 66 bytes long
> Page 1: sortalph.inc is 431 bytes long
> Page 1: datap1.inc is 2702 bytes long
Mostly BASIC libraries (all the c3 stuff, the DCSB libs) plus the HomeRun and other ParserHook features.
> Page 2: vectorsp3.asm is 24 bytes long
> Page 2: ionlibsp2.inc is 630 bytes long
> Page 2: parserhook.inc is 228 bytes long
> Page 2: c3_hook.asm is 1047 bytes long
> Page 2: c3_std.asm is 1021 bytes long
> Page 2: c3_util.asm is 3481 bytes long
> Page 2: c3_xfn.asm is 2477 bytes long
> Page 2: c3_pfn.asm is 1634 bytes long
> Page 2: c3_cfn.asm is 2716 bytes long
> Page 2: dcsblibs.asm is 2855 bytes long
Page 0 is 16347 bytes long (37 bytes to spare)
Page 1 is 16337 bytes long (47 bytes to spare)
Page 2 is 16122 bytes long (262 bytes to spare)
Because of the speed concerns of routines and subsystems that span pages, I'm saving the 262 bytes on Page 2 for features and fixes that concern Hybrid libraries and HomeRun features (cf. ParserHook.inc). That leaves 37+47 bytes = 84 bytes (up from 2+1 = 3 bytes!) for the Doors CS 7.2 bugfixes listed here: DCS7 Scratchwork/Bugs plus gCn fixes for DCS 7.2. Also, if you want to see the effort that I've put into tracking down and fixing bugs people have reported, scroll down that page a bit. :)
→ A solution could be to have a lite version of DoorsCS that would only include the essentials (the libs, the homerun hook, the writeback option Razz ...) in the form of a hook installer, with a really simple GUI, exactly like Omnicalc, all that in only one or two pages of Flash.
Unsurprisingly, this has been suggested several times before. If I ripped out all of the hybrid BASIC libraries, CALCnet, and perhaps my custom font routine that makes Doors CS and its programs somewhat faster, I could fit DCS into two pages. However, I'm loath to remove any features that would make canonical Doors CS programs, BASIC or ASM, not work right. If I wanted to fit it into one page, I would have to also toss out all of the GUI API stuff, which I am even more loath to do. Actually, thinking about the first option is not as bad as I have thought it might be in the past, but I'm still quite resistant to the idea due to either logic, stubbornness, or some cross between the two.
Of course, locking/unlocking progs (for example) would no longer be allowed in that version