About sticking libraries in SEs: I think that since everything will have to be ported from scratch and all of the legacy requirements will be thrown out, we can totally support this by making the dependency requirements part of the program header: a program that doesn't have a particular dependency simply won't run by DCS, without the program having to do this check itself.

Of course, I don't know if we can feasibly support multiple dependencies or chained dependencies. I can think of two ways to do this:
1. Dynamically allocate all the dependencies. This would allow all the systems to be easily organized, but all programs could only support relative jumps - not even any calls except on subdependencies.
2. Load all the subroutines the program calls for (including core subroutines) into an extra RAM page and map it to $4000. The beginning of the page contains a jump table that references all the other programs. The beginning of each subroutine also contains a list of where all of its subroutines are in the jump table. To illustrate:

Code:

This, of course, would limit a program to only 16K of libraries, including the jump table. However, it would allow for calls.

What do you think? Do I even remotely make sense?

I think 16x16 should be -the- size. While having varying sizes might be nice, honestly, it makes things look less uniform. And this way, you could offer the size difference in Doors itself. If they want normal icons, 16x16, if they want large icons, 32x32. Do you plan to add a list view, like Crunchy/Mirage has? I don't know if that would add a lot of code or not. That way, it would appease many more people.

I second this. Shell Expansions are poorly under used. It'd be awesome if you could promote DCS8 as a one page app and offer users extra libraries in shell expansions. Letting other people create SE's with libraries of their own would be super beneficial as well - the key ones or CIII, xLib, PicArc & Omnicalc. Of course the DCSB Library would be a built-in standard. The key libraries on the TI83+ line aren't going to be heavily utilized so I think stripping those features out and creating a SE for each one, or fitting them into one, would be awesome (and to reiterate) create awareness for SE's.

tifreak, I was even considering 32x32, color icons for ASM programs, but if you do the math, that would be 2*32*32=2KB just for the icon, which is not a good idea. Another option would be 4-bit 32*32 icons, which is still 512 bytes of icon. A 16*16 4-bit color icon would be 128 bytes, which I think most ASM programmers would probably be willing to spare. The question remains if I should scale them up to 32x32, though. With 32x32 (scaled) icons, each program's name+icon could be up to 32+10+4=46-ish pixels tall, and 8*8=64 pixels wide. That would mean a Doors CS desktop that cold fit 4 icons vertically and about 4 icons horizontally.

That's way too few icons for the desktop, I think it's best to mock out the icons on a canvas the size of the screen and see what works best. I think 8x8 would be incredibly small and 16x16 would be more appropriate. You could allow 32x32 icons in headers, but make the default 16x16 and allow users to either increase or decrease icon sizes.

Kerm, please increase the size of the app significantly. It'll be okay with the new calc. It'll give you room to do things, and you can optimize later in updates. Please make it... more compatible. And less intrusive. It pretty much takes over the calculator,

Better yet, just write the first picture viewer or a USB MSD browser.

But here's the thing: that bigger ROM is more than complemented with a more RAM-consuming screen, which will make everything else bigger. While having a lot of well-written features is good, most people don't use them all, so having modular parts is much more important, which is what we're talking about by having SEs be libraries.

I thought it was already incredibly compatible. See below. Also, can you elaborate?

What do you want? More compatibility or less intrusions? It takes over the calculator because there are parser hooks to catch the use of library commands when programs are ran from the home screen, a key hook to instantly launch DCS without selecting the App. There's also other hooks installed if I'm not mistaken.

I've always had DCS on all of my calculators, and the only intrusion I've ever felt from it was having ALPHA work with lowercase too, which is a good thing.

That might even be a settable thing, if I recall. With HomeRun, it's actually the least-intrusive shell possible.

As far as size goes, I'm not going to be going out of my way to make this (for example) a one-page App; I think that's orthogonal to Doors CS's goal of being the "ultimate" calculator shell. Some of that requires features for niche users and coders (the GUI API, CALCnet), pieces also require plenty of eye-candy. Compynerd makes the excellent point that high-resolution and color are going to make graphics inside and outside Doors CS larger and more CPU- and space-intensive. That's something I'm going to need to balance with more visually-appealing GUIs.

You think that 4 icons by 4 icons is too small? I'm not sure I agree with you on that, considering it's 3 times as many as Doors CS currently shows.

Id be more inclined to side with the 8x8 (scaled) icon idea for BASIC programs as well. Since on-calc to begin with there are only 15 colours available on the graph screen it might be an idea to keep those colours as standard for BASIC icons? Are coloured icons needed at all?

I suspect that BASIC programmers might want the eye candy. 64 hexadecimal digits is the same length of the current 16x16 DCS icon for BASIC programs, so an 8x8 color icon seems reasonable to me. Perhaps we should standardize BASIC program headers the way we're standardizing ASM headers?

Oops, I misread that as 4 icons.

I think compynerds post is pretty much the best idea; the best way to easy adoption of a standard is to be open. Thinking years down the road when Kerm may not have the time to maintain DCS8 with any new popular routines, some developer would be able to add that support into DCS through an SE or migrate to a shell that does. While I acknowledge DCS8 will not feasibly fit in 1 page, the goal of making it as few pages as possible will ease people upgrading from the TI-83+. At least those who aren't aware of the extra App pages.

You can gloat and mention all the features you want but people have weird habits. I for one, don't download or purchase anything that doesn't have a pretty GUI. Then comes function. Basically, you can't appease everyone with features & functions alone. Some people might "shop" by the number of pages and then features and I think it'd be awesome if we can appease both by showing off a small size and a wonderful feature for extendability at the same time.

If someone wants a lightweight shell, they have it. If they don't then they can download Shell Expansions for DCS.

Personally, I think it'd be amazing to throw out a purely minimalistic shell that supports SE's for everything. For instance, ship out DCS8 with the core as the backend/app and the GUI can be an SE. You'd break some familiarity but you'd open yourself to a whole flood of developer support as well. The more developers you get interested in DCS the more support and life it'll have. It'll be similar to Linux, sadly in the bad ways as well, while it's likely we won't end up with "flavors" of DCS floating about.

You also need to go about this so that it's easy to diagnose issues and bugs. If someone comes running to Cemetech because of a graphical glitch, it'll likely be the fault of the GUI developer. Creating DCS8 to support wide adoption and developer support while also maintaining quality is imperative. However it's accomplished in the end is fantastic but I firmly believe the best way to meet this initiative is to promote Shell Expansions.

The amount of things that can be altered and amended through an SE is up to you, of course.

Implement a package manager with dependency resolution.

That seems reasonable enough. I don't want the Doors CS core to be more than one piece that people load onto their calculator, as that would put a big hit in calculator-to-calculator transfers. People wouldn't realize they had to transfer other pieces and get frustrated.

Doors CS has always been aimed at users who want a lot of features and worry less about weight, but that's not to say it's not a change of attitude that I'm willing to reconsider.

I agree; I'm just not totally convinced (nor am I convinced otherwise) that Doors CS is the shell to do that. That part is very important. The more program are dependent on Doors CS, the more Doors CS is going to proliferate.

I hear your conviction on that. I definitely agree whole-heartedly with the bolded statement: DCS7 has become known for its completeness and especially stability, and I'd like to maintain that.

You == me or you == programmers?

Why, thanks. I doubt that either solution I came up with will work by itself since 1 page isn't going to be enough and the $C000 execution limit still works. I bet we'll come up with some way to integrate all the libraries a program wants to use, or else we'll end up with all those "flavors" of DCS like you were describing. Perhaps page switching through all that RAM we've got.

Well, it should be noted that I discovered pages R:04 through R:07 are used for graph buffers, two for the foreground and two for the background. So we don't have quite as much RAM as you might think.

Well at least we have graph buffers. And we could probably destroy the foreground one safely as long as we notify the user that we're going to do so.

Yes. The flags that control whether the foreground and background are marked dirty or not have not yet been discovered, but I'm confident that we'll manage to track them down.

I'd agree that a minimal core is one of the best things you could do, though that's not to say you shouldn't include a set of libraries as standard.

If we're in a position to discard many existing conventions, I think it makes sense to effectively specify a way in which shells act like dynamic linkers, allowing the programmer to specify a set of shared libraries to link against.

The biggest problem here is that there may be a non-negligible amount of library call overhead, since library code is not feasibly relocatable in most cases (and disallowing relocation automatically makes some sets of libraries mutually exclusive). Thus we need to place trampolines somewhere in memory, or have a single entry point that takes a parameter identifying the function to call (just like bcalls do).