Hi Charles, you have so much RAM on a modern machine, you can just as well allocate XMS or other memory whenever you feel like swapping out a task :-) No need to use a file on a ramdisk. Also, the latter has the extra complexity that you need DOS to access that disk, which already needs stabilization due to the ongoing task switch anyway...
How about the following: Wrap int 16 and int 21 in routines which, before doing their actual work, do a check in 40:xx whether the user pressed a task- swap hotkey. If yes, use XMS to swap all possible aspects of state before continuing with whichever int 16 or int 21 call the NEW swap wanted to do at the moment when it was swapped out earlier. This avoids swapping while DOS or IRQ handlers are busy, if you handle the special case of DOS itself calling int 16 properly :-) Of course you may need to wrap several other DOS-related int as well, or at least use the InDOS flag to skip the swap magic when called while DOS is already busy. The meaning of ALL STATE can include all contents of the first 1024 + 64 kB, all CPU registers, the FPU registers if necessary. You probably want to save / restore keyboard shift LED states. As other mouse / keyboard activities are volatile anyway, it can be okay to not save them. On the other hand mouse activities transfer multiple bytes and you lose sync by just kicking in and out of swap all mouse driver state at arbitrary task swap moments. You may also want to swap graphics and sound state, but task swapping while playing sound might be too complicated for now anyway. Same for MMX and other FPU-like state. You may want to block DOS extenders while the task swapper runs, as otherwise you would have to swap all state of the DOS extender as well. Something like being in protected mode but blocking VCPI might be sufficient to block DOS extenders from reaching protected mode. To swap in protected mode, all the protected mode registers and data structures and all memory allocated by EMS XMS VCPI DPMI etc. would either need swapping (but where?) or managed: You would not swap them out, but keep track which of your tasks is allowed to see them in what way. As you see, even allowing your tasks to allocate XMS or EMS already makes task swapping more complicated. The good news is that if you simply refuse to swap tasks as soon as anything complicated is used, you could get a working task swapper in acceptable time. Then you can make more features swappable later :-) For example you could initially only allow swapping if graphics, sound, EMS, XMS, FPU, DPMI, VCPI... are in the same state as when your swapper host started. Or even only allow it when they are not used at all, or not even the drivers are used. Of course you will need XMS for the swapper itself, but the swapper may block access to XMS for everybody else. You probably will want to force kernel and command.com to not use XMS and HMA, to keep things simple, initially. Note that Windows 3 in 386enh mode swaps tasks in a very DOS specific way: It uses protected mode to put DOS in a v86 (vm8086?) task and then sort of clones that, knowing exactly which aspects need coordination between tasks (e.g. disk access). In a way, the DOS operating system aspect of all tasks shares state if I remember correctly, only the apps differ. This is why Windows only works in this mode with very well cooperating versions of DOS. Also, trying to use a feature or driver that is not managed might break the framework or might be simply blocked by it, afair... On the other hand, if all your hardware is virtual and you have lots of RAM, you can actually start a number of totally independent DOS tasks in protected mode. In other words, boot Linux and start as many DOSEMU windows as you want, they will not clash. Or boot Windows and start multiple DOSBOX windows :-) Does somebody remember what the abilities and limits of MS DOS DOSSHELL task swapping were? Or how about that open source thing? Was it TriDOS? I think most limitations of that were protected mode related? Regards, Eric PS: If you like advanced assembly language stuff, try the 386SWAT protected mode aware debugger TSR for DOS. ------------------------------------------------------------------------------ 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
