KermMartian wrote:
elfprince13 wrote:
tr1p1ea wrote:
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?
... still breaks normal math program that aren't targetting DCSE specifically, and doesn't help the situation on DCS7. At least on DCSE, there aren't non-DCS xlib programs, so you should really just disable the libraries entirely for Basic programs with a DCSE header. Still leaves things a mess on the B/W calcs, and TI still hasn't patched OpenLib( to even work with lowercase letters.Ahh, yes, that was what I meant. And...huh, there isn't a stand-alone implementation is there? I feel like accessing basic libraries without a header should be considered unsupported behavior, at least on the 84+CSE, since you don't need to emulate support for pre-DCS xLib programs here.
KermMartian wrote:
KermMartian wrote:
Doors CS 7.2 and Doors CSE 8 both have this. I can detect it and return valid values for complex and imaginary numbers and for all reals except integers 1-14, but dealing with the integers 1-14 properly is harder. tr1p1ea, I recommend we do something about this for Doors CSE 8 ASAP, and figure out what kind of fix to backport later (since it seems not to be a bug people encounter daily (????)). The biggest problems are reals 6, 8, 11, and 14 on the monochrome calculators, and real(9) on the color calculator, since those are the functions that take a single argument. Is there some function that all xLIB-using programs run in practice before using the other real() functions?
In other words, make DCS and DCSE use the normal OS functionality for real() until the first time it is called with multiple arguments, then use the hooked version until the program ends. Honestly, the hardest part would be finding some very safe RAM to store a bit (ie, a binary digit) of state about this. For Doors CS 7 on the monochrome calculators, reals 14, 11, and 8 are the only ones that might be called before a multi-argument real. Doors CSE would be much easier: the online single-argument real() can never be the first xLIBC command called.If you get this working reliably, it would be great. It would need to work even in the face of reals 14/11/8 to restore functionality for math applications, or for my data structure implementations that use complex numbers to store tuples of pointers (e.g. for left/right tree-node children).
KermMartian wrote:
It would be very cool, but a pretty complex thing to implement. Even manipulating levels from user programs is pretty hard, given that the OS bcalls to work on these tasks are incompletely reverse-engineered and poorly documented. I'd say this is firmly on my long-term feature requests list, unfortunately.
Oh well =(
KermMartian wrote:
01:23 <@KermM> I just wish OpenLib/ExecLib were a lot less broken
Also bump of a previous proposal:
elfprince13 wrote:
Okay, makes sense. I think this reasoning would make even more sense if the OpenLib( call was to a generic shell name that could be configured to pass the program along to a user specified default shell. Is there a clean method to transfer control between apps? This would mean that (a) the polyglot portion of the header was always a fixed size regardless of which shell was being used (and make parsing easier), and (b) that programs wouldn't have to be released in 5 different editions for different shells.
elfprince13 wrote:
What about my idea of implementing a shell-manager app to transfer control to a shell of user's preference?