Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
+1 (I hate +1 mails on a mailing list that is read by 100's of readers, but this mail deserves it) Bringing things back to reality: Options 1, 2, and 3 do not exist and are not likely to exist for a few years even after somebody actively starts working on them. Options 1 and 2 can not promise 100% compatibility with both DOS applications and the full range of PC hardware when they are not even well defined. Is it a single 32 bit kernel or is it multiple kernels running in VDMs? I've seen so many things thrown around here so loosely ... It is a little silly to keep talking about a 32 bit kernel on the roadmap when such an option does not exist. To be considered for the roadmap it should exist in some form. Right now it is not even well defined what a 32 bit kernel would be. Not even a specification that we can debate. Let's see some concrete results on a 32 bit kernel before talking about putting it on any roadmap. BTW, the Kickstarter project doesn't even clearly define what a 32 bit DOS is. But at least its being honest and not promising 100% compatibility on anything. It is claiming to be hard real-time, modular, based on a micro-kernel, multi-threaded, and portable enough to be able to target ARM and some other architectures. That's a pretty bold set of buzzwords, but not a specification by any stretch of the imagination. Tom -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hi, I have to admit the difference between what I'd like to see and what I think it is likely to happen. I had found Japheth's work promising towards a good VMM, but apparently doesn't seem to be under active development, I find the task would be so huge (need to rewrite 32-bit versions of BIOS/DOS APIs capable of multitask different machines), and there's no abundance of gifted programmers. So I'm afraid I give +1 to this mail. I suggest concentrating efforts on FreeDOS 1.2. As for FreeDOS 2.0, we can always talk later (as I see it, either there's no consensus on what 32-kernel is, or if it has to be 16-bit, I think recovering the talk is needed, I would like to see what is proposed to be labelled 2.0 instead of 1.3). Cheers, Aitor 2015-01-06 3:16 GMT+01:00 Ralf Quint freedos...@gmail.com: On 1/5/2015 6:14 PM, Michael Brutman wrote: Bringing things back to reality: Options 1, 2, and 3 do not exist and are not likely to exist for a few years even after somebody actively starts working on them. Options 1 and 2 can not promise 100% compatibility with both DOS applications and the full range of PC hardware when they are not even well defined. Is it a single 32 bit kernel or is it multiple kernels running in VDMs? I've seen so many things thrown around here so loosely ... It is a little silly to keep talking about a 32 bit kernel on the roadmap when such an option does not exist. To be considered for the roadmap it should exist in some form. Right now it is not even well defined what a 32 bit kernel would be. Not even a specification that we can debate. Let's see some concrete results on a 32 bit kernel before talking about putting it on any roadmap. BTW, the Kickstarter project doesn't even clearly define what a 32 bit DOS is. But at least its being honest and not promising 100% compatibility on anything. It is claiming to be hard real-time, modular, based on a micro-kernel, multi-threaded, and portable enough to be able to target ARM and some other architectures. That's a pretty bold set of buzzwords, but not a specification by any stretch of the imagination. Now on this post, I can give a +1 ;-) Ralf --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Thank you very much, Vidók! On Tue, Jan 6, 2015 at 2:34 PM, Vidók Tibor tibor.vi...@gmail.com wrote: Hi, I was participating in a project to port a 32bit proprietary OS to 64bit 6 or 7 years ago. I was using a printed wersion of AMD64 Architecture Programmer’s Manual Volume 2: System Programming http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf Documentation. Actually I liked it much better then the Intel one. Br, Tibi 2015-01-06 17:50 keltezéssel, Mercury Thirteen írta: The only problem is that I haven't been able to find a whole lot of info on 64-bit long mode. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hi, I was participating in a project to port a 32bit proprietary OS to 64bit 6 or 7 years ago. I was using a printed wersion of AMD64 Architecture Programmer’s Manual Volume 2: System Programming http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf Documentation. Actually I liked it much better then the Intel one. Br, Tibi 2015-01-06 17:50 keltezéssel, Mercury Thirteen írta: The only problem is that I haven't been able to find a whole lot of info on 64-bit long mode. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
You are really providing links to me about how protected mode works? I am somewhat amused. Your new OS has to be able to arbitrate between conflicts caused by the multiple running VDMs. If two programs running at the same time choose to access the same I/O ports how are you going to handle that? (Hint: interleaving is not an option.) What about screen and filesystem access? How do you plan to virtualize the keyboard and mouse? OS/2 had to do all of these things. The OS described in your visions will have to do it as well. Any project is doable given enough resources. The point that we keep trying to make is that this is going to require a lot of resources, and these things have already been done by other operating systems. It doesn't make sense to spend resources on something we don't need. And as has already been pointed out, you seem to have a very poor understanding of the history of FreeDOS. Here is a link: http://en.wikipedia.org/wiki/Pat_Villani Quite a few of us know about OS design and implementation. I'm incredulous about general hand waving that is going on in this thread about how great a 32 bit FreeDOS would be. By definition if it's 32 bit it's not FreeDOS. Go start a project and do some work toward realizing your vision, but please stop calling it FreeDOS. And stop pretending to be an OS architect. On Tue, Jan 6, 2015 at 8:44 AM, Mercury Thirteen mercury0x0...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:14 PM, Michael Brutman mbbrut...@brutman.com wrote: Options 1, 2, and 3 do not exist and are not likely to exist for a few years even after somebody actively starts working on them. Correct. I never said this was something which could be thrown together overnight. I know the existing FreeDOS kernel took a ton of work, and I expect this undertaking would be no different. But it is doable. Options 1 and 2 can not promise 100% compatibility with both DOS applications and the full range of PC hardware when they are not even well defined. Is it a single 32 bit kernel or is it multiple kernels running in VDMs? I've seen so many things thrown around here so loosely ... It would be a single 32-bit protected mode http://en.wikipedia.org/wiki/Protected_mode kernel which sets up individual work spaces http://en.wikipedia.org/wiki/Virtual_8086_mode for each application, which can all run independently (and unaware) of each other. These work spaces would be set up by the processor itself to mimic the way real mode (e.g. 16-bit mode) works so that the applications can run as they always have. This is similar to running them in a virtual machine, except there is no emulator - the chip already contains the necessary silicon (the MMU) to perform the memory address relocation which makes this all possible. Interrupts are serviced by 32-bit handlers to eliminate the cycle-expensive switch from protected mode to real mode and back again. This http://prodebug.sourceforge.net/pmtut.html should explain the details of protected mode operation more concisely than I can do here. This kernel would (optimally) be a drop-in replacement for the existing FreeDOS kernel to enable 32-bit operation. It is a little silly to keep talking about a 32 bit kernel on the roadmap when such an option does not exist. I see your point, however if that attitude was taken during the initial formative discussions of the existing FreeDOS kernel... it never would have been made. ;-) At that point the 16-bit FreeDOS kernel didn't exist yet either, but discussion started, people got together and with a lot of work, it got made. To be considered for the roadmap it should exist in some form. Right now it is not even well defined what a 32 bit kernel would be. Not even a specification that we can debate. This is a very good point, I'll have to draw one up sometime soon. Let's see some concrete results on a 32 bit kernel before talking about putting it on any roadmap. Agreed. I've never said that we should actually put it on the map or make this huge push to create such an animal at this point. However, it short-circuits innovation to not discuss all options and methods available in any situation. I fully expect FD 1.2 to be 16-bit, and most likely 2.0 will be as well, but this shouldn't make us just blanket-disregard the future possibility. And maybe, in the end, some of these goals aren't attainable; I don't claim to be the world's foremost expert on the x86 architecture. But what I do know - about programming, OS design and the Intel processor line in general - indicates to me that these things should all be doable. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos,
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
To maybe summarize and make the task list a bit more concrete. Goals for FD 1.2 * Update kernel (release 2042?) * Update apps * Update translations * Update installer * Update/Standardize on mTCP and FDNPKG * Live-CD with installer * Floppy-based installer Possible Goals for FD 2.0 * USB-drive installer * UEFI companion CSM/SeaBIOS * UEFI boot-capability (from Floppy, HDD, CD-ROM, USB, other?) * Hardware detection, driver config install (network, audio?) * 16-bit core/boot image, build up of 32-bit/DPMI userland * Port mTCP and dependent tools to 32-bit/DPMI Feel free to chop up this list. Intentionally, I'm leaving off the 2.0 list things like making LFN (work!) better, better PXE boot support (PXE boot image), picking a 32-bit compiler (OW vs. DJGPP), the possibility of a 64-bit DPMI, anything else that could take significant amounts of man-hours. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Like others have said, anything (like the fictitious 64-bit DPMI) which has 1) little or no working code as of today (precedent/compatibility/feature parity with MS 3.3/6.22), 2) has a high a degree of complexity (achieveable), 3) requires a large dedication of man-hours to complete, 3) has little or no past, present, or future audience (value/benefit) ought to be on the short list of features to chop. I threw it out there though maybe I shouldn't have. Something more achievable would be to get Charles Sandmann to release his 36-bit CWSDPMI source (a DPMI server capable of providing 36-bit address space to P6 compatible processors). There's beta binaries in the wild. Though value/benefit is dubious; 32-bit DPMI apps would run fine on machines upto 64GB (the benefit), but there would be little or no software that could directly make use of more than 4GB at a time (dubios benefit). -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Mon, Jan 5, 2015 at 9:14 PM, Michael Brutman mbbrut...@brutman.com wrote: Options 1, 2, and 3 do not exist and are not likely to exist for a few years even after somebody actively starts working on them. Correct. I never said this was something which could be thrown together overnight. I know the existing FreeDOS kernel took a ton of work, and I expect this undertaking would be no different. But it is doable. Options 1 and 2 can not promise 100% compatibility with both DOS applications and the full range of PC hardware when they are not even well defined. Is it a single 32 bit kernel or is it multiple kernels running in VDMs? I've seen so many things thrown around here so loosely ... It would be a single 32-bit protected mode http://en.wikipedia.org/wiki/Protected_mode kernel which sets up individual work spaces http://en.wikipedia.org/wiki/Virtual_8086_mode for each application, which can all run independently (and unaware) of each other. These work spaces would be set up by the processor itself to mimic the way real mode (e.g. 16-bit mode) works so that the applications can run as they always have. This is similar to running them in a virtual machine, except there is no emulator - the chip already contains the necessary silicon (the MMU) to perform the memory address relocation which makes this all possible. Interrupts are serviced by 32-bit handlers to eliminate the cycle-expensive switch from protected mode to real mode and back again. This http://prodebug.sourceforge.net/pmtut.html should explain the details of protected mode operation more concisely than I can do here. This kernel would (optimally) be a drop-in replacement for the existing FreeDOS kernel to enable 32-bit operation. It is a little silly to keep talking about a 32 bit kernel on the roadmap when such an option does not exist. I see your point, however if that attitude was taken during the initial formative discussions of the existing FreeDOS kernel... it never would have been made. ;-) At that point the 16-bit FreeDOS kernel didn't exist yet either, but discussion started, people got together and with a lot of work, it got made. To be considered for the roadmap it should exist in some form. Right now it is not even well defined what a 32 bit kernel would be. Not even a specification that we can debate. This is a very good point, I'll have to draw one up sometime soon. Let's see some concrete results on a 32 bit kernel before talking about putting it on any roadmap. Agreed. I've never said that we should actually put it on the map or make this huge push to create such an animal at this point. However, it short-circuits innovation to not discuss all options and methods available in any situation. I fully expect FD 1.2 to be 16-bit, and most likely 2.0 will be as well, but this shouldn't make us just blanket-disregard the future possibility. And maybe, in the end, some of these goals aren't attainable; I don't claim to be the world's foremost expert on the x86 architecture. But what I do know - about programming, OS design and the Intel processor line in general - indicates to me that these things should all be doable. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
It is a little silly to keep talking about a 32 bit kernel on the roadmap when such an option does not exist. I see your point, however if that attitude was taken during the initial formative discussions of the existing FreeDOS kernel... it never would have been made. ;-) At that point the 16-bit FreeDOS kernel didn't exist yet either, but discussion started, people got together and with a lot of work, it got made. this way to tell the history of the FreeDOS kernel is as wrong as possible. FreeDOS kernel (or any other part of FreeDOS) was certainly not designed by a committee, but *all* of it (with the likely excreption of command.com) was designed and created by a single person (and later debugged/refined/extended by a dozen other people). I wasn't around in 1995, but not 'discussion started, people got together'. One day Pat Villani appeared out of thin air, and offered his (already existing) DOS-C kernel to the FreeDOS project. even if this had a huge number of bugs and problems, it was designed and created by a single person. He certainly didn't need (or take) advice from some members of an obscure mailing list. note: most software materializes after writing code, not emails. Tom -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
I have to say, I love the idea of a 64-bit DPMI. That's an area in which we would have total creative freedom because (unless I've missed the news) nobodyhas made such a thing yet. The only problem is that I haven't been able to find a whole lot of info on 64-bit long mode. http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html should contain enough info on long mode, but don't read everything at once Tom -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Sounds good to me. :) I have to say, I love the idea of a 64-bit DPMI. That's an area in which we would have total creative freedom because (unless I've missed the news) *nobody* has made such a thing yet. The only problem is that I haven't been able to find a whole lot of info on 64-bit long mode. On Tue, Jan 6, 2015 at 10:38 AM, Louis Santillan lpsan...@gmail.com wrote: To maybe summarize and make the task list a bit more concrete. Goals for FD 1.2 * Update kernel (release 2042?) * Update apps * Update translations * Update installer * Update/Standardize on mTCP and FDNPKG * Live-CD with installer * Floppy-based installer Possible Goals for FD 2.0 * USB-drive installer * UEFI companion CSM/SeaBIOS * UEFI boot-capability (from Floppy, HDD, CD-ROM, USB, other?) * Hardware detection, driver config install (network, audio?) * 16-bit core/boot image, build up of 32-bit/DPMI userland * Port mTCP and dependent tools to 32-bit/DPMI Feel free to chop up this list. Intentionally, I'm leaving off the 2.0 list things like making LFN (work!) better, better PXE boot support (PXE boot image), picking a 32-bit compiler (OW vs. DJGPP), the possibility of a 64-bit DPMI, anything else that could take significant amounts of man-hours. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] drives.exe
Interesting! I guess that's my one thing I've learned today lol *Mercury* isn't my birth name either ;-) On Mon, Jan 5, 2015 at 6:13 PM, Rugxulo rugx...@gmail.com wrote: Hi, On Mon, Jan 5, 2015 at 4:09 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: Thanks for that! I wasn't aware :) I wasn't sure either, but apparently that's their bug, so we can't really fix it. By the way.. how does one pronounce your name? I'm imagining something like Rug-zoo-low? Roo-JEW-lo (red guy) It's just a nickname, not even, just a fake screen name for computers. It's not my birth name. :-) http://www.akademio-de-esperanto.org/fundamento/gramatiko_angla.html gx is an unofficial (but popular) 7-bit digraph for (Unicode) U+011D, aka LATIN SMALL LETTER G WITH CIRCUMFLEX. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
