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] Kickstarter project for FreeDOS 2.0
You can also buy a copy at MacMall for $2 [0]. [0] http://www.macmall.com/p/HP-Operating-Systems/product~dpno~13045035~pdp.igfhgha On Wed, Dec 31, 2014 at 8:52 PM, Michael Brutman mbbrut...@brutman.com wrote: Somebody should talk to HP and see what FreeDOS 2.0 includes. They are already shipping machines that support it: http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04027658DocLang=endocLocale=en_USjumpid=reg_r1002_usen_c-001_title_r0001 On a more serious note, somebody should try to correct them ... On Wed, Dec 31, 2014 at 4:27 PM, Ralf Quint freedos...@gmail.com wrote: On 12/31/2014 4:22 PM, Jim Hall wrote: It's not my kickstarter project, but I'll watch and see what happens. I agree that FreeDOS-32 is a tough prospect. As you can guess from my other post, I'm very concerned that they can maintain any application compatibility while adding modern hardware support. If they can't keep compatibility, it's a dead end. But if they can, it's worth looking at. Given that I am working/playing/programming with DOS since December 1981, I simply don't see how they can possibly achieve this, unless they produce their own reincarnation of something Linux-like and then provide a VM to run 16bit DOS. And in that case, you can use a VM on Linux to begin with. Or on Windows or OS/X, or any other OS that supports a VM... Even NovOS (also another post) was a tough sell to Novell, because it hoped to provide backwards compatibility while offering a whole new API to do new stuff. It sounds great until you try to do it. Well, 1991 would have been at a time well before Linux had gone mainstream and you could argue that the folks at Novell had already seen the writing on the wall... 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 -- 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] Working on FreeDOS 1.2
One thing I'd like to see in the next FreeDOS is a better installer. Installer should be writable to a USB stick or be bootable and runnable from a disk image; there is a rather outdated FreeDOS runnable quasi-floppy image on the System Rescue CD, though this image has no installer. I would like to see an installer (not necessarily bootable) that could run from Linux or FreeBSD, since many computer users these days have no DOS system, and running from Linux or FreeBSD would give the user more control than booting FreeDOS and not knowing which partition or disk is which. I have big hard drives, 3 TB or bigger, partitioned GPT, so the only place I could install FreeDOS to is a USB stick. Even on a modern system, FreeDOS can be useful for hardware diagnostic tools or BIOS/UEFI flash update. 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
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] Kickstarter project for FreeDOS 2.0
Not that I all of a sudden want to jump the bandwagon, but is he planning on hiring current/past FreeDOS developers at least? - Oorspronkelijk bericht - Van: Jim Hall jh...@freedos.org Aan: freedos-devel@lists.sourceforge.net Verzonden: Woensdag 31 december 2014 17:12:57 Onderwerp: [Freedos-devel] Kickstarter project for FreeDOS 2.0 Chelson Aitcheson has just started an independent Kickstarter project to fund development for FreeDOS-32, in support of a FreeDOS 2.0 distribution. I will also post a note about this on the FreeDOS website, but I wanted to share a link here for those who wanted to contribute. https://www.kickstarter.com/projects/1597889412/freedos-20-32-bit The Kickstarter aims to raise $2,500 by Thursday, January 29 2015. Chelson's goal is to hire public developers through freelancer.com to improve FreeDOS-32. If FreeDOS-32 can be significantly improved, Chelson hopes it will become part of mainline FreeDOS. I'll add that 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 that kernel update in FreeDOS 2.0. -- 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
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
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
Just to put in my own two cents. The lastest happening thing is all about open source hardware. Open source operating systems are so 2000. Intel has recently released a number of x86 based boards. With a simple operating system like DOS you could do all sorts of hardware things directly, without having to go through all the hassle of installing, updating and maintaining a full linux system. - Oorspronkelijk bericht - Van: cordat...@aol.com Aan: freedos-devel@lists.sourceforge.net Verzonden: Woensdag 31 december 2014 20:02:57 Onderwerp: [Freedos-devel] Kickstarter project for FreeDOS 2.0 I'm curious what the specific uses are being proposed for FreeDOS-32 ? The kickstarter site mentions supporting DJGPP compiled programs which use DPMI. This is already supported in FreeDOS. It further mentions hard real time and threading. There are already user-space threading packages available ( freebie: Erick Engelke's ERTOS) for FreeDOS. What is it that the developers of this project want to do that can't be done with FreeDOS or other existing OS ? -- 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
