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
