Hi Andy, > Thanks for the responses. I really don't have a project/idea in mind but > am looking to get my hands dirty and develop/work on/debug/poke anything > that needs to be done to improve the project. > > After looking at the FreeDOS roadmap ( > http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map) it seems like > working on developing automated regression tests (something I do most days) > would be beneficial to speed up releases. Has anyone looked into this > before? What would be things that would be most useful to be tested?
This would be beneficial if there were frequent code changes, which is not the case. In my personal opinion, it might be more useful to help Mateusz keeping an eye on updated packages to wrap them up in FreeDOS structured ZIPs for his update and installation tool, so the users can have fresh software. Regarding regression tests: There ARE some tickets where it would indeed be interesting to find out in which svn version of kernel (or maybe command.com, not so many other svn-based sources) a certain bug showed up or went away. So in that sense, your plant for making automated VM images running automated tests CAN be useful :-) Let me see what else the page lists: > == An Analysis of FreeDOS Needs == > > There are certain needs that the 1.0 release does not address. These are: > * Built-in networking and internet connectivity currently provided by add on > packages. > * Open source USB support through a built-in subsystem. > * Integrated protected mode programming currently provided by add on packages. > * Native 32‑ and 64‑bit code base. Honestly all of the above work quite well as drivers (using config.sys device drivers or command line runnable TSR drivers) and looking at FD32 experiences, building DPMI directly into the DOS kernel only has minimal performance advantages, for example. Of course it is important to have a good COLLECTION of drivers for in particular basic USB device classes and in particular wired ethernet network, even if they are just drivers and not parts of the kernel. For protected mode and 32/64 bit addressing (and multi CPU core thread processing) the necessary low level programming can be very tricky, so we have to stay thankful to the few experts who maintain the drivers for EMS / XMS / VCPI / DPMI and related. The USB core is also complex, but at least for drivers for specific USB devices, I see more chances for less specialized programmers to contribute. > * New device drivers available in other operating systems. At the moment, for example MPXPLAY uses ported (Linux ALSA?) built-in sound hardware drivers, but the nature of the DOS game versus soundcard interaction makes providing drivers for those hard: Most games have the driver built-in, not exchangeable. There are proof of concept "virtual" hardware drivers which show a simplified SoundBlaster hardware to DOS games while sending the actual sound to other hardware, but they suffer from the same problem as the protected mode drivers above: Complexity. For printing, the basic I/O can be seen as printer port, USB or network topic (there are some native and ported tools for the latter) while the printer language is sort of covered by ports of GhostScript and similar but could probably gain from having more choice of methods. For example for basic "print screen" functionality, we have a tiny driver which can do greyscale PostScript, HP/PCL and ESC/P in old dialects, which in turn is more convenient than having to go through GhostScript batches first. Note that nevertheless, it is barely used: Most people seem to use DOS only to print text or use DOS in a VM where they can also use drivers and tools of the host operating system. In particular for games, it is way more common to use DOSBOX or DOSEMU than to use raw hardware now. By the way, there are cool drivers like VMSMOUNT which specifically do driver work for improving DOS interaction with for example VMWare VMs. > * Faster release cycle through automated regression testing. Might be interesting, see above :-) > == Proposed Road Map == > > The proposed road map (as of 20 August 2010) is as follows: > * Automated regression testing will begin with version 1.1. > * Tightly integrated protected mode support will begin with version 1.2. > * Tightly integrated, protected mode networking, protected mode USB subsystem > will be part of 1.2 > * Version 1.2 will begin to share device drivers from other open source > operating systems. > * Version 2.0 will migrate kernel to a portable code base to address 32- and > 64-bit machines. Note that this roadmap is somewhat old and can be seen as one of several possible ways to improve FreeDOS. It basically depends on availability and interest of developers and on what they enjoy to contribute :-) Regards, Eric ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
