I. Introduction: What?
Shell Expansions, or SEs, are modules for Doors CS. They are similar to the concept of Ion Modules, except that they are far more versatile. Shell Expansions can have one or more of three sections: Boot, Mouse, and Unload. A shell expansion with a Boot section is called while Doors CS is booting, before it counts programs and displays the desktop. Possible uses: load interrupts, set up hardware, sort programs, etc etc. Mouse sections are the most versatile: not only does Doors CS call them continuously while the mouse is active, they can actually interject actions into Doors CS itself. They can force mouse movement, clicking, and coordinate jumping via well-placed memory editing (not necessarily advocated). Finally, unload sections are, obviously, called while Doors CS is quitting, after it has closed down the GUI system but before it reverts to the TI-OS. Since a program can contain one or more of these sections, it can be anywhere from 768 byte to 2,304 bytes; each section can only be up to 768 bytes, since it must fit in SavesScreen.
II. Programming Detail: How?
Shell Expansions are currently loaded via an extremely inefficient system. When Doors CS first loads, it searches the VAT for programs that may be shell extensions, counting the number of shell extensions on the calculator but not making a note of which have boot, mouse, and unload sections. When the calculator reaches any of the three stages, it first checks to see if the SE count total is zero. If it is, it skips SE execution completely. If the variable is nonzero, it goes through an iterative loop, calling VATFind, Doors CS's most CPU-intensive routine, once for each of the Shell Extensions reportedly present. The VATFind routine searches through the VAT, counting the Shell Extensions it finds until the select one is found. It then checks if its vector table contains an entry for the calculator's current state (boot, mouse, or unload). If a relevant section is found in the selected Shell Extension, it copies it to RAM and then jumps to it.
Clearly, this is quite inefficient, because the entire VATFind system must be invoked each time an SE is executed, even if the specified SE does not have a relevant section for the current mode. However, this system does have its strenths. Because it does not store a table of SE locations anywhere, there is no inherent limit to the number of SEs on any system at a time, other than the 255-SE limit of using a byte to count. Secondly, it saves safe memory for programs for the same reason. However, by limiting the number of Shell Extensions on any system to, for example, eight, two major advantages could be attained:
1. The vector table could be consulted each time an SE event occured instead of needing to search through the VAT with VATFind once again
2. Additional memory, perhaps 2 bytes per SE, could be allocated to store important data in between executions.
With these changes, SEs would move closer to partial multithreading and away from the current rather cumbersome system.
III. Why?
As a programmer, why would you want to write your program as an SE rather than a full program? Well, not only would you have the programming challenge of fitting your entire program into 768, 1,536, or 2,304 bytes, you would have the advantage of interacting directly with the Doors CS kernel. Startup programs could directly set flags and options within Doors CS, or through some fancy programming, even prevent it from booting entirely (password protection, anyone?). Because Doors CS is now an app, SEs have access to each and every routine Doors CS has to offer to ASM programs, although it is not recommended that they mess with the GUI system, in case Doors CS itself is taking advantage of undocumented GUI API features. The mouse SEs are the crowning jewel of the SE system, for thety allow the programmer full control over cursor movement, cursor clicking, and even the direct cursor coordinates. Such power gives SEs the opportunity to completely change the way the interface works for the user. A low-end example could be remapping the keys on the keyboard, while a higher-end one might be a PS/2 or USB hardware driver.
IV. When?
Spurred by recent improvements in PS/2 routines written by the community, I just completed fixing support for SEs within Doors CS 5.7 Internal Beta 6, which unfortunately uses the old system. Please click on the Discuss link and give me some feedback on the new system I'm considering.
Shell Expansions, or SEs, are modules for Doors CS. They are similar to the concept of Ion Modules, except that they are far more versatile. Shell Expansions can have one or more of three sections: Boot, Mouse, and Unload. A shell expansion with a Boot section is called while Doors CS is booting, before it counts programs and displays the desktop. Possible uses: load interrupts, set up hardware, sort programs, etc etc. Mouse sections are the most versatile: not only does Doors CS call them continuously while the mouse is active, they can actually interject actions into Doors CS itself. They can force mouse movement, clicking, and coordinate jumping via well-placed memory editing (not necessarily advocated). Finally, unload sections are, obviously, called while Doors CS is quitting, after it has closed down the GUI system but before it reverts to the TI-OS. Since a program can contain one or more of these sections, it can be anywhere from 768 byte to 2,304 bytes; each section can only be up to 768 bytes, since it must fit in SavesScreen.
II. Programming Detail: How?
Shell Expansions are currently loaded via an extremely inefficient system. When Doors CS first loads, it searches the VAT for programs that may be shell extensions, counting the number of shell extensions on the calculator but not making a note of which have boot, mouse, and unload sections. When the calculator reaches any of the three stages, it first checks to see if the SE count total is zero. If it is, it skips SE execution completely. If the variable is nonzero, it goes through an iterative loop, calling VATFind, Doors CS's most CPU-intensive routine, once for each of the Shell Extensions reportedly present. The VATFind routine searches through the VAT, counting the Shell Extensions it finds until the select one is found. It then checks if its vector table contains an entry for the calculator's current state (boot, mouse, or unload). If a relevant section is found in the selected Shell Extension, it copies it to RAM and then jumps to it.
Clearly, this is quite inefficient, because the entire VATFind system must be invoked each time an SE is executed, even if the specified SE does not have a relevant section for the current mode. However, this system does have its strenths. Because it does not store a table of SE locations anywhere, there is no inherent limit to the number of SEs on any system at a time, other than the 255-SE limit of using a byte to count. Secondly, it saves safe memory for programs for the same reason. However, by limiting the number of Shell Extensions on any system to, for example, eight, two major advantages could be attained:
1. The vector table could be consulted each time an SE event occured instead of needing to search through the VAT with VATFind once again
2. Additional memory, perhaps 2 bytes per SE, could be allocated to store important data in between executions.
With these changes, SEs would move closer to partial multithreading and away from the current rather cumbersome system.
III. Why?
As a programmer, why would you want to write your program as an SE rather than a full program? Well, not only would you have the programming challenge of fitting your entire program into 768, 1,536, or 2,304 bytes, you would have the advantage of interacting directly with the Doors CS kernel. Startup programs could directly set flags and options within Doors CS, or through some fancy programming, even prevent it from booting entirely (password protection, anyone?). Because Doors CS is now an app, SEs have access to each and every routine Doors CS has to offer to ASM programs, although it is not recommended that they mess with the GUI system, in case Doors CS itself is taking advantage of undocumented GUI API features. The mouse SEs are the crowning jewel of the SE system, for thety allow the programmer full control over cursor movement, cursor clicking, and even the direct cursor coordinates. Such power gives SEs the opportunity to completely change the way the interface works for the user. A low-end example could be remapping the keys on the keyboard, while a higher-end one might be a PS/2 or USB hardware driver.
IV. When?
Spurred by recent improvements in PS/2 routines written by the community, I just completed fixing support for SEs within Doors CS 5.7 Internal Beta 6, which unfortunately uses the old system. Please click on the Discuss link and give me some feedback on the new system I'm considering.