At first, I didn't want to make that topic, because, in my opinion, it is too much "my opinion". But Kerm poked me to do it, so I do it.
Also note that I am a Cemetech newbie and that maybe some things I'll say will seem stupid/already-said/useless/etc (I'm still not used to the menus and all), so if what I propose is already done, please not insult me but just give me a link
Also excuse my grammar/spelling fails : I am French.
And the last thing before I start , I think that DoorsCS is awesome, even after what I'm going to write.

-First problem: automatic writeback.
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".

-Another problem is the speed when lauching or quitting a program but I think there is nothing to do here.

-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+ (yes, I diffused DoorsCS to all of my classmates who own 83+s)), every byte counts.
→ 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 ...) 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.
Of course, locking/unlocking progs (for example) would no longer be allowed in that version

Yes, I agree with all of this. DoorsCS appears to be optimized for the large Archive of 84 Plus systems. Automatic writeback, speed, and reduced size would all be appreciated from the 83 Plus standpoint (that used to be my device of choice).

I think it's great to write constructive feedback, Hayleia, even if it's already been said somewhere else. Please remember to introduce yourself and add an avatar to your profile!

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

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.

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.

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:


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


Code:
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.


Code:
Mostly BASIC libraries (all the c3 stuff, the DCSB libs) plus the HomeRun and other ParserHook features.


Code:

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

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.

(Avatar's size changed, sorry for the inconvenience)
(Once again, the following could include grammar or spelling fails)

And sorry for the delay before the answer, it took me 10 minutes to read your post (jk)

-For the writeback.
It is sad you can't add this option (even if not a lot of big programs need writeback). Nevertheless, that was not the most important of my points/requests/whatever. That would just have been the cherry on the cake
And yes, we are talking about ASM. I made some kind of a math program (in Axe, so compiled in ASM) that I used to use a lot last year.

-For the speed.

??? My Pokemon game doesn't need writeback and it takes 7 seconds to quit (it is 21364 bytes). Same for DoodleJump that takes 5 seconds (it is 15833 bytes).
Well except the fact that the more the program is large, the longer it takes to quit (that may be normal, I guess), there is nothing particular.

-For the size.
(I wonder what easteregg does. "Happy hunting" says the manual.)
Of course, I have none of those apps now that I have DoorsCS and the Homerun hook is awesome. So yeah, in one way it saves space.
But the problem is not for me, but mostly for my classmates (not all of them) that don't use their calculators a lot but still need for some features. I mean that they are unable to use any GUI, and only need the hooks. I didn't mean to remove libs, but to remove the GUI, so they can run any prog with only one or two pages of ROM, and without (useful) functions that they will never use (even if I personally use them, like the ability to lock programs). And I really doubt that they will use CalcNet, as none of them has kept the linking cable (I don't know how they live without it).
In other words, DCS Lite would be more like a complete shell than like an awesome-multifunction-App-that-includes-shell, but that would be enough for my classmates.

Self-modifying code is one such example of cases where safeRAM is not particularly practical, especially in large programs. I suppose the best way to work around that would be to re-load the original program back into RAM to trick DoorsCS into thinking nothing has changed. Could you see any problem with that technique?

Then as Benryves points out, the culprit is probably some SMC routines in Axe that, for space, don't clean up after themselves. I've considered only writing back changes that occur in the last NNN bytes of the program, to avoid that sort of problem, but that's an artificial construct on programmers too, so I don't love it. Ben, the problem, as you point out, is that for RAM programs Doors CS (and other shells) move the program rather than copy it, but of course that's only a problem for RAM programs, but then again, how would the program know if it was run from RAM or Flash without chkfindsym'ing itself? Sounds like a mess either way. I think we're all on the same page that SMC is the problem here, and that there's no elegant solution either way. I agree that the easiest way out would be a "disable writeback" checkbox somewhere. :/

I'll admit, that's one luxury I allow myself. I removed the music from the Easter Egg and simplified it a lot, so even that is now half its original size.

Indeed, I figured that that was more or less what you had in mind. Unfortunately, the actual frontend GUI that you see when you run the DoorsCS7 app from the Applications menu is a very small part of the app's size, once you get right down to it. A far bigger bulk is the underlying GUI API subsystem, without which tons of Doors CS programs (including almost every ASM program for Doors CS I've written in the last three or four years) would not work. I could probably come up with a decent two-page alternative by removing the BASIC libraries, but I wouldn't be super-happy about it.

I'll be honest, I'm considering a two-page version more than I have in a long time, but I'm still resistant to the idea of diluting Doors CS's brand with a stripped-down version.

You've gotten far too many requests for a lite version of DCS that I don't think you can put if off any longer.

I think building the lite version would be a prime time to show off Shell Expansions. Of course, built checks when a user runs a program that uses a lib. If the lib isn't there (via a SE) then prompt the user to download the SE or upgrade to the full-featured version.

SE's could be the libs, the GUI routines, gCn, etc.

I hear what you're saying, but the way that shell expansions are written wouldn't work for those features. One thing that WOULD be cool would be to make those into ALEs (Appended Library Extensions), which could be dynamically loaded when a specific feature was requested. Currently ALEs must be pre-specified by programs, and don't cover any of the built-in features. I'll try to remain open-minded about the possibility of this; let me also remind everyone the deficit I'm already running on my free time between Cemetech, Sandpaper, my book, and most importantly, my professional research and schoolwork.

Whoa, let's not throw Axe under the bus just yet. To the best of my knowledge, Axe does not use any SMC in its routines, so I doubt if that's the culprit. My guess is that Hayleia has a lot of programs on his calc so his VAT is cluttered. Perhaps he could try turning the option to alphabetically sort programs off and see if that makes any difference.

No worries, perhaps a formal announcement with a lack of date would suffice. Just something that says it will happen, just after current projects are completed, and leave out a date do you don't break expectations.

I'm not throwing it under the bus, I'm using the facts presented. If (1) an Axe program is run from Flash, (2) the hourglass is displayed after it runs, indicating Doors CS is performing writeback, and (3) the quit-time-to-desktop scales roughly with the size of the program being exited, then clearly the contents of the program changed while it ran. Since Hayleia does not believe the program performed any intentional writeback, that leaves (a) corruption or (b) SMC. The fullness or emptiness of the VAT does not affect writeback, although you make the good point that if the lag is after the hourglass disappears, then it's probably something like sorting rather than writeback. It didn't sound to me as if that was the case, hence my conclusion of SMC. But if it is after the hourglass disappears, then by all means try turning off sorting. I reiterate that the following led me to doubt sorting:


Comic, aye, but I'm not 100% convinced about the project either, yet; while there have been several people who have requested it, the vast majority either grin and bear it, or presumably don't use Doors CS at all, so to have two versions of Doors CS floating around to muddy the waters makes me apprehensive. FYI: did you know that Doors CS used to come in a smaller Standard and a large Professional edition? According the the Doors CS Version History, the two were merged with Doors CS 5.4.0 Beta 2:

As long as we're having an open forum for DCS criticism, I have a question: Kerm, what drove you to use the mouse-based UI instead of a menu system? Overall, it seems like controlling the mouse with the cursor keys is simply slower that navigating through a menu. It's largely a moot point with TabFuncs and the 1-6 keyboard shortcuts, but I can't help but think how difficult that UI was to design and code, with, at least at first glance, no discernible benefit.

I'd be interested to know, as I know there has to be some reason.

I was always under the impression that the shell was originally made for people who were: a) fed up with MirageOS' odd keys for making folders, changing names, etc, b) never use a calculator and want something familiar. To most people, using a mouse to move around the screen and click buttons is very intuitive; it's the same thing that their computer's OS does. Also, it was called "Doors CS" as a play on "Windows OS", and since Windows uses mice, has folders, runs programs, and has ways to use libraries and extend the OS/shell, so does Doors CS. At least, that's what I've always thought about it.

That moves the problem onto the user, and a lot of games require writeback so asking the user to remember which games do or do not so they can set the checkbox appropriately before playing a game sounds a little inelegant (unless you intend to add a Windows-style set of "compatibility" options for each program). I think this should be something that a developer can add to their program.

The simplest way I can currently think of would be to set a system flag to a silly (but benign) value when exiting - for example, setting donePrgm in doneFlags. It would need to be a flag that is unlikely to be set accidentally (donePrgm should have no effect for programs run a shell, so there's no good reason to use it), but a flag that would not have any negative side-effects otherwise. Doors CS could then check the flag when the program exits and if it's "silly" change it back to "sensible" and not perform writeback.

Edit: Learn the difference between effect and affect.

I meant a shell-wide way to disable writeback, but that's just as awkward as having a per-game writeback disabling function, I guess. If I understand your main suggestion correctly, this would be a fairly elegant way for future programs to specify whether they desire writeback or not, which I think is a great idea. I'd have to get people like Quigibo to agree to using the convention, but it could be a good solution for up and coming programs. Unfortunately, it still doesn't solve the issue of existing programs, but based on this discussion, I'm not entirely sure there is a solution;.

Ah, okay, that makes sense. I didn't know the hourglass only indicated if the program was writing itself back or not - I thought there was other stuff there as well.

Perhaps a GarbageCollect'll speed it up.

Perhaps. But the problem remains tracking down why Hayleia's Axe programs appear to Doors CS to need writeback at all. Any chance someone could poke Quigibo to take a look at this topic when you see him next?

Cross-posting this since it was reported as a bug:

Axe does not use any SMC in the program itself because this is a required invariant of the language in order to ensure things optimize correctly. The only SMC it uses is to modify some free RAM that is executed over when an interrupt occurs (which has nothing to do with writeback).

Judging by the size of the mentioned programs, they are both well over the 8kb limit meaning they are using Crabcake or Fullerene, both of which I think use SMC, but you'd have to double check that. So it appears to be the Axioms that are the culprits.

Kerm, if you decide on a header convention (preferably the same size as the current one) I'd be happy to add a "DCS no-writeback" compile option.

Compiled Axe programs don't use SMC exactly. No executable code is ever modified, but Axe does allow for data to be modified. It is common for Axe programmers to allocate buffers inside their program for temporary storage (e.g. a buffer image) that doesn't need to be saved between executions. I'm guessing this is why DoorsCS thinks that these programs require writeback, because the data in temporary storage buffers was changed.

I was reluctant to suggest a header option as that would limit the tweak to DoorsCS programs (admittedly this feature would be DoorsCS-specific, but if we could get away with running the same executable in MirageOS otherwise I think it saves the hassle of having to release multiple versions of a program).