From: Martin K. <mar...@gm...> - 2012-05-04 05:01:30
|
Thanks Jim for your encouragement and support. What your suggesting is an interesting idea, like Pat Villani's original idea of implementing FreeBSD drivers into DOS. This idea intrigues me alot, i am a big BSD fan especially NetBSD and DragonflyBSD, thus implementing a Hybrid DOS-BSD system would be a rather neat feature. I agree with you for the most part Rugxulo that focusing on smaller bite size peices and planning it before you start i.e. the userspace utilities first is the best way to go. :D I don't have alot of knowledge on alot of the scripting language which is my limitation for knowing what things are possible. I would agree that porting from Minix would provide cleaner code than Linux, but while i say that i wouldn't be porting from Linux code but most likely BSD code. BSD code is generally scrutinised more and far more stable than Linux code, also BSD code would be easier to port than Linux code, as mentioned above. NetBSD in particular has alot of source that is compatible and has been used by alot of other OS's thus using some of their code wouldn't be a stupid idea. The biggest issue is that the project would take years for me to do alone and i don't know enough about all the different areas, scripting language being one of them to implement the idea in the cleanest and most efficient way. I think your question Mike is valid, but my belief and core idea is not to remove the INT 0x21 programming interface or the current software compatibility infact that was one of the key motivations of my design, was to keep all those features. It was the core idea of implementing the current FDOS kernel and running it along side a compatible DOS kernel that implements alot of the functionality of a current SMP capable kernel but at the same time can allow the DOS kernel to run the system indirectly or directly. Although I don't believe how DOS memory paging works or the Direct hardware access is what makes DOS, DOS. That was just the way of designing the system at the time, direct hardware access undoubtly has its benefits but in the grand scheme of things does the end user ever really see the difference? would it ultimately change what DOS can on a computer? The idea is similar to how MS implemented Windows 95 but the key difference NOT placing DOS into a virtual machine that is just the bootloader essentially. The only other OS i know that implements a similar feature is DragonflyBSD. It uses a virtual kernel in userspace but the key difference is that the virtual kernel provides instructions amongst other things to the kernel. Whether the creation of a hybrid system of a DOS kernel alongside a BSD kernel is possible (i.e. Converting between the different scripting languages)? or wheather you would have to write/ re-write a new kernel i am not sure? Running DOS like DOSEMU etc ontop of a Linux kernel would be pointless because the core interface is still Linux command and only becomes DOS when you enter the DOSEMU. Thus, to update the Linux kernel or to fix problems related to Linux (i.e. bugs, security, etc) you still need to use terminal. Unless the DOSEMU is able to implement a Linux command feature within or emulate it. Its a neat idea and would be kool, but at the end of the day its just another Linux system, with a different spin. I think DOSEMU demonstrates that the idea of putting the DOS kernel alongside another (non-DOS) kernel is infact possible. Strip DOSEMU down to the bare minimum and what you have is a Linux programming converted into DOS language. Just like how Wine is used in ReactOS. Martin |