On Saturday 07 January 2006 23:09, Nils Labugt wrote: > > I think if we want to support multitasking the DPMI applications > > like mpxplay (it replaced the PIT handler), we have to virtualize > > the PIT ... > > We would probably have to virtualize more than the PIT...
IMHO we should, as Nils said, let the user decide. Since we are implementing a DOS-like system, we always said applications must be able to do whatever they want, including crash the system. Hence if an application wants to reprogram the PIT, the real one, it should have a chance to do so. It is common practice for applications that reprogram the PIT to call the original INT 8 handler (assuming they get INT 8 and not INT 1Ch) at regular intervals (the default PIT frequency) to keep the system working. If we can happily work even with a PIT frequency as low as 18 Hz I think we should, by default. The user might choose between several timer modules, each providing different levels of performance and compatibility: plain PIT, virtualized PIT, APIC timer, HPET and so on. Each timer module could expose timer-related functionality for event management (via devices?), so that other system components can be implemented transparently in respect of the timer module used. What do you think? > > BTW, I once thought about port QEMU user mode to FD32, let it > > natively runs in FD32 and it also was configured to run DOS > > programs (only). This can be appealing, but it would be straight emulation, while we should be able to provide native support. Bye, Salvo -- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ freedos-32-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-32-dev
