OK now I'm done my app (mostly) I can think a little more about other things. This is my first try at initiating an email to everyone and not just replying. Should work I think.
I may not have made the idea clear awhile back when I was talking about task switching in DOS and RAM disks. If I understand all the discussions so far most of the modern Intel boxes have way more RAM than does DOS can use or needs. I would suggest making the unused RAM a virtual disk and then using a task switcher that swapped to disk, pointing it to the virtual drive in memory. It would be quick and in fact just switching DOS sessions around in RAM. Now the second point is if I remember the "stuff" correctly the problem with DOS task switching is having the CPU start again in the right place when a session was switched back into the DOS space. You have to capture the stack on the CPU when you switch out a session. The problem is the stack was sometimes pointing to outside the session space like a BIOS routine, something in upper memory or an IRQ handler, a call the active session had made. When it swapped the session back in to active something had changed for one of those routines and it caused errors and occasionally a crash. I think this was the problem early version of Windows running in Real Mode and even 286 Mode had. General Exception Error OK Box (No! It was never OK.) or the notorious blue screen. OR EEP! something about the file the app was working on had changed! (EEP is an old school assembler joke) Some DOS apps behaved better than others in this regard, depending on how much they used stuff outside the session space. I'd bet, being a little bit more stupid than even Windows 1 to 2.5, DOS would be a little more fault tolerant in this regard. Perhaps just having the all sessions return to executing at a common "safe point" in RAM. Or a look up list for each app could be developed with the safe return point for each app in the list or the safe stack setting. The simple way I did this back in the day was just copy the most used and smaller programs along with a menu system that left a controlling stub of itself under the session to the RAM drive. It was close to task switching in RAM exiting and starting stuff in RAM. My last menu was mouse driven and so were a lot of text DOS apps at the times. It was fairly Windowy. Awww! Now I miss debug and writing your own coms in assembler with it. Poke a port, kludge a pointer. We sure had our fun back in the day! Later peeps Charlie B. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
