There is a fair amount of FlashROM on the 84C so i cant imagine the app being a problem for too many people. It can be a bit a pain if you require users to build up different configurations of a shell to run certain programs, and there may be compatibility issues between modules. Still there are advantages to running a setup that way as well.

As tr1p1ea says, we have so much space that I'm not planning to bother with multiple types of Doors CS. Once upon a time Doors CS had a a Standard and a Pro edition, and it just led to confusion, even when the difference in features was relatively small. Since I'm starting over with a new set of libraries and have no immediate plans to build a CSE version of the GUI API, I don't see Doors CS 8 going over two pages anyway (if that).

Elfprince, I think that the polyglot header is probably the best idea at this point, but we also need to figure out how the rest of the header will be structured. I'm thinking something like a series of sections, each with the simple structure the follows:

Code:
It might also be nice to have a wrapper around the whole header with the size of the header and how many sections it contains.

Might be worth looking at implementation of some "real" executable/object/library file formats, and see what some of the possible pitfalls are, what can be adapted directly, and what is overkill for a platform of this nature.

That's an excellent idea. I think reading the ELF documentation would be a good start, for instance. Header fields we've talked about include icons, descriptions, dependencies, and memory requirements. I particularly like the idea of programs being able to specify how much memory they need for scratch space, since it would/will allow the shell to manage memory and prevent programs for having to coordinate safeRAM all by their lonesome. It would also greatly simplify writeback.

ELF can indeed be a source of concepts, but you shouldn't make something even remotely as complex.
FWIW, on the TI-68k series, there is a standard for embedding metadata, such as program name / version / author / icons in AMS native programs. GCC4TI produces programs complying with that standard. I can't find the text of the standard at the moment...

EDIT: "STANDARD FOR NOSTUB COMMENT AND OTHER EXPORTED STATIC DATA EXTENSIONS": http://members.chello.at/gerhard.kofler/kevin/ti89prog/dataex10.txt . I had enough trouble finding it again, despite being one of its authors, that I'm putting the title along the link, as it might help next time I'm seeking for it (if ever).

You should also allow them to specify what portions of their own body should be modified on writeback and what should be left "as-is". For example a program may use both SMC and keep an internal high score table. The high scores should be preserved, but the SMC changes should not.

*bump*
FACT: The Doors CS 7 codebase is huge and hard to maintain
FACT: Other than me, almost no one uses the GUI and CALCnet
FACT: I have no time
FACT: TI-84+CSE GUIs, graphics, sprites, etc are hard
FACT: Although the AP system is awesome and PC-like, only I and a few other coders use it.

It is resolved:
RESOLVED: Any TI-84+CSE Doors CS will not have a GUI API
RESOLVED: Any TI-84+CSE Doors CS will not offer CALCnet (for now)
RESOLVED: Any TI-84+CSE Doors CS will not have an AP subsystem, File Open/Save/Save As dialogs, and all that
RESOLVED: Any TI-84+CSE Doors CS will not suck up my time
RESOLVED: Any TI-84+CSE Doors CS will have neither a cursor nor a cursor editor
RESOLVED: Any TI-84+CSE Doors CS *WILL* have hook(s) or mods for the TI-BASIC editor to not make it so gol-darned slow, even if it's just to fix 2:Goto.
RESOLVED: Any TI-84+CSE Doors CS *WILL* offer TI-BASIC coders a sprite routine and a tilemap routine. It's up to you guys what form that will take. It's up to you guys if you also want a text routine and a line routine. If you don't tell me a thing you want, I won't read your mind, and I won't write it.
RESOLVED: Any TI-84+CSE Doors CS *WILL* offer some rudimentary ASM routines, like a sprite routine, a line routine, a random number routine, and a few other Ion-style helper calls.

Thoughts?

This is what I had trouble with with xLIB on the 83+. There are lots of 'custom features' that people were requesting that noone ended up using. In all it takes up code space and ultimately drastically affected performance.

I say stick with the basics and dont go overboard. Leave it open if you find inspiration to extend the featurelist in the future.

I like the fact that you have been decisive on this matter.

Trading breadth of features (GUI, CALCnet, AP, etc.) for speed of development (and quick availability for users of an initial 84+CSE shell) is a valid choice.
(as long as you don't make it hard to add these features later and thereby increase development time / make it unlikely that the features are added some day, but you have more software development experience than needed to plan the code base for future extensibility)

• A standardized open-with API would be incredibly handy even if you don't provide any GUI dialogs supporting it. Just a way to embed "pass my name and info to another program" in the header format.
  
• If you're dropping most of your library systems and UI, you should provide a good continuity with the shell extension system and a standardized linking mechanism for other people to provide libraries for assembly (and possibly BASIC) programmers.
  

Basically, what I'm saying is: if you're not going with a "build in the kitchen sink" design philosophy, you need to go with a well-planned system for extensibility.

Hey, I use the GUI and CALCnet, as do many other cemetechians. Having said that though, if you want to make the 'shell-de-jour' for the platform, you are going to have to omit the developer features in the first few releases. I say this because you will need to develop the software relatively quickly. Some other ASM programmers may have similar ideas for shells and may want to get there first.

If we take MOS and ION as an example, the average user isn't going to care about developer features (which is a shame, but equally a sign of the times ), and therefore the tools that they offer aren't really accessible to the BASIC programmer. In fact, many a pupil see their calculator as a games machine.

I'm only emphasizing this due to the huge turn of events in DCS8. No Mouse, GUI Routine, etc. Perhaps we can have a really good shell expansion support that will let others build that support in.

Thoughts? I hope a better shell than the proposed "DCS8" comes soon. I dissagree with nearly all of those points. And I find Fact #2 mildly offending.

And what do you make of AxeDCS ? Is it nothing ?

Well he never said that 'no-one' uses it, just that hardly anyone does, which is true.

Kerm has a very busy life and needs to prioritise his projects. For a first release the shell is indeed going to be barebones since the amount of effort needed to implement a full feature set is not available.

I can certainly understand where he is coming from.

Yeah, don't let's be dramatic. The sooner we get something out there the better, and if that means barebones at first then so be it.

Kerm: I can add more detail to what I'd like to see with the sprites etc. But I think tr1p has some good design for xlib. You two should work together. I'd also love to see it use openLib and ExecLib rather than hooks. A lot of elfprince's ideas have been great, too.

Lastly, text routine would be great. Supporting back and fore color, a way to measure a string, and maybe even custom fonts in appvars.

*facepalm* I didn't say no one uses them, I said hardly anyone. There are probably 20-30 coders who use those features, you guys included, versus thousands of programmers among the general public who have Doors CS on their calculators. Those special features have taken probably 60-70% of my total Doors CS development time, and while I'm very proud of them, they don't fit with a future shell that I develop while still keeping up with all the responsibilities I have in real life.

Shaun: I think so too. I will probably have about 4KB free for spritey things, so if tr1p1ea can jam some cool xLIB stuff into that space, I'd love to have his help.

I can certainly help out, xLIB at the moment is more of a test-bed for experimenting so hopefully i can get some good ideas out of it.

being that i dont see myself getting an 84C anytime soon, and that you have all sorts of projects allready stacked on top of regular life, id say that stripping DoorsCS to be simple would be a great launchpad for the 84C.

even if i will miss CalcNet.

I was also thinking, AssemblyBandit has been doing great work with IViewer and has even added OpenLib/ExecLib support. Perhaps he is able to contribute to the lib side of things as well?