Hi Louis, sort of a long response - it seems hard to make a short point here:
> FreeDOS Roadmap, as goals and stretch goals for the project. I read > (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit The fd32 project works or worked on the DPMI aspect. As far as I remember, the performance gain was minimal, but consider interest in terms of style to consider a protected mode kernel which has both DPMI and VM86 visibility. It would be a sort of DOSBOX then. Regarding built-in networking and USB, I am personally more for the existing loadable driver model. The BIOS gives you enough support to reach the point where you can load drivers in config sys. Even when booting via network (PXE) or from CD/DVD/BD, you can still use a MEMDISK (bootable ramdisk) to get started... On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables. The latter would have significant practical use. Not the former: When you boot from CD/DVD/BD, you do typically want a writeable ramdisk anyway, so you can just as well boot with the help of a MEMDISK which lets you load DOS CD/... drivers from there, making drivers for that as fixed parts of the kernel less interesting. Also, they are harder to update than separate drivers and you cannot easily skip them at boot to save DOS memory. Good question whether you want built-in USB: I would say no, you already need the BIOS to help to boot from USB. After that, you want a modular system of USB drivers (unless the BIOS provides support for all relevant USB devices) to let you access disks, sticks, mice, keyboards and so on. Also, devices for which there is no popular DOS or BIOS interface, such as network or sound, cannot have kernel drivers in a useful way. For networking, the packet driver interface is just one facet in a complex world, we could think about some additions to make it easier to write new drivers or to do common things with the network. For sound, the lack of popular interfaces means that you basically have to use protected mode to simulate a popular HARDWARE (SoundBlaster etc) and then let your actual driver play whatever the soundblaster would have played given the detected I/O with the simulation. > & 64-bit support, device driver imports, automated regression testing. Some automated or semi-automatic quality checks seem interesting. One could think of code style checks, audits, automated comparison of how well different artificial test cases or real software runs work with different kernel (micro-) versions in some VM etcetera. Regarding 64 bit support, there are some experiments with letting DPMI drivers use more than 4 GB of RAM. To make better use of it, you would have to define new interfaces (XMS, EMS, DPMI, VCPI...) and hope that DOS software would be written which uses them. Just using 32- or 64-bit calculations (not RAM addresses) is another story: Probably the kernel can be smaller by using more 32-bit calc but not really faster. Using memcopy optimized for more modern CPU (32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real difference, as the DOS kernel itself does not move a lot of data. In short, there are certainly points in which DOS can be extended, but I personally doubt that many or even any of them should start in the kernel. Separate drivers and other software fit better. Maybe we should discuss the roadmap again in the first place? Regards, Eric ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
