Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Welp, it was fun while it lasted On Fri, Jan 2, 2015 at 5:22 PM, Aitor Santamaría aitor...@gmail.com wrote: Thank you Rugxulo! If you thank me for good things working, which I didn't do, then you must also blame me when things go wrong. As such, blame away. I always was somewhat concerned about such licensing issues, but the software looks pretty valuable! :) Certainly valuable. That's why a lot of us used it. Heck, presumably that's why he shared it with the world in the first place. Unfortunately, it doesn't work anymore: Page cannot be crawled or displayed due to robots.txt. http://web.archive.org/web/20140526051314/http://japheth.de/robots.txt User-agent: * DisAllow: /cgi-bin I have no idea why they decided (now) to enforce that, after all these months. The original site is still down. AFAIK, the software itself is still freeware (although not totally free/libre). I don't know if this was Japheth's wish (doubt it, but he's very eccentric) or if it's just some default setting somewhere. Color me naive. I don't think the world is a better place now. Jim Hall will probably say, That's what you get for not being free/libre in the first place. And he's probably right. 2015-01-02 23:24 GMT+01:00 Rugxulo rugx...@gmail.com: On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com wrote: PS: Btw, I continue to be a bit worried about [ www.japheth.de ], anyone? http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html Also, dare I mention, the licensing is a bit ambiguous. Great if all you care about is freeware, lousy if you're a free software zealot. So don't expect many (if anybody) else to mirror it anywhere. -- 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, And that's such a sad news, if Japheth's software cannot be accessed anymore. Oh well... Aitor 2015-04-04 22:08 GMT+02:00 Rugxulo rugx...@gmail.com: Welp, it was fun while it lasted On Fri, Jan 2, 2015 at 5:22 PM, Aitor Santamaría aitor...@gmail.com wrote: Thank you Rugxulo! If you thank me for good things working, which I didn't do, then you must also blame me when things go wrong. As such, blame away. I always was somewhat concerned about such licensing issues, but the software looks pretty valuable! :) Certainly valuable. That's why a lot of us used it. Heck, presumably that's why he shared it with the world in the first place. Unfortunately, it doesn't work anymore: Page cannot be crawled or displayed due to robots.txt. http://web.archive.org/web/20140526051314/http://japheth.de/robots.txt User-agent: * DisAllow: /cgi-bin I have no idea why they decided (now) to enforce that, after all these months. The original site is still down. AFAIK, the software itself is still freeware (although not totally free/libre). I don't know if this was Japheth's wish (doubt it, but he's very eccentric) or if it's just some default setting somewhere. Color me naive. I don't think the world is a better place now. Jim Hall will probably say, That's what you get for not being free/libre in the first place. And he's probably right. 2015-01-02 23:24 GMT+01:00 Rugxulo rugx...@gmail.com: On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com wrote: PS: Btw, I continue to be a bit worried about [ www.japheth.de ], anyone? http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html Also, dare I mention, the licensing is a bit ambiguous. Great if all you care about is freeware, lousy if you're a free software zealot. So don't expect many (if anybody) else to mirror it anywhere. -- 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 gather that this debate is a bit over debated but... 1 - Two separate kernels (one 16-bit and one 32-bit) with a mechanism which auto-detects what CPU it's running on and launches the appropriate kernel Bernd and I once considered the possibility to make this part of the boot process, but then realized that you can not easily boot 16-bit CPU (286 and older) from CD anyway. In general, almost everybody should be happy with a kernel which needs at least 386 CPU. Others can use a boot floppy with 8086 compatible kernel. Another story is the 32-bit aspect of DOS extenders: The FD32 project has the kernel directly supporting protected mode (think DPMI). However, the performance improvement compared to loading DPMI host or similar extension frameworks inside a normal DOS. In FreeDOS, the kernel does NOT run in protected mode, so it is limited to 1 MB RAM. However, various drivers are not affected by that and even the kernel can use 32 bit maths. In short, a protected mode kernel is a niche thing, but it also is a niche thing to require 8086 CPU compatibility ;-) 3 - A single kernel which supports only 386 and newer processors and always runs in protected mode. Loses hardware compatibility for computers with 286 or earlier processors but maintains 100% software compatibility. See FD32. Given your interest in dedicated protected mode support, you certainly want to have a closer look at it. 4 - Keep the same great 16-bit kernel we all know and love. Maintains 100% hardware and software compatibility. See above - most people now use the FreeDOS kernel with 32-bit maths but without built-in protected mode stuff, loading that separately. Regards, Eric -- 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 like you've been busy, Jeremy! Please keep it up -- believe me, I can relate to the lack of time to implement and test all of the ideas. -- 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 Wed, Jan 7, 2015 at 11:31 AM, Bertho Grandpied y31415926...@yahoo.fr wrote: Regarding the next FreeDOS 1.2 and possible later 1.x releases, I'd like to see the kernel upgraded to supporting large sector sizes, rather than hear fantasies about '32 bit FreeDOS' ! As far as the 16-bitty-FreeDOS kernel is concerned, it's been clearly stated that the goal is to be (at least) at the level of MS-DOS 3.x to MS-DOS 6.2x Those proprietary DOSes support installable block devices with 8k-byte sectors (claimed) and even up to 32k (not claimed by MS, but effectively working, even if such sector sizes are ineffective and arguably ridiculous). I'd like to hear from the Kernel team (is that just one-man, aka PerditionC ?) on this subject. A proposed roadmap could have, ideally : ... My current plans are to get a new release out in the next couple of weeks with accumulated bug fixes. After that depending on many factors (mostly free time and other kernel devs), 2043/2044 will have boot time changes, specifically I may merge in some of my work on MS-DOS compatible menus and GPT support. The kernel can handle larger sectors, but there are some buffers and corruption issues (probably related to the buffers issue) that need to be addressed. I have more plans, but my time is limited so until I have code will refrain from discussing. Jeremy -- 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 Tue, Jan 6, 2015 at 7:06 PM, Michael Brutman mbbrut...@brutman.com wrote: 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. Oh, the things I could say to that response... I just can't win with you, can I? lol You site my lack of technical info, then when I provide slightly more technical examples, there's a problem with those, too. Oh, well. It seems your mind is already made up that you don't want to even consider any new ideas of this type. And that's all they are... ideas. I'm not forcing anything on anybody, just making discussion since that is what this list is for. And I'll have to agree with you on your point that a would-be developer of such a project should go elsewhere to do so - they sure wouldn't get much support here. Regardless, this will be my final word to you on this subject. P.S. Thank you for the link, however. I, for one, appreciate learning new things. -- 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 have my email address. Say them in private if you like. In the past few days you have drawn false analogies to other operating systems, demonstrated a lack of understanding of the origins of FreeDOS or what it is, and made wild statements about what a non-existent piece of software could do. You have replied that you have provided details on how to maintain compatibility with existing software without providing any such details. And you continue to do this in the name of a roadmap discussion where the consensus has already formed days ago. How long have you been a FreeDOS user? What DOS code have you written? What other relevant experience do you have? I'm done too - this has been a waste of precious time. I hope you learn something while trying to put FreeDOS 1.2 together; it may give you a better appreciation for the technical challenges. -- 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
Regarding the next FreeDOS 1.2 and possible later 1.x releases, I'd like to see the kernel upgraded to supporting large sector sizes, rather than hear fantasies about '32 bit FreeDOS' ! As far as the 16-bitty-FreeDOS kernel is concerned, it's been clearly stated that the goal is to be (at least) at the level of MS-DOS 3.x to MS-DOS 6.2x Those proprietary DOSes support installable block devices with 8k-byte sectors (claimed) and even up to 32k (not claimed by MS, but effectively working, even if such sector sizes are ineffective and arguably ridiculous). I'd like to hear from the Kernel team (is that just one-man, aka PerditionC ?) on this subject. A proposed roadmap could have, ideally : - at FREEDOS 1.2 : achieve the compatibility as advertised with MS-DOS, i.e. allow installable block drivers declaring 8 k bytes per sector (bps). 16 32 k bps are not necessary IMO, if they work (silently, unadvertised) so much the better. At LEAST we SHOULD have 4k bps working and tested, which while not up to MS-DOS, is necessary (and sufficient) for most if not all current devices. - at 1.2 OR LATER, let FREEDOS optimise buffer management BETTER than MS-DOS : e.g. could have differentiated pools of buffers for 512 and 4K bps (or other 'large' sectors), or 1 pool but intelligent management of space so as not to waste a large part of buffer space in the presence of devices with different sector sizes. Possibly, with buffers in XMS, EMS... - some time : update DOS's built-in (not installable) disk drivers so they, too, support native 4k bps sectors (or more). - some time : support booting from large sectors (may need BIOS or auxiliart support) Of these steps, I deem the first one an absolute must in this time and world. Opinions please ? and HAPPY NEW TEAR ! -- Czerno -- 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
Couldn't agree more, Czerno. I would also add that the various disk utilities (FORMAT, FDISK, defragging, caching, etc.) should also work correctly with sector sizes other than 512 bytes (even though most of the MS-DOS utilities don't -- SMARTDRV being the major exception that I'm aware of). In addition to installable block device drivers, it should also be possible to install large-sector block devices with TSRs (including using the INSTALL= option in CONFIG.SYS to install a TSR, or using DEVLOAD or equivalents thereof with CONFIG.SYS-style device drivers). The other major bug I'm aware of in FreeDOS, which may have been fixed by now, is the INSTALL= problem. FREEDOS INSTALL= installs between 64k and 128k of DOS-related code at the top of conventional memory (just below the 640k barrier), but doesn't properly allocate it it with a memory control block. When a TSR tries to (properly) allocate memory in this region of memory, it clobbers the DOS code and the machine crashes. -- 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
+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] FreeDOS 1.2 and 2.0 roadmap discussion
Hi all! I want to add my thoughts to Tom’s e-mail: I think that the first step to a 32-bit version of FreeDOS has already be done! It’s called JEMM and HX DOS Extender (http://web.archive.org/web/20140905021040/http://www.japheth.de/) You can even run some Windows programs. Using money from Kickstarter could maybe motivate him to continue developing these programs. Cheers Florian — Dr. Florian Xaver http://www.xaver.me http://www.drdos.org - DOS Wiki On Sonntag, Jän. 4, 2015 at 6:17 nachm., Tom Ehlert t...@drivesnapshot.de, wrote: The part about a kernel sensing the hardware it is on and being able to decide to boot in classic 16 bit mode or go full 32 bit and behave as a supervisor is technically feasible. But I don't think it's going to fit on a floppy disk. you are missing the fact that device= EMM386.EXE (or its brothers and sisters) puts the machine in 32bit, protected mode, and *everything* runs under the control of EMM386.EXE. even if it currently reflects most interrupt handling down to the 'real mode' KERNEL.SYS and BIOS, there is no reason that it couldn't handle some part or all of INT21, INT13, INT10, INTxyz handling *inside* EMM386, fully in protected mode, making it a real, true 32 BIT DOS. I even think it should be possible (with reasonable effort) to compile KERNEL.EXE in 32Bit mode (with some glue code) and make it part of EMM386; this would make this 32BIT DOS 100% compatible to FreeDOS by definition. not exactly trivial, but not (much) more complicated that moving KERNEL.EXE into HMA. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? so far the people working on FreeDOS did it for fun or technical challenge, not for the money. $2500 would have been ridiculous bad hourly wage. Who out there with the skills to do this kind of work is actually standing up to do the work? I don't expect anyone. not that many people out there with the required skills, and there are other, more rewarding projects waiting 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-- 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, Florian! I totally agree, but the only problem is that Japheth seems to be gone. :( On Mon, Jan 5, 2015 at 5:04 AM, Florian Xaver f...@drdos.org wrote: Hi all! I want to add my thoughts to Tom’s e-mail: I think that the first step to a 32-bit version of FreeDOS has already be done! It’s called JEMM and HX DOS Extender ( http://web.archive.org/web/20140905021040/http://www.japheth.de/) You can even run some Windows programs. Using money from Kickstarter could maybe motivate him to continue developing these programs. Cheers Florian — Dr. Florian Xaver http://www.xaver.me http://www.drdos.org - DOS Wiki On Sonntag, Jän. 4, 2015 at 6:17 nachm., Tom Ehlert t...@drivesnapshot.de, wrote: The part about a kernel sensing the hardware it is on and being able to decide to boot in classic 16 bit mode or go full 32 bit and behave as a supervisor is technically feasible. But I don't think it's going to fit on a floppy disk. you are missing the fact that device= EMM386.EXE (or its brothers and sisters) puts the machine in 32bit, protected mode, and *everything* runs under the control of EMM386.EXE. even if it currently reflects most interrupt handling down to the 'real mode' KERNEL.SYS and BIOS, there is no reason that it couldn't handle some part or all of INT21, INT13, INT10, INTxyz handling *inside* EMM386, fully in protected mode, making it a real, true 32 BIT DOS. I even think it should be possible (with reasonable effort) to compile KERNEL.EXE in 32Bit mode (with some glue code) and make it part of EMM386; this would make this 32BIT DOS 100% compatible to FreeDOS by definition. not exactly trivial, but not (much) more complicated that moving KERNEL.EXE into HMA. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? so far the people working on FreeDOS did it for fun or technical challenge, not for the money. $2500 would have been ridiculous bad hourly wage. Who out there with the skills to do this kind of work is actually standing up to do the work? I don't expect anyone. not that many people out there with the required skills, and there are other, more rewarding projects waiting 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 -- 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
+1 +1 +1 :) However... I just wanted to point out that - if my grasp on technology is adequate - going 32-bit need not break either hardware or software compatibility, since the kernel could detect which CPU on which it is running and either shift into protected mode or stay in real mode accordingly. I have a habit of not fully explaining the concepts in my head (probably why I'm not a teacher lol) so I just wanted to make sure I had made that point clear. No problems, though. Looking forward to FreeDOS 2.0! :D On Sun, Jan 4, 2015 at 11:27 PM, Jim Hall jh...@freedos.org wrote: I'm traveling, and likely won't be able to check email again or update the roadmap on the wiki until Wednesday. With a few disagreements, it looks like the consensus remains this: *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* This seems a clear direction. I'll admit that I'm curious what the kickstarter might achieve, but I'm not hopeful. So while a FreeDOS-32 kernel that ran 16-bit apps while adding new features would be very cool, it doesn't seem realistic. And it breaks hardware compatibility anyway. So let's take it off the roadmap. If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. But I don't think we want to forecast it for a release (that is, not 2.0 or 3.0 ... it's up to them to demonstrate feasibility, then we'll pick up the topic again.) If no serious disagreements with the above, I think we can consider this topic done, and I'll update the roadmap on the wiki later this week. If you agree, please reply with +1. If you disagree, please share your thoughts by Tuesday. Sound fair? -- 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
Nobody says you gotta run a 32-bit version of dos on a system that isn't 32-bit. What's wrong with just leaving the version that's already running there, and just use the 32-bit version on 386+ machines. Nobody said the current version would disappear just because a 32-bit version shows up. Still a nonissue as far as I'm concerned. On Jan 3, 2015, at 2:04 PM, Steve Nickolas wrote: On Sat, 3 Jan 2015, Travis Siegel wrote: On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: People are free to fork off and make a new project based on FreeDOS. No problem there. But once you break compatibility with existing applications, you lose a lot of your potential user base. And as soon as you go to 32 bits, you lose all of the early hardware. I'm puzzled at this. Why does going to 32-bit mean all old hardware will be broken? Because old hardware exists, like my 5160, that runs DOS and is still 16-bit? Obviously you can't run a 32-bit OS on a 5160, but DOS will run just fine. All of that would be broken by moving to 32-bit. 32-bit os doesn't mean no old hardware, it simply means drivers need to do something to make the translation. ...And how do you expect to run this OS on a 5160? Or an AT? Systems that run DOS just fine now? You knock out probably half the audience for FreeDOS by eliminating pre-386. -uso. -- 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
Expounding a bit on all the options and variations which have been presented in this 32- vs. 16-bit debate: 1 - Two separate kernels (one 16-bit and one 32-bit) with a mechanism which auto-detects what CPU it's running on and launches the appropriate kernel automatically. Maintains 100% hardware and software compatibility, and would potentially cut down on bloat since the installer could alternately detect the user's processor ahead of time and install only the most well-suited kernel for the user's machine. 2 - A single kernel which contains provisions for both protected and real modes, auto-detects what CPU it's running on and launches into protected mode automatically if it's supported but stays in real mode if not. Maintains 100% hardware and software compatibility at the expense of a larger kernel. 3 - A single kernel which supports only 386 and newer processors and always runs in protected mode. Loses hardware compatibility for computers with 286 or earlier processors but maintains 100% software compatibility. 4 - Keep the same great 16-bit kernel we all know and love. Maintains 100% hardware and software compatibility. Note that only options 1, 2 and 4 keep 100% compatibility with both DOS applications and the full range of PC hardware. Option three would modernize the kernel the most, but I think we all agree we cannot isolate any members of our installed base like that. None of these options involve any kind of emulation software, although options 1 and 2 would rely on the processor's built-in virtual x86 mode which, despite it's name, is not (strictly speaking) an emulator but simply real mode with the on-chip MMU - normally deactivated in real mode - left activated. Not meaning to keep the debate going, just summarizing as it winds to a close. This has been a most interesting discussion. :) Merc On Mon, Jan 5, 2015 at 4:58 PM, Travis Siegel tsie...@softcon.com wrote: +1 On Jan 4, 2015, at 11:27 PM, Jim Hall wrote: I'm traveling, and likely won't be able to check email again or update the roadmap on the wiki until Wednesday. With a few disagreements, it looks like the consensus remains this: *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* This seems a clear direction. I'll admit that I'm curious what the kickstarter might achieve, but I'm not hopeful. So while a FreeDOS-32 kernel that ran 16-bit apps while adding new features would be very cool, it doesn't seem realistic. And it breaks hardware compatibility anyway. So let's take it off the roadmap. If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. But I don't think we want to forecast it for a release (that is, not 2.0 or 3.0 ... it's up to them to demonstrate feasibility, then we'll pick up the topic again.) If no serious disagreements with the above, I think we can consider this topic done, and I'll update the roadmap on the wiki later this week. If you agree, please reply with +1. If you disagree, please share your thoughts by Tuesday. Sound fair? -- 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
+1 On Jan 4, 2015, at 11:27 PM, Jim Hall wrote: I'm traveling, and likely won't be able to check email again or update the roadmap on the wiki until Wednesday. With a few disagreements, it looks like the consensus remains this: *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* This seems a clear direction. I'll admit that I'm curious what the kickstarter might achieve, but I'm not hopeful. So while a FreeDOS-32 kernel that ran 16-bit apps while adding new features would be very cool, it doesn't seem realistic. And it breaks hardware compatibility anyway. So let's take it off the roadmap. If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. But I don't think we want to forecast it for a release (that is, not 2.0 or 3.0 ... it's up to them to demonstrate feasibility, then we'll pick up the topic again.) If no serious disagreements with the above, I think we can consider this topic done, and I'll update the roadmap on the wiki later this week. If you agree, please reply with +1. If you disagree, please share your thoughts by Tuesday. Sound fair? -- 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 january 4 Jim Hall said: FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea. I must say I never used the installer, so I don't know whether it can be improved. FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion). If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. If you agree, please reply with +1. +1 JAS -- 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
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. -- 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 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hi Or let te user to decide to load the 32bit/i386 driver or not. The marketting question is: why is it more than a new, yet another extender. If decided not to load, it is 100 backward compatible both from hw and sw point of view. Br, Tibi -- 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
The part about a kernel sensing the hardware it is on and being able to decide to boot in classic 16 bit mode or go full 32 bit and behave as a supervisor is technically feasible. But I don't think it's going to fit on a floppy disk. you are missing the fact that device= EMM386.EXE (or its brothers and sisters) puts the machine in 32bit, protected mode, and *everything* runs under the control of EMM386.EXE. even if it currently reflects most interrupt handling down to the 'real mode' KERNEL.SYS and BIOS, there is no reason that it couldn't handle some part or all of INT21, INT13, INT10, INTxyz handling *inside* EMM386, fully in protected mode, making it a real, true 32 BIT DOS. I even think it should be possible (with reasonable effort) to compile KERNEL.EXE in 32Bit mode (with some glue code) and make it part of EMM386; this would make this 32BIT DOS 100% compatible to FreeDOS by definition. not exactly trivial, but not (much) more complicated that moving KERNEL.EXE into HMA. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? so far the people working on FreeDOS did it for fun or technical challenge, not for the money. $2500 would have been ridiculous bad hourly wage. Who out there with the skills to do this kind of work is actually standing up to do the work? I don't expect anyone. not that many people out there with the required skills, and there are other, more rewarding projects waiting 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 don't think I missed anything. In his most recent post Mercury Thirteen spoke of multiple 16 bit programs running at the same time. That it's not EMM386 ... that is a supervisor layer for multiple virtual DOS machines. -- 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 don't think I missed anything. In his most recent post Mercury Thirteen spoke of multiple 16 bit programs running at the same time. That it's not EMM386 ... that is a supervisor layer for multiple virtual DOS machines. multitasking is certainly far from trivial, but will not fill a floppy disk. I was referring to the fact that the kernel is ~60 K, JEMM386 30K, a 2nd included kernel 60 K again, leaving 1 MB for the hypothetical multitasking supervisor. not that we will see one anytime soon 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 getting better at it. Recently, made a picture viewer in visual studio, and have to play with it some more. I settled on 30 an hour for coding an app. -- -Chris Evans Computer Consultant, Systems Administrator, Programmer, PC technician Digitalatoll Solutions Group (Tawhaki Software) Cell. : 916-612-6904 | http://www.tawhakisoft.slyip.net/ Office: 916-382-9395 | http://www.digitalatoll.com/ Skype: chris.evans450 | http://norcalhost.com/ On Jan 4, 2015 9:17 AM, Tom Ehlert t...@drivesnapshot.de wrote: The part about a kernel sensing the hardware it is on and being able to decide to boot in classic 16 bit mode or go full 32 bit and behave as a supervisor is technically feasible. But I don't think it's going to fit on a floppy disk. you are missing the fact that device= EMM386.EXE (or its brothers and sisters) puts the machine in 32bit, protected mode, and *everything* runs under the control of EMM386.EXE. even if it currently reflects most interrupt handling down to the 'real mode' KERNEL.SYS and BIOS, there is no reason that it couldn't handle some part or all of INT21, INT13, INT10, INTxyz handling *inside* EMM386, fully in protected mode, making it a real, true 32 BIT DOS. I even think it should be possible (with reasonable effort) to compile KERNEL.EXE in 32Bit mode (with some glue code) and make it part of EMM386; this would make this 32BIT DOS 100% compatible to FreeDOS by definition. not exactly trivial, but not (much) more complicated that moving KERNEL.EXE into HMA. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? so far the people working on FreeDOS did it for fun or technical challenge, not for the money. $2500 would have been ridiculous bad hourly wage. Who out there with the skills to do this kind of work is actually standing up to do the work? I don't expect anyone. not that many people out there with the required skills, and there are other, more rewarding projects waiting 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 -- 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 Sat, Jan 3, 2015 at 10:15 PM, Michael Brutman mbbrut...@brutman.com wrote: If you want to run multiple virtual DOS machines at the same time use an existing solution that already has the Virtual 8086 mode, or even an entire virtual machine. I really can't see the advantage that you would be getting by reinventing a very big, heavy, and complex wheel. It is not as trivial task. As you say, we have an existing solution to run multiple instances of FreeDOS on a modern system: Linux + DOSemu http://www.freedos.org/jhall/blog/?id=20090422-143518. Creating another non-DOS system just to emulate DOS on modern systems isn't necessary. I don't support the emulation route. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? Who out there with the skills to do this kind of work is actually standing up to do the work? Chelson says he has used programmers on freelancer.com before (he does game development). I think developing a small app for an iDevice is a different thing than updating the codebase from something like FreeDOS-32. But I'm curious to see what he can do. If I understand the Kickstarter rules correctly, he has to reach his $2,500 goal before Kickstarter will release the funds to him. -- 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'm traveling, and likely won't be able to check email again or update the roadmap on the wiki until Wednesday. With a few disagreements, it looks like the consensus remains this: *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* This seems a clear direction. I'll admit that I'm curious what the kickstarter might achieve, but I'm not hopeful. So while a FreeDOS-32 kernel that ran 16-bit apps while adding new features would be very cool, it doesn't seem realistic. And it breaks hardware compatibility anyway. So let's take it off the roadmap. If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. But I don't think we want to forecast it for a release (that is, not 2.0 or 3.0 ... it's up to them to demonstrate feasibility, then we'll pick up the topic again.) If no serious disagreements with the above, I think we can consider this topic done, and I'll update the roadmap on the wiki later this week. If you agree, please reply with +1. If you disagree, please share your thoughts by Tuesday. Sound fair? -- 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
+1 backwards compatibility model is a must more so than 32bit support, measuring stick should be compared to a average stock 6.22/win98 dos system. -- -Chris Evans Computer Consultant, Systems Administrator, Programmer, PC technician Digitalatoll Solutions Group (Tawhaki Software) Cell. : 916-612-6904 | http://www.tawhakisoft.slyip.net/ http://www.tawhakisoft.com/ Office: 916-382-9395 | http://www.digitalatoll.com/ Skype: chris.evans450 | http://norcalhost.com/ http://norcalhost.slyip.net/ On Sun, Jan 4, 2015 at 8:27 PM, Jim Hall jh...@freedos.org wrote: I'm traveling, and likely won't be able to check email again or update the roadmap on the wiki until Wednesday. With a few disagreements, it looks like the consensus remains this: *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* This seems a clear direction. I'll admit that I'm curious what the kickstarter might achieve, but I'm not hopeful. So while a FreeDOS-32 kernel that ran 16-bit apps while adding new features would be very cool, it doesn't seem realistic. And it breaks hardware compatibility anyway. So let's take it off the roadmap. If they can demonstrate feasibility of FreeDOS-32 running 16-bit programs while adding new features, we can consider it and discuss it at that time. But I don't think we want to forecast it for a release (that is, not 2.0 or 3.0 ... it's up to them to demonstrate feasibility, then we'll pick up the topic again.) If no serious disagreements with the above, I think we can consider this topic done, and I'll update the roadmap on the wiki later this week. If you agree, please reply with +1. If you disagree, please share your thoughts by Tuesday. Sound fair? -- 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
from Sparky4: I think the FreeDOS 2.0 version should be a updated 16 bit kernel that can run in real mode by default and the freedos-32 stuff should merge with OSFree I thought of that, a 32-bit version of FreeDOS could take ideas/features from OS/2 and eComStation. I saw OS/2 as like a much-enhanced 32-bit DOS. On osfree.org, it looks like progress is minimal, like watching grass grow at the South Pole. I ran OS/2 from v1.3, the last 16-bit version, to Warp 4 with fixpack 12 when during the single-digit days of April 2001, following a crash/freeze, CHKDSK, running automatically, ran amok and trashed the hard-drive data. I was never again able to boot OS/2 even with the installation floppies. Since then, Linux, FreeBSD and NetBSD have, as far as I can see, greatly overtaken eComStation in hardware support and functionality. Even if FreeDOS-32 and OSFree could join forces, there would be a lot of catching up to do. 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
On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: I too would love to see a fully modern DOS. As would I, and I believe everything mentioned in the email would be perfect for a 32-bit dos. I believe it can be done, and the whole give each program it's own virtual 86 machine is one I've wondered about for quite sometime. It shouldn't be difficult, and actually, I read somewhere that the initial version of windows did this, but of course, I can't confirm that, since the only version of windows 1.0 I ever had was on an xt where such a scheme wouldn't have worked anyhow, not to mention, I haven't a clue where that machine wound up at. :) Otherwise, each program being spawned in it's own virtual 86 machine, and leaving things in protected mode as much as possible makes perfect sense to me, and it was what I'd figured would happen to dos eventually, but it never did. -- 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 Sat, 3 Jan 2015, Thomas Mueller wrote: I thought of that, a 32-bit version of FreeDOS could take ideas/features from OS/2 and eComStation. I saw OS/2 as like a much-enhanced 32-bit DOS. Yeah. And if I were to try to create a 32-bit DOS, it might be something like OS/2 without Presentation Manager (think, a 32-bit OS/2 1.0). -uso. -- 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
Yes, that's exactly what I meant in my emails. Microsoft would've eventually (in my educated guesses, at least) made MS-DOS enter protected mode as early as possible (as any modern OS does) then spawned multiple apps in their own memory areas using VM86. This would basically make the kernel the V86 monitor program which managed hardware and such for the VM86 applications. It would've been super fast with protected memory and preemptive multitasking thrown in almost for free, as a gift from the x86 processor. And, since the traditional applications would be running on real hardware and not in some kind of emulator, we would still be staying true to the classic DOS platform while being suddenly able to run all kinds of binaries - e.g. MZ, NZ, LE and LX programs. Such a DOS would be quite an experience to run! :) On Sat, Jan 3, 2015 at 1:14 PM, Travis Siegel tsie...@softcon.com wrote: On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: I too would love to see a fully modern DOS. As would I, and I believe everything mentioned in the email would be perfect for a 32-bit dos. I believe it can be done, and the whole give each program it's own virtual 86 machine is one I've wondered about for quite sometime. It shouldn't be difficult, and actually, I read somewhere that the initial version of windows did this, but of course, I can't confirm that, since the only version of windows 1.0 I ever had was on an xt where such a scheme wouldn't have worked anyhow, not to mention, I haven't a clue where that machine wound up at. :) Otherwise, each program being spawned in it's own virtual 86 machine, and leaving things in protected mode as much as possible makes perfect sense to me, and it was what I'd figured would happen to dos eventually, but it never did. -- 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
Old hardware has 16 bit registers. Requiring opcodes that only 386+ systems have an using the extra registers, or assuming that registers contain 32 bits means that no 8088 class or 80286 class system will run. That is a big conflict. On Sat, Jan 3, 2015 at 10:35 AM, Travis Siegel tsie...@softcon.com wrote: On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: People are free to fork off and make a new project based on FreeDOS. No problem there. But once you break compatibility with existing applications, you lose a lot of your potential user base. And as soon as you go to 32 bits, you lose all of the early hardware. I'm puzzled at this. Why does going to 32-bit mean all old hardware will be broken? Why does it mean old 16-bit programs won't work? Neither one of these issues are a problem if the 32-bit is handled properly. There's no reason it can't be done. I mean, look at linux. It's a 32-bit os, but it has been successfully compiled and run on xt class machines. 32-bit os does not mean no 16-bit apps, it simply means special handling is due such apps. 32-bit os doesn't mean no old hardware, it simply means drivers need to do something to make the translation. That's all. I see no conflict. -- 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
On Sat, Jan 3, 2015 at 1:33 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: We in this discussion aren't the first people to question how to successfully meld the worlds of 32- and 16-bit code while having speed, flexibility and compatibility. This became an issue way back in the days of the 386, and so some smart folks have already not only already considered the problem, but designed the solution and implemented it - right into the Intel processor! We just have to know its intricacies and use them to our advantage. The code of the open source DOS/32A extender and the OSDev.org website would be great starting points for anyone who wanted to undertake such an endeavor. ...however, don't misconstrue my comments to mean that I'm insisting FreeDOS become 32-bit. This project is awesome as it is and you guys have already taken it way beyond Microsoft ever did, showing it the love it always deserved. Either way we go will be fine with me. :) -- 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 Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: People are free to fork off and make a new project based on FreeDOS. No problem there. But once you break compatibility with existing applications, you lose a lot of your potential user base. And as soon as you go to 32 bits, you lose all of the early hardware. I'm puzzled at this. Why does going to 32-bit mean all old hardware will be broken? Why does it mean old 16-bit programs won't work? Neither one of these issues are a problem if the 32-bit is handled properly. There's no reason it can't be done. I mean, look at linux. It's a 32-bit os, but it has been successfully compiled and run on xt class machines. 32-bit os does not mean no 16-bit apps, it simply means special handling is due such apps. 32-bit os doesn't mean no old hardware, it simply means drivers need to do something to make the translation. That's all. I see no conflict. -- 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 Jan 1, 2015, at 8:31 PM, Jim Hall wrote: It seems clear a consensus is appearing, but I'll give folks another few days to chime in. That will give me time to continue on website cleanup things, anyway. :-) I think primarily, your summary hit the nail on the head, with the caveat that if a 32-bit dos could be built that still maintained the backward compatibility for those programs that needed it, it would *not* be a bad thing, in fact, it'd be embraced wholeheartedly. Of course, the chances of that are slim, but if it could be pulled off, freedos would do something no other dos has ever managed, and that would sure be a boon. -- 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 Jan 1, 2015, at 10:44 PM, Dave Pratt wrote: Are there other benefits you see to the 32 bit DOS? A 32-bit dos would break the 640K barrier permanently for one thing. For another, multitasking would not only be possible, it would probably become the norm. I know I'm not the only one who would love to have an os that's dos compatible, has loads of memory, and could switch tasks, and still do so in less than 5 megabytes of space. (ok, probably more like 20-50 megabytes of space when all is said and done, but still) ... -- 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
Hello, 2015-01-03 19:14 GMT+01:00 Travis Siegel tsie...@softcon.com: On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: I too would love to see a fully modern DOS. As would I, and I believe everything mentioned in the email would be perfect for a 32-bit dos. I believe it can be done, and the whole give each program it's own virtual 86 machine is one I've wondered about for quite sometime. It shouldn't be difficult, and actually, I read somewhere that the initial version of windows did this, but of course, I can't confirm that, since the only version of windows 1.0 I ever had was on an xt where such a scheme wouldn't have worked anyhow, not to mention, I haven't a clue where that machine wound up at. :) Otherwise, each program being spawned in it's own virtual 86 machine, and leaving things in protected mode as much as possible makes perfect sense to me, and it was what I'd figured would happen to dos eventually, but it never did. It actually did! This is exactly what I was trying to explain, this is the way Microsoft took, as this is what VMM32.VXD=DOS386.EXE does (a much overpowered EMM386.EXE). But Microsoft didn't sell this piece of software with MS-DOS, but with MS-Windows. Cheers, Aitor -- 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 myself agree with the first and third point. About the second, I'm not advocating for a different 32-bit OS (such as FreeDOS-32). I also agree that one first target would be the UEFI stuff. But at long term, I am of the opinion that VxDs are DOS drivers, as much as the classic DEVICE= drivers are, and that is a neat way of preserve running 16bit programs on a bubble and protected from the outside 32/64-bit world (and that in addition to CONFIG.SYS, has a file called SYSTEM.INI for configuration and listing of which drivers are loaded; and a SYSTEM.INI that has nothing to do with WIN.INI). If FreeDOS 2.0 is going to be purely and completely 16-bit, in what differs FreeDOS 2.0 from FreeDOS 1.3? Aitor PS: Btw, I continue to be a bit worried about [ www.japheth.de ], anyone? 2015-01-02 2:31 GMT+01:00 Jim Hall jh...@freedos.org: It seems clear a consensus is appearing, but I'll give folks another few days to chime in. That will give me time to continue on website cleanup things, anyway. :-) *What I think I'm hearing: (and I agree)* *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* Agree or disagree with these points? Did I miss anything? Other discussion? -- 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, Not only about kernels, but about the 16-bit DOS compiling options too. I think we talked about this in the past, and I think it'd make sense that FreeDOS 2.0 would be 386+. Aitor 2015-01-01 23:43 GMT+01:00 Mercury Thirteen mercury0x0...@gmail.com: Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Personally, I think that's acceptable and I'm sure Microsoft would've no doubt done the same thing by now had they not gone to Windows. There's no way they would still include the 8086 and 80186 in their modern MS-DOS, had they made one. -- 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
I think the FreeDOS 2.0 version should be a updated 16 bit kernel that can run in real mode by default and the freedos-32 stuff should merge with OSFree -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-1-2-and-2-0-roadmap-discussion-tp21529p21578.html Sent from the FreeDOS - Dev mailing list archive at Nabble.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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Well, I wasn't advocating that we leave behind our 16-bit roots altogether, because it is possible to still run 16- as well as 32-bit code on a 32-bit OS.Then again, if we go to a 32-bit kernel and still run 16-bit code... exactly what have we gained? Like I said before, I can see both sides of this debate. Keeping FreeDOS in the 16-bit realm will be the easiest thing to do and it won't make the project inferior or hinder us that much, even if we add modern features. On Fri, Jan 2, 2015 at 3:17 PM, Michael Brutman mbbrut...@brutman.com wrote: What's the difference between FreeDOS 1.1, 1.2 and 1.3? Bug fixes, updates to the user space packages, improvements to the installer, and possibly improvements to the packaging. I reject the argument that FreeDOS needs to evolve and leave its 16 bit roots behind, similar to the way MacOS did. MacOS exists for an entirely different reason - to sell hardware. FreeDOS is a much different project. We have more than enough work to do in user space than any of us are going to get done in the next decade. What exactly is the use case for a 32 bit FreeDOS? Do those use cases justify an investment in a 32 bit FreeDOS compared to using existing solutions? Where exactly are all of these developers that are going to create a 32 bit FreeDOS? -- 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
What's the difference between FreeDOS 1.1, 1.2 and 1.3? Bug fixes, updates to the user space packages, improvements to the installer, and possibly improvements to the packaging. I reject the argument that FreeDOS needs to evolve and leave its 16 bit roots behind, similar to the way MacOS did. MacOS exists for an entirely different reason - to sell hardware. FreeDOS is a much different project. We have more than enough work to do in user space than any of us are going to get done in the next decade. What exactly is the use case for a 32 bit FreeDOS? Do those use cases justify an investment in a 32 bit FreeDOS compared to using existing solutions? Where exactly are all of these developers that are going to create a 32 bit FreeDOS? -- 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 don't know how that can run in real mode by default differs from current situation. Maybe you mean that FreeDOS drops EMM386.EXE. Regards, Aitor 2015-01-02 20:47 GMT+01:00 sparky4 spar...@cock.li: I think the FreeDOS 2.0 version should be a updated 16 bit kernel that can run in real mode by default and the freedos-32 stuff should merge with OSFree -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-1-2-and-2-0-roadmap-discussion-tp21529p21578.html Sent from the FreeDOS - Dev mailing list archive at Nabble.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
Hi, On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com wrote: PS: Btw, I continue to be a bit worried about [ www.japheth.de ], anyone? http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html Also, dare I mention, the licensing is a bit ambiguous. Great if all you care about is freeware, lousy if you're a free software zealot. So don't expect many (if anybody) else to mirror it anywhere. -- 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 agree with everything -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-1-2-and-2-0-roadmap-discussion-tp21529p21580.html Sent from the FreeDOS - Dev mailing list archive at Nabble.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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
I agree -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-1-2-and-2-0-roadmap-discussion-tp21529p21585.html Sent from the FreeDOS - Dev mailing list archive at Nabble.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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
It wouldn't be only the speed increase, but the fact that we'd be modernizing FreeDOS as a whole. I think of it this way: What would Microsoft have done had they not gone exclusively to Windows? I am doubtless they would've migrated MS-DOS to a 32-bit platform years ago. If we were to do such a move, we would not only make the OS as fast as possible, but also open up roads to modern development tools and allow the running of apps made by a whole host of compilers - because not that many (in comparison) support a 16-bit target. We would make FreeDOS more attractive to programmers because their compiler would already have the means of generating appropriate code, they would have no 640 KB (or 1 MB or 1.5 MB...) RAM ceiling to contend with and they wouldn't have to worry about switching back and forth between protected mode and real mode to run their programs. The speed advantages which pure 32-bit would have over 16-bit + DPMI would not only be from eliminating the delays from entering and exiting protected mode and the associated memory copies, but also the more subtle details like variable limit checking and the elimination of the overhead incurred from having to work with the clumsy segment:offset addressing method. I have no tasks which I do right now which demand more speed, but my line of thought is that - if we're trying to take DOS where Microsoft didn't - then going the 32-bit route would be the way to go. On the other hand, there's the reality that, while they in all likelihood Microsoft would've gone to 32-bits... they never did. Their DOS was a 16-bit product and all the software built for it expects it to be that way. Keeping that tradition intact will do nothing to harm our project, and - as Mike said - there are plenty of other things we can do to modernize and improve the project as a whole, especially the userspace. And there's the naming issue: anything that takes us into the 32-bit world technically is no longer FreeDOS as we know it. On Thu, Jan 1, 2015 at 10:44 PM, Dave Pratt davidpr...@aol.com wrote: Mercury, It looks like your idea in terms of a benefit of a 32 bit FreeDOS is this: FreeDOS would suddenly be the most blazing fast DOS ever conceived. Fair ? Why do you think that pure 32 bit will be significantly faster than the current model of 16 bit plus DPMI ? (I suppose there is some buffer copy that takes place in a DOS extender for each INT 21 call ? Is that all we are trying to get rid of ? ) Why do you think yourself and other users need a faster DOS? Are there tasks you're doing now that are very slow ? Personally new hardware is so fast compared to what we had in the 1990s that I don't see a benefit for most users on any increases in speed, I'm curious to hear your experience. Are there other benefits you see to the 32 bit DOS? Thanks, Dave -- 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
FreeDOS is, by definition, a re-implementation of DOS. If you read the specification on the Wiki the kernel targets MS-DOS 3.3 and the applications target MS-DOS 6.22. There is no need to modernize FreeDOS. Anything 32 bit would be radically different and thus is a different project. IBM and Microsoft did not see a future with DOS and they knew that back fairly early on. The marketing literature and trade press at the time was talking about a multitasking version of DOS for the PC AT. OS/2 was the answer, but OS/2 1.x was horribly botched by requiring it to run on the 80286 processor and by both IBM and MS trying to work together. Let's talk about the roadmap. People are free to fork off and make a new project based on FreeDOS. No problem there. But once you break compatibility with existing applications, you lose a lot of your potential user base. And as soon as you go to 32 bits, you lose all of the early hardware. I think that we have enough to do to make the existing FreeDOS a pleasant operating system to install and use. And I think a lot of that work is in user space. We need a better installer. We need more (16 bit) applications. And I'm sure that some of our existing 16 bit utilities could use some modernization and freshening too. Look at mTCP as an example of what can be done to modernize a good class of applications (networking) and still do it in 16 bit code that does not break anybody. Or people can go off and work on a new 32 bit variant of DOS in the hopes that they'll attract more programmers and fresh applications to the new platform. The great news is that anybody can go off and do whatever they want to as this is all a hobbyist effort anyway. But lets stop calling it a discussion about the FreeDOS roadmap. Once it goes to 32 bits its not FreeDOS anymore. Copy the code and start again, but lets not confuse the two projects anymore. -- 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, That's my guess: 2015-01-02 0:05 GMT+01:00 cordat...@aol.com: If you take a look one of the links from Jim recently he states: But in an alternate reality, what would DOS had looked like if Microsoft *hadn't* moved to Windows? I think we get to define what that looks like. My guess is that if Windows (the GUI) hadn't existed, then DOS386.EXE would have been packed with MS-DOS, it would have never been renamed to WIN386.EXE or VMM32.VXD, and MS-DOS would have had a wonderful multitasker that allows you to switch between different MS-DOS sessions, and thus fully profit from the power of a 386. My guess is that the decision to pack DOS386.EXE with Windows (3.X+) and not with MS-DOS was a commercial one, to push the market into Windows, and not a technical one (just as the abilities of the NT kernel to run POSIX and OS/2 applications were underdeveloped). Commercially wise, but a pitty for software with such a huge potential :) Think for a second about what Microsoft, or any company would have done to continue DOS development ? They would have started by trying to understand what users would be doing with the new software. What kinds of things are users requesting that can't be done with MS-DOS 6.22 ? What could we do to increase market share for DOS compared to other operating systems? In my opinion, users usually like to run classic apps but profiting from new hardware's capabilities. 386 gives you a way to access huge amounts of memories and multitask, and that can be done in a 100% DOS flavour (as DOS386/VMM32 proves). But I am repeating my arguments from other mails, I hope I managed to explain my position this time :) Cheers, Aitor -- 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
That's why I suggest two kernels, 16 and 32 and make it switchable like through a boot up keywords like F7. -- -Chris Evans Computer Consultant, Systems Administrator, Programmer, PC technician Digitalatoll Solutions Group (Tawhaki Software) Cell. : 916-612-6904 | http://www.tawhakisoft.slyip.net/ Office: 916-382-9395 | http://www.digitalatoll.com/ Skype: chris.evans450 | http://norcalhost.com/ On Jan 2, 2015 5:24 PM, Ralf Quint freedos...@gmail.com wrote: On 1/1/2015 2:43 PM, Mercury Thirteen wrote: Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Absolutely NOT! 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
On 1/1/2015 7:15 PM, Mercury Thirteen wrote: We can add modern OS features (protected memory and multitasking are still quite doable) without jumping to 32-bit code. After all, there obviously already is a 32-bit FreeDOS project, and it wouldn't really make sense to have /two/ 32-bit versions of FreeDOS. I doubt that you will even see one (1) 32-bit version of FreeDOS. Whoever is seriously claiming on working on that just doesn't know what they will get themselves into. MS/PC/DR-/FreeDOS is at its very core 16bit/x86. You get yourself in one development hell if you try to change that. And what advantage does a 32bit FreeDOS supposed to have? What application would you run on it? 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Thank you Rugxulo! I always was somewhat concerned about such licensing issues, but the software looks pretty valuable! :) Aitor 2015-01-02 23:24 GMT+01:00 Rugxulo rugx...@gmail.com: Hi, On Fri, Jan 2, 2015 at 1:39 PM, Aitor Santamaría aitor...@gmail.com wrote: PS: Btw, I continue to be a bit worried about [ www.japheth.de ], anyone? http://web.archive.org/web/20140904175113/http://www.japheth.de/HX.html Also, dare I mention, the licensing is a bit ambiguous. Great if all you care about is freeware, lousy if you're a free software zealot. So don't expect many (if anybody) else to mirror it anywhere. -- 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
On 1/1/2015 2:43 PM, Mercury Thirteen wrote: Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Absolutely NOT! 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On 1/2/2015 2:28 PM, Mercury Thirteen wrote: It wouldn't be only the speed increase, but the fact that we'd be modernizing FreeDOS as a whole. I think of it this way: What would Microsoft have done had they not gone exclusively to Windows? I am doubtless they would've migrated MS-DOS to a 32-bit platform years ago. If we were to do such a move, we would not only make the OS as fast as possible, but also open up roads to modern development tools and allow the running of apps made by a whole host of compilers - because not that many (in comparison) support a 16-bit target. We would make FreeDOS more attractive to programmers because their compiler would already have the means of generating appropriate code, they would have no 640 KB (or 1 MB or 1.5 MB...) RAM ceiling to contend with and they wouldn't have to worry about switching back and forth between protected mode and real mode to run their programs. Sorry but I think you need to get real here. 32bit over 16bit brings pretty much no speed advantage at all for a DOS program. Today's CPUs are a factor of 60 faster then even the fastest 486 CPU at the end of the DOS era. And have more cache RAM than a system back then had even as total RAM. And that is magnitudes faster today then it was back then. A real 16 bit DOS program is screamingly fast these days, you will not gain any serious advantage by running in 32bit. The amount of memory available is a slight improvement, but then most likely just resulting in the improvement of software bloat as well... The speed advantages which pure 32-bit would have over 16-bit + DPMI would not only be from eliminating the delays from entering and exiting protected mode and the associated memory copies, but also the more subtle details like variable limit checking and the elimination of the overhead incurred from having to work with the clumsy segment:offset addressing method. Do you even remotely have an idea on how many function calls (INT21h) within DOS this is required/expected? Not to mention things like video both for INT10h or direct write access? I have no tasks which I do right now which demand more speed, but my line of thought is that - if we're trying to take DOS where Microsoft didn't - then going the 32-bit route would be the way to go. Sorry, but that way is just a road to nowhere. As you would loose the 100% application compatibility in a heartbeat... 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
I doubt that you will even see one (1) 32-bit version of FreeDOS. Whoever is seriously claiming on working on that just doesn't know what they will get themselves into. MS/PC/DR-/FreeDOS is at its very core 16bit/x86. You get yourself in one development hell if you try to change that. And what advantage does a 32bit FreeDOS supposed to have? What application would you run on it? I've detailed the advantages in several other emails, and so far as what applications would run on it... both traditional DOS apps and new 32-bit applications as well. What exactly would you mean by 32 bit kernel? What is the kernel? I always get the impression that people that mention stuff like this don't know how DOS works and take their inspiration from Linux or other, similar sized and focused OS... The kernel, in the case of MS-DOS, would be IO.SYS. For FreeDOS it's KERNEL.SYS - basically the core of the DOS, minus the interface shell. Do you even remotely have an idea on how many function calls (INT21h) within DOS this is required/expected? Not to mention things like video both for INT10h or direct write access? Yes, 114 in interrupt 0x21, not including the others in the 0x2x series which DOS uses. I'm sure there are some I'm missing, not to mention the video BIOS routines and such which you mention, so I would guess around two to three hundred functions total. That's actually not that many compared to other operating systems - the classic MacOS and Windows both have literally thousands of function calls and services. Sorry, but that way is just a road to nowhere. As you would loose the 100% application compatibility in a heartbeat... Compatibility would not necessarily be lost, as I've detailed in other emails as well. All that said, I have no problem with FreeDOS staying 16-bit. Perhaps Microsoft would not have integrated 32-bit support and just packaged their own extender, as Aitor noted. Regardless, we have an excellent piece of software capable of doing amazing things no matter how we choose to evolve it. I'm not fighting for one side of the argument or the other here, I'm just presenting my thoughts on either way the outcome could be. -- 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 Fri, 2 Jan 2015, Mercury Thirteen wrote: I've detailed the advantages in several other emails, and so far as what applications would run on it... both traditional DOS apps and new 32-bit applications as well. Might be trickier if you're talking about 16-bit apps that hit the metal. Even Win9x had a 16-bit DOS under the hood. The kernel, in the case of MS-DOS, would be IO.SYS. For FreeDOS it's KERNEL.SYS - basically the core of the DOS, minus the interface shell. More precisely: the MS-DOS kernel is split between IO.SYS (the DOS BIOS) and MSDOS.SYS (the BDOS). DR DOS maintains this distinction, using the names from PC DOS (IBMBIO.COM and IBMDOS.COM respectively). It is a distinction inherited from CP/M. -uso. -- 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 1/2/2015 12:30 PM, Mercury Thirteen wrote: Well, I wasn't advocating that we leave behind our 16-bit roots altogether, because it is possible to still run 16- as well as 32-bit code on a 32-bit OS.Then again, if we go to a 32-bit kernel and still run 16-bit code... exactly what have we gained? Like I said before, I can see both sides of this debate. What exactly would you mean by 32 bit kernel? What is the kernel? I always get the impression that people that mention stuff like this don't know how DOS works and take their inspiration from Linux or other, similar sized and focused OS... 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Vote noted! :) On Fri, Jan 2, 2015 at 8:23 PM, Ralf Quint freedos...@gmail.com wrote: On 1/1/2015 2:43 PM, Mercury Thirteen wrote: Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Absolutely NOT! 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
On 1/2/2015 3:29 PM, Michael Brutman wrote: The great news is that anybody can go off and do whatever they want to as this is all a hobbyist effort anyway. But lets stop calling it a discussion about the FreeDOS roadmap. Once it goes to 32 bits its not FreeDOS anymore. Copy the code and start again, but lets not confuse the two projects anymore. +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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Fri, Jan 2, 2015 at 6:22 PM, Aitor Santamaría aitor...@gmail.com wrote: Thank you Rugxulo! +1 :) -- 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 1/2/2015 7:36 PM, Mercury Thirteen wrote: I doubt that you will even see one (1) 32-bit version of FreeDOS. Whoever is seriously claiming on working on that just doesn't know what they will get themselves into. MS/PC/DR-/FreeDOS is at its very core 16bit/x86. You get yourself in one development hell if you try to change that. And what advantage does a 32bit FreeDOS supposed to have? What application would you run on it? I've detailed the advantages in several other emails, and so far as what applications would run on it... both traditional DOS apps and new 32-bit applications as well. Well, those traditional DOS apps, that's the part I seriously doubt. New 32 bit applications, well, we shall see... Do you even remotely have an idea on how many function calls (INT21h) within DOS this is required/expected? Not to mention things like video both for INT10h or direct write access? Yes, 114 in interrupt 0x21, not including the others in the 0x2x series which DOS uses. I'm sure there are some I'm missing, not to mention the video BIOS routines and such which you mention, so I would guess around two to three hundred functions total. That's actually not that many compared to other operating systems - the classic MacOS and Windows both have literally thousands of function calls and services. But how to you intend to solve this? How to you interpret a Seg:Ofs given in a fact into your 32 bit kernel flat space? How you decide which information to return? Sorry, but that way is just a road to nowhere. As you would loose the 100% application compatibility in a heartbeat... Compatibility would not necessarily be lost, as I've detailed in other emails as well. Sorry, I am working with DOS far too long as to see where you detailed anything... FreeDOS should be and stay just what its original intention is/was, providing an Open Source clone of the discontinued and closed source 16 bit MS-DOS 6.22. If anyone wants to improve the odds of getting updated or newer software for it, IMHO the project needs to be more open to software (tools) that were written and used at the time DOS was mainstream, even if that means that software is only freely (but legally) available, like the old Borland compilers. Then I am sure you will be able to get some more traction again, not by re-using Linux oriented software and tools like GCC. And even OpenWatcom seems like a dead end now after it seems to finally have stalled, not only in terms of DOS. Still works though... 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Have two kernels a 16/32bit for legacy cpus and a 64bit kernel that can use 4gb+ addressing of the ram. -- -Chris Evans Computer Consultant, Systems Administrator, Programmer, PC technician Digitalatoll Solutions Group (Tawhaki Software) Cell. : 916-612-6904 | http://www.tawhakisoft.slyip.net/ Office: 916-382-9395 | http://www.digitalatoll.com/ Skype: chris.evans450 | http://norcalhost.com/ On Jan 1, 2015 6:12 AM, Aitor Santamaría aitor...@gmail.com wrote: Hello Jim and all, I like the idea of having two releases of FreeDOS with different goals: a FreeDOS 1.2 as an update of current FreeDOS 1.1, in order to have something on a short term as an update of current distribution. As for FreeDOS 2.0, I share my ideas here. I agree that it should be a big leap forward on the development of FreeDOS, and as my biggest worries are the disappearing of BIOS and 16-bit mode, they are about moving to 32-bit. Three possibilities: (1) My favourite would be to develop something similar to Microsoft's VMM32.VXD: a 32-bit kernel that would allow you to run different 16-bit/32-bit VMs, with expansion by 32-bit drivers (the VXD) that emulate BIOS and control the VM interoperativity. With some help (multithreading), and some software to run EXE-PE's and DLL's, FreeDOS could expand not only to running DOS-16bit apps, but also legacy Win32 apps (e.g. console ones). With quite an effort, this scheme may be extended to run Win16, POSIX (minGW?) or OS/2 apps. Booting could start with 16-bit, and then execute the extender, or alternatively, set a bootstrap sequence (set by SYS) to directly run the extender. The disadvantage is that this is quite a lot of work, I think Japeth has moved on this way, so there's something where to start. The advantage is that DOS would retain much of its flavour, and continue the tradition to run legacy Microsoft software. (2) A second option would be that, instead of a new 32-bit kernel, we use Linux: you boot a Linux without anything extra, and that simply runs DOSEMU (or different consoles with different DOSEMU's, in order to emulate to have different VM's). My plan was to pick a Linux distribution and start stripping it down to simply boot DOSEMU. The advantage is that FreeDOS would live as long as Linux lives (and no matter if it moves to 64-bit), that is, forever. The disadvantage is that it would mean moving to a native POSIX world, it may loose some of the DOS flavour, and everything that does not work on DOSEMU, would not run on FreeDOS 2.0. (3) Go the FreeDOS-32 way that you mentioned. The advantage is the total freedom and unconstrained start for a 32-bit kernel, based on what's there. The disadvantage is that it may also require a lot of work, and that it may be to start a work compatible with nothing that already exists. I just thought I should mention them before entering a critical way that requires a lot of work. Cheers and happy 2015 to everyone. Aitor 2014-12-31 23:51 GMT+01:00 Jim Hall jh...@freedos.org: Mike pointed out that the FreeDOS Road Map http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map (wiki) is out of date and short on details and suggested a broad discussion on the road map, get consensus and have it updated. I figured we should start a separate discussion thread about that. First, a little history on the road map: When I started FreeDOS in 1994, the goal was to create a free version of DOS, compatible with MS-DOS. (original PD-DOS announcement https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ) (original Free-DOS manifesto https://groups.google.com/d/msg/comp.os.msdos.apps/W6MuhF__R9s/MgdzBrlanTwJ ) That aim remained essentially the same for a long time. And I believe we met that with version 1.0 a few years ago. FreeDOS 1.1 was an update to FreeDOS 1.0, so things didn't really change there. In 2009 http://www.freedos.org/jhall/blog/?id=20090511-192954, I briefly stepped away from FreeDOS to focus on a graduate program (I ended up changing jobs instead, and didn't do the M.S. program until a few years later). During that time, Pat Villani stepped in as project coordinator. Pat wanted to do something to spur development, so in 2010 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845 he wrote the first version of the FreeDOS Road Map (see old version http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845 ). In 2011 http://www.freedos.org/jhall/blog/?id=20110502-164858, Pat's health was getting worse, so I came back as project coordinator. Nothing had been done on the road map, so I replaced it with a copy/paste from a blog post I had written earlier (see blog post http://www.freedos.org/jhall/blog/?id=20110502-164858) until I could go back and update it for real later on. A few days ago, Harold (aka Mercury Thirteen) mentioned the road map on the wiki. I realized I never updated the road map, so I
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hello Jim and all, I like the idea of having two releases of FreeDOS with different goals: a FreeDOS 1.2 as an update of current FreeDOS 1.1, in order to have something on a short term as an update of current distribution. As for FreeDOS 2.0, I share my ideas here. I agree that it should be a big leap forward on the development of FreeDOS, and as my biggest worries are the disappearing of BIOS and 16-bit mode, they are about moving to 32-bit. Three possibilities: (1) My favourite would be to develop something similar to Microsoft's VMM32.VXD: a 32-bit kernel that would allow you to run different 16-bit/32-bit VMs, with expansion by 32-bit drivers (the VXD) that emulate BIOS and control the VM interoperativity. With some help (multithreading), and some software to run EXE-PE's and DLL's, FreeDOS could expand not only to running DOS-16bit apps, but also legacy Win32 apps (e.g. console ones). With quite an effort, this scheme may be extended to run Win16, POSIX (minGW?) or OS/2 apps. Booting could start with 16-bit, and then execute the extender, or alternatively, set a bootstrap sequence (set by SYS) to directly run the extender. The disadvantage is that this is quite a lot of work, I think Japeth has moved on this way, so there's something where to start. The advantage is that DOS would retain much of its flavour, and continue the tradition to run legacy Microsoft software. (2) A second option would be that, instead of a new 32-bit kernel, we use Linux: you boot a Linux without anything extra, and that simply runs DOSEMU (or different consoles with different DOSEMU's, in order to emulate to have different VM's). My plan was to pick a Linux distribution and start stripping it down to simply boot DOSEMU. The advantage is that FreeDOS would live as long as Linux lives (and no matter if it moves to 64-bit), that is, forever. The disadvantage is that it would mean moving to a native POSIX world, it may loose some of the DOS flavour, and everything that does not work on DOSEMU, would not run on FreeDOS 2.0. (3) Go the FreeDOS-32 way that you mentioned. The advantage is the total freedom and unconstrained start for a 32-bit kernel, based on what's there. The disadvantage is that it may also require a lot of work, and that it may be to start a work compatible with nothing that already exists. I just thought I should mention them before entering a critical way that requires a lot of work. Cheers and happy 2015 to everyone. Aitor 2014-12-31 23:51 GMT+01:00 Jim Hall jh...@freedos.org: Mike pointed out that the FreeDOS Road Map http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map (wiki) is out of date and short on details and suggested a broad discussion on the road map, get consensus and have it updated. I figured we should start a separate discussion thread about that. First, a little history on the road map: When I started FreeDOS in 1994, the goal was to create a free version of DOS, compatible with MS-DOS. (original PD-DOS announcement https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ) (original Free-DOS manifesto https://groups.google.com/d/msg/comp.os.msdos.apps/W6MuhF__R9s/MgdzBrlanTwJ ) That aim remained essentially the same for a long time. And I believe we met that with version 1.0 a few years ago. FreeDOS 1.1 was an update to FreeDOS 1.0, so things didn't really change there. In 2009 http://www.freedos.org/jhall/blog/?id=20090511-192954, I briefly stepped away from FreeDOS to focus on a graduate program (I ended up changing jobs instead, and didn't do the M.S. program until a few years later). During that time, Pat Villani stepped in as project coordinator. Pat wanted to do something to spur development, so in 2010 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845 he wrote the first version of the FreeDOS Road Map (see old version http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845). In 2011 http://www.freedos.org/jhall/blog/?id=20110502-164858, Pat's health was getting worse, so I came back as project coordinator. Nothing had been done on the road map, so I replaced it with a copy/paste from a blog post I had written earlier (see blog post http://www.freedos.org/jhall/blog/?id=20110502-164858) until I could go back and update it for real later on. A few days ago, Harold (aka Mercury Thirteen) mentioned the road map on the wiki. I realized I never updated the road map, so I tacked a THIS PAGE IS OUT OF DATE notice at the top of the wiki entry. More recently, Chelson announced on our Facebook group https://www.facebook.com/groups/freedos/ his kickstarter project to fund development of FreeDOS-32, with the hope that this kernel could be part of FreeDOS 2.0. I shared his announcement on the website and on freedos-devel this morning. I think that brings us to this discussion. :-) *My thoughts on FreeDOS 1.2 and FreeDOS 2.0:* I think the next distribution will be
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hello! Notes below. BTW, Whatever happened to Japheth's pages?? Is server down? (see JEMM's LSM for URL's). Aitor 2015-01-01 19:31 GMT+01:00 Mercury Thirteen mercury0x0...@gmail.com: 1 - I like the idea of being able to run apps for multiple other OSes, but I think that ability should fall to a program running atop FreeDOS, not to the FreeDOS kernel itself. That would be a very cool feature, but the amount of code needed to add it to the kernel would probably be too large for us to continue to be viable in the tiny memory space market. FreeDOS should do one thing (be as DOS-like as possible, not only in its interface, but in its memory footprint) and do it very, very well. It would be better to make individual apps to serve as emulators for foreign apps than to have this feature build in. And I guess, in a way, these emulators which run atop FreeDOS to support PE EXEs, DLLs and console Windows apps would serve as the VXD-like drivers which you specify, so my point may be moot here - maybe we're both speaking about the same things, only using different words. lol I don't want to give the impression that the main idea is to run other kinds of executables. It is a nice addition, but my main interest is to run DOS itself, and DOS applications, maintaining 100% compatibility. The most wonderful stuff that could be done, in my opinion, goes along the experiment that Schulman does in Unauthorized Windows95, and that I'd love to see somehow some day. IIRC: - he wrote an example DOS program that requests memory via XMS. For me, XMS (or a XMS manager) is as much a part of DOS as is, say, the redirector. - he renamed KRNL386.EXE (the main Windows executable) to something else, and copied COMMAND.COM into KRNL386.EXE - then he ran WIN /3, the program that runs the extender (VMM32.VXD) and then uses KRNL386.EXE as shell, this is, COMMAND. - he entered on a magic world of having pure MS-DOS inside a VMM. Everything ran as MS-DOS does, but when he ran the example program, he could allocate more XMS than the existing physical memory, and all that because the underlying VMM32.VXD+VSD's were doing the virtual memory magic. Pure MS-DOS, inside the most DOS-compatible VMM implementation that one can get. The book also mentions that in some Windows versions, the extender was called DOS386.EXE, instead of VMM32.VXD, quite meaningful. In my opinion, DOS386.EXE is more an MS-DOS piece than a MS-Windows piece: Windows was merely a fancy (and complex) GUI DOS application ran on top of DOS386, that was also coded to run on top of NTOSKRNL. One of the (IMHO) brightest (and latest) additions from Microsoft to MS-DOS, that I suppose that was coded after EMM386.EXE. 2 - I'd say including Linux - or any other OS, for that matter - makes this project pointless. We should make FreeDOS its own standalone OS, not dependent on any other package, emulator or OS. This will give our users the best possible experience and greatly simplify development and debugging because we control all our own code. As you point out, we'd lose some (a lot?) of the DOS flavor in going this route. I don't see it as you do. First, I guess many FreeDOS users actually use it on DOSEmu, or any other VMs, less on bare metal. It is the same FreeDOS in both cases, and it has always been out of the scope of FreeDOS project: in the latter case, FreeDOS relies on BIOS manufacturers. In the former, I simply mean to outsource it to the Linux project ;) You never care how to deal with multiple drivers in a 32/64 bit world: as long as DOSEmu translates the Linux stuff into BIOS-compatible stuff, we are safe ;) 3 - While it would be great to be able to make a DOS from scratch based on modern technology, I fear we'd lose too much in the way of compatibility this way, and we don't want to do that. Just think of the possibilities, though... :) lol I think I agree with you on point number one. That seems to correlate with my thoughts as the best (e.g. most compatible, flexible and powerful) way to go. What I dislike of the third approach, is that sooner or later, you will have to standarise and tell how to write drivers for such a FreeDOS-32 project. The option (1) says: don't make it up, just write good old VxD's. I don't know the internals of FreeDOS-32, but maybe (1) and (3) are not exclusive from each other: I seem to remember that at some point, the FreeDOS-32 guys did a 32-bit FAT driver. Perhaps that could be turned into VFAT/VREDIR... Cheers, Aitor -- 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___
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
I too would love to see a fully modern DOS. My thoughts for features added in FreeDOS 2.0: The processor is shifted into (and stays in, at least as much as possible) protected mode, providing 32-bit addressing. Memory therefore would become a flat 4GB RAM address space, allowing for advanced features like preemptive multitasking with protected memory. While researching these features for addition to my GUI, I came up with an approach which I think will maintain backwards compatibility. Each newly spawned .EXE gets its own copy of the lower 1 meg of RAM upon entry, complete with its own BIOS trap table, video RAM space and so on. This way each application has everything it expects to have - all while running in protected mode. The only downside is that each new app which gets run (beyond the first one) takes up a whole 1 or 1.5 megs of RAM, but the benefits far outweigh that small fact. For users who have limited RAM (and therefore can't multitask anyway) the system behaves like it always has, and those with an extra 32 megs sitting in their case just bought themselves the power to run more apps. This way nothing has to change compatibility-wise, and FreeDOS remains small, powerful and fast for those who rely on it for these traits. For the power users, it has not just those things but also the potential for much more. Under this model, each app is isolated from all others and essentially thinks it's the only one in the system. Inter-application communication is still possible through a software interrupt for those newer apps which expect it to be there, but the older ones remain blissfully ignorant. When the app closes and control would normally return to command.com, the kernel instead disposes of the RAM that app was using and continues running all the others. Segment-offset addressing would still work as intended, but maybe with a slight speed hit since that format would have to be remapped to the actual load address of the app. The memory allocated to these apps would use double-indirect addressing so that apps can be moved around in memory while they execute, allowing the kernel to optimize memory usage as needed. The standard BIOS API would inevitably need to be rewritten in 32-bit clean code. This would most likely be a complete custom rewrite of the usual BIOS services with a set of redirectors for older programs which are nothing more than simple dispatchers which resolve memory addresses and pass control along to the 32-bit BIOS services. The speed hit incurred in doing this would be slight compared to actually shifting back into real mode every time you need to do something with 16-bit code, as it seems most DOS extenders do. The key to speed is to keep the processor in protected mode as much as possible. So far as supporting modern hardware at the OS level, this is a non-issue in my mind. Older DOS apps won't expect it to be there, and newer ones will have some kind of driver framework at that point which they can rely on for access. Like Marc said in his Novell letter, you can promise the world as long as you leave hooks to add the world in later. We could implement some kind of hardware table / driver model, but leave it up to future versions to decide the intricacies of how these things would work. To me, that looks like a great job for FreeDOS 3.0. :) What we *absolutely should not do* is keep adding all manner of features to the kernel. I'm looking at you, Linux. lol Seriously, though, our goal will be to keep FreeDOS lightweight, fast and compact. We have what has to be one of the tiniest kernels in existence, and we should keep it that way. A simplification of this technique could be summarized as merely moving some parts of a DOS extender into the kernel itself, but cleaning and streamlining things along the way. Really the single worst thing about doing this would be a modest increase in kernel size, but for all the modern features FreeDOS would gain I'd say that's *well* worth it. -- 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, Aitor :) Just touching on some of your ideas: 1 - I like the idea of being able to run apps for multiple other OSes, but I think that ability should fall to a program running atop FreeDOS, not to the FreeDOS kernel itself. That would be a very cool feature, but the amount of code needed to add it to the kernel would probably be too large for us to continue to be viable in the tiny memory space market. FreeDOS should do one thing (be as DOS-like as possible, not only in its interface, but in its memory footprint) and do it very, very well. It would be better to make individual apps to serve as emulators for foreign apps than to have this feature build in. And I guess, in a way, these emulators which run atop FreeDOS to support PE EXEs, DLLs and console Windows apps would serve as the VXD-like drivers which you specify, so my point may be moot here - maybe we're both speaking about the same things, only using different words. lol I'd definitely stay away from switching modes back and forth between protected (32-bit) mode and real (16-bit) mode constantly during the user's session. This wastes valuable CPU cycles, and users running this new version on older hardware will definitely feel the speed hit. We should shift to protected mode as early as possible or feasible, after any kind of setup we need to do in real mode, then try if at all possible to *stay* in protected mode and never come out; this will allow for top-notch speeds. We should design the new version as if we were just as limited in memory and speed as we've always been. 2 - I'd say including Linux - or any other OS, for that matter - makes this project pointless. We should make FreeDOS its own standalone OS, not dependent on any other package, emulator or OS. This will give our users the best possible experience and greatly simplify development and debugging because we control all our own code. As you point out, we'd lose some (a lot?) of the DOS flavor in going this route. 3 - While it would be great to be able to make a DOS from scratch based on modern technology, I fear we'd lose too much in the way of compatibility this way, and we don't want to do that. Just think of the possibilities, though... :) lol I think I agree with you on point number one. That seems to correlate with my thoughts as the best (e.g. most compatible, flexible and powerful) way to go. -- 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
If you take a look one of the links from Jim recently he states: But in an alternate reality, what would DOS had looked like if Microsoft hadn't moved to Windows? I think we get to define what that looks like. Think for a second about what Microsoft, or any company would have done to continue DOS development ? They would have started by trying to understand what users would be doing with the new software. What kinds of things are users requesting that can't be done with MS-DOS 6.22 ? What could we do to increase market share for DOS compared to other operating systems? While it's certainly fun to think about all kinds of cool stuff .. ultimately it comes down to what problem are we trying to solve? I've read only one use case in the discussion so far: a user has a PC with UEFI BIOS and we want to boot DOS. This may be a non-issue as others have discussed, but it's a specific use case that some users might be interested in. So who can articulate a use case or user story about what they want to do with a FreeDOS 32 or whatever it might be called ? I have my own user story I'll share in a bit. Dave -- 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 seems clear a consensus is appearing, but I'll give folks another few days to chime in. That will give me time to continue on website cleanup things, anyway. :-) *What I think I'm hearing: (and I agree)* *- FreeDOS 1.2 should be an update/refresh from FreeDOS 1.1. No major changes. Improved installer is a good idea.* *- FreeDOS 2.0 should be 16-bit. Make FreeDOS feel more modern, but keep it DOS. We can improve the userspace. Keep supporting old PCs, but support new hardware where we can. UEFI may be tricky (see SeaBIOS discussion).* *- If FreeDOS-32 will break DOS application compatibility, it should not use the FreeDOS name.* Agree or disagree with these points? Did I miss anything? Other discussion? -- 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 Thu, 1 Jan 2015, Mercury Thirteen wrote: Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Personally, I think that's acceptable and I'm sure Microsoft would've no doubt done the same thing by now had they not gone to Windows. There's no way they would still include the 8086 and 80186 in their modern MS-DOS, had they made one. Wouldn't that defeat the point of it being *DOS*, though? -uso. -- 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
Speaking of multiple kernels, would it be acceptable to require a minimum hardware platform for a new version of FreeDOS? Could we exclude the pre-386 crowd without backlash? Personally, I think that's acceptable and I'm sure Microsoft would've no doubt done the same thing by now had they not gone to Windows. There's no way they would still include the 8086 and 80186 in their modern MS-DOS, had they made one. -- 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
[Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Mike pointed out that the FreeDOS Road Map http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map (wiki) is out of date and short on details and suggested a broad discussion on the road map, get consensus and have it updated. I figured we should start a separate discussion thread about that. First, a little history on the road map: When I started FreeDOS in 1994, the goal was to create a free version of DOS, compatible with MS-DOS. (original PD-DOS announcement https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ) (original Free-DOS manifesto https://groups.google.com/d/msg/comp.os.msdos.apps/W6MuhF__R9s/MgdzBrlanTwJ ) That aim remained essentially the same for a long time. And I believe we met that with version 1.0 a few years ago. FreeDOS 1.1 was an update to FreeDOS 1.0, so things didn't really change there. In 2009 http://www.freedos.org/jhall/blog/?id=20090511-192954, I briefly stepped away from FreeDOS to focus on a graduate program (I ended up changing jobs instead, and didn't do the M.S. program until a few years later). During that time, Pat Villani stepped in as project coordinator. Pat wanted to do something to spur development, so in 2010 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845 he wrote the first version of the FreeDOS Road Map (see old version http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845). In 2011 http://www.freedos.org/jhall/blog/?id=20110502-164858, Pat's health was getting worse, so I came back as project coordinator. Nothing had been done on the road map, so I replaced it with a copy/paste from a blog post I had written earlier (see blog post http://www.freedos.org/jhall/blog/?id=20110502-164858) until I could go back and update it for real later on. A few days ago, Harold (aka Mercury Thirteen) mentioned the road map on the wiki. I realized I never updated the road map, so I tacked a THIS PAGE IS OUT OF DATE notice at the top of the wiki entry. More recently, Chelson announced on our Facebook group https://www.facebook.com/groups/freedos/ his kickstarter project to fund development of FreeDOS-32, with the hope that this kernel could be part of FreeDOS 2.0. I shared his announcement on the website and on freedos-devel this morning. I think that brings us to this discussion. :-) *My thoughts on FreeDOS 1.2 and FreeDOS 2.0:* I think the next distribution will be FreeDOS 1.2 because I want to reserve 2.0 for a major shift in how FreeDOS software is organized and what we include. I'm currently looking at the packages we list on the Software List, so maybe we'll get to 2.0 soon - but I think it's safe to assume the next FreeDOS distribution will be 1.2 and the one after that would be 2.0. *My thoughts on FreeDOS 1.2:* FreeDOS 1.2 is basically an update from FreeDOS 1.1. The biggest change is probably the installer: It should be very simple, very straightforward. FreeDOS isn't very big or complex, so it doesn't make sense to have a lot of install options. The current install process (FreeDOS 1.1) has a lot of steps to it. I think we could simplify this a bit. I'm not sure about the full steps for the install process, but to brainstorm something, here's a sketched out plan: 1. *Boot the FreeDOS Install CDROM.* This is basically a live FreeDOS, which happens to boot into an automated install process. - If you Exit the process at any time, you go back to a DOS prompt. (This is useful for people who just want to run FreeDOS from CD without installing it.) 2. *Does the C: drive exist?* - If not, prompt the user to run FDISK. Reboot to re-read the partition table. 3. *Is the C: drive usable?* - If not, prompt the user to run FORMAT. 4. *Start the INSTALL program.* 5. *Run SYS to make the C: drive bootable.* 6. *Do any follow-up steps* (such as creating a default CONFIG.SYS and AUTOEXEC.BAT, set language, etc). 7. *Done* *My thoughts on FreeDOS 2.0:* I'd like to see a modernized version of DOS. This might be as ambitious as Marc Perkel mentioned in his 1991 letter to his Novell bosses about a modern DOS, which he called NovOS (read NovOS letter http://Marc Perkel). Or it could be something less ambitious, basically a modernization of the FreeDOS userspace (utilities, etc) while keeping the original DOS kernel. I haven't used FreeDOS-32 but if it supports classic DOS programs on modern systems, while adding new and useful features, I would support using that kernel in FreeDOS 2.0. (I said this on Facebook, too https://www.facebook.com/groups/freedos/permalink/10152599941377887/?comment_id=10152600011617887offset=0total_comments=27.) Above all, application compatibility is 100% important. FreeDOS 2.0 needs to run applications written for MS-DOS. Thoughts? -- 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
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Looks like I forgot to make the read NovOS letter into a link, so here is the URL: http://www.ctyme.com/dri2.htm On Wed, Dec 31, 2014 at 4:51 PM, Jim Hall jh...@freedos.org wrote: Mike pointed out that the FreeDOS Road Map http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map (wiki) is out of date and short on details and suggested a broad discussion on the road map, get consensus and have it updated. I figured we should start a separate discussion thread about that. First, a little history on the road map: When I started FreeDOS in 1994, the goal was to create a free version of DOS, compatible with MS-DOS. (original PD-DOS announcement https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ) (original Free-DOS manifesto https://groups.google.com/d/msg/comp.os.msdos.apps/W6MuhF__R9s/MgdzBrlanTwJ ) That aim remained essentially the same for a long time. And I believe we met that with version 1.0 a few years ago. FreeDOS 1.1 was an update to FreeDOS 1.0, so things didn't really change there. In 2009 http://www.freedos.org/jhall/blog/?id=20090511-192954, I briefly stepped away from FreeDOS to focus on a graduate program (I ended up changing jobs instead, and didn't do the M.S. program until a few years later). During that time, Pat Villani stepped in as project coordinator. Pat wanted to do something to spur development, so in 2010 http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845 he wrote the first version of the FreeDOS Road Map (see old version http://www.freedos.org/wiki/index.php?title=FreeDOS_Road_Mapoldid=845). In 2011 http://www.freedos.org/jhall/blog/?id=20110502-164858, Pat's health was getting worse, so I came back as project coordinator. Nothing had been done on the road map, so I replaced it with a copy/paste from a blog post I had written earlier (see blog post http://www.freedos.org/jhall/blog/?id=20110502-164858) until I could go back and update it for real later on. A few days ago, Harold (aka Mercury Thirteen) mentioned the road map on the wiki. I realized I never updated the road map, so I tacked a THIS PAGE IS OUT OF DATE notice at the top of the wiki entry. More recently, Chelson announced on our Facebook group https://www.facebook.com/groups/freedos/ his kickstarter project to fund development of FreeDOS-32, with the hope that this kernel could be part of FreeDOS 2.0. I shared his announcement on the website and on freedos-devel this morning. I think that brings us to this discussion. :-) *My thoughts on FreeDOS 1.2 and FreeDOS 2.0:* I think the next distribution will be FreeDOS 1.2 because I want to reserve 2.0 for a major shift in how FreeDOS software is organized and what we include. I'm currently looking at the packages we list on the Software List, so maybe we'll get to 2.0 soon - but I think it's safe to assume the next FreeDOS distribution will be 1.2 and the one after that would be 2.0. *My thoughts on FreeDOS 1.2:* FreeDOS 1.2 is basically an update from FreeDOS 1.1. The biggest change is probably the installer: It should be very simple, very straightforward. FreeDOS isn't very big or complex, so it doesn't make sense to have a lot of install options. The current install process (FreeDOS 1.1) has a lot of steps to it. I think we could simplify this a bit. I'm not sure about the full steps for the install process, but to brainstorm something, here's a sketched out plan: 1. *Boot the FreeDOS Install CDROM.* This is basically a live FreeDOS, which happens to boot into an automated install process. - If you Exit the process at any time, you go back to a DOS prompt. (This is useful for people who just want to run FreeDOS from CD without installing it.) 2. *Does the C: drive exist?* - If not, prompt the user to run FDISK. Reboot to re-read the partition table. 3. *Is the C: drive usable?* - If not, prompt the user to run FORMAT. 4. *Start the INSTALL program.* 5. *Run SYS to make the C: drive bootable.* 6. *Do any follow-up steps* (such as creating a default CONFIG.SYS and AUTOEXEC.BAT, set language, etc). 7. *Done* *My thoughts on FreeDOS 2.0:* I'd like to see a modernized version of DOS. This might be as ambitious as Marc Perkel mentioned in his 1991 letter to his Novell bosses about a modern DOS, which he called NovOS (read NovOS letter). Or it could be something less ambitious, basically a modernization of the FreeDOS userspace (utilities, etc) while keeping the original DOS kernel. I haven't used FreeDOS-32 but if it supports classic DOS programs on modern systems, while adding new and useful features, I would support using that kernel in FreeDOS 2.0. (I said this on Facebook, too https://www.facebook.com/groups/freedos/permalink/10152599941377887/?comment_id=10152600011617887offset=0total_comments=27.) Above all, application compatibility is 100% important. FreeDOS 2.0 needs to run applications written for MS-DOS.
