Re: [Freedos-devel] Google Summer of Code?
Hi Liam, > "All" it needs is a memory manager that can start as a 32-bit process, > set up a few interrupts -- INT 11 for the hard disk, for instance -- INT 11? Hard disk is Int 13h. Cheers, Robert -- BTTR Software https://www.bttr-software.de/ DOS ain't dead https://www.bttr-software.de/forum/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
Let's plan for the next virtual get-together on Sunday Feb 19 at 11am US/Central. The focus for this one will be "technical." ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
On Sun, 22 Jan 2023 at 22:11, Jerome Shidel wrote: > > Assuming Google does not scrap GSoC amidst the layoffs, I have a thought. > > Perhaps it could be used to solve one of the most frequent problems I hear. > Running FreeDOS on modern UEFI hardware. > > As we are all well aware, this cannot be directly accomplished and would > require an abstraction layer between the OS and the actual hardware. I was discussing this recently on Mastodon, following Jim kindly agreeing to a video interview for the Register. https://social.vivaldi.net/@do...@nd2.uk/109716078029851572 This is a very sketchy thought, but... AIUI, the way that 386 memory managers for DOS work is that they put the CPU into protect mode, map RAM into upper memory blocks as DOS wants, then start a single, non-multitasking V86 mode VM for DOS itself. That basic process would be enough to boot a DOS instance, wouldn't it? "All" it needs is a memory manager that can start as a 32-bit process, set up a few interrupts -- INT 11 for the hard disk, for instance -- start a single V86 process, and then kick DOS off in that process. Then a stub program for DOS to load in CONFIG.SYS to enable the memory manager. Normally, DOS starts EMM386 or JEMM386 or whatever. This way round, JEMM386 starts DOS. Does that seem doable? It needs to be small, but as such, I wonder if VisOpySys, KolibriOS, MenuetOS or the like might have something usable? > A project could be created to provide a very thin Linux based system > (possibly using an RTOS kernel) whose only job is to manage the abstraction > layer and implement the virtual machine to run FreeDOS. This sounds akin to the process HP and others use to ship FreeDOS laptops. It works but it's quite complicated: https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packard-freedos-option/ -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
On Sun, 22 Jan 2023, Jerome Shidel wrote: Assuming Google does not scrap GSoC amidst the layoffs, I have a thought. Perhaps it could be used to solve one of the most frequent problems I hear. Running FreeDOS on modern UEFI hardware. As we are all well aware, this cannot be directly accomplished and would require an abstraction layer between the OS and the actual hardware. A project could be created to provide a very thin Linux based system (possibly using an RTOS kernel) whose only job is to manage the abstraction layer and implement the virtual machine to run FreeDOS. This could be done almost transparently. Booting straight to DOS unless the user pressed a specific key (Like F1) during boot. Pressing such a key would bring up a BIOS like interface that could be used to change the virtual BIOS settings and configure drivers and such aspects of the host OS. Their job would be to create that interface and make it all work seemingly. Most of the pieces required exist. But, it would not be a small task to implement. It could yield much better performance and more accurate emulation than traditional virtual machines. With todays multi-core systems, individual cores could be dedicated to emulating various aspects of PC hardware. For example, one core could be dedicated to performing the tasks handled by a sound card. I think such a project could appeal to many. There is a lot of interest in playing old games. Also, since this would be a generic legacy PC emulation layer. It could be used to install other Operating Systems like MS-DOS, PC-DOS, etc. :-) Jerome I think I actually proposed a similar idea some time ago except that it was *itself* the OS, rather than a stripped-down Linux distro. Sort-of a pre-AMD64 PC emulator, virtualizing where possible, emulating where not. Then again, I have a half-written Apple //e emulator that runs straight off UEFI - and it's much the same thing I was describing, except Apple ][ instead of an older variety of PC, and strictly emulation. I do feel it's really overkill though - and it's a bit of a two-edged sword. More work to implement and maintain, though much less of a footprint. As for all the people saying "make FreeDOS more like Linux", they don't seem to understand FreeDOS *or* Linux. -uso. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
Assuming Google does not scrap GSoC amidst the layoffs, I have a thought. Perhaps it could be used to solve one of the most frequent problems I hear. Running FreeDOS on modern UEFI hardware. As we are all well aware, this cannot be directly accomplished and would require an abstraction layer between the OS and the actual hardware. A project could be created to provide a very thin Linux based system (possibly using an RTOS kernel) whose only job is to manage the abstraction layer and implement the virtual machine to run FreeDOS. This could be done almost transparently. Booting straight to DOS unless the user pressed a specific key (Like F1) during boot. Pressing such a key would bring up a BIOS like interface that could be used to change the virtual BIOS settings and configure drivers and such aspects of the host OS. Their job would be to create that interface and make it all work seemingly. Most of the pieces required exist. But, it would not be a small task to implement. It could yield much better performance and more accurate emulation than traditional virtual machines. With todays multi-core systems, individual cores could be dedicated to emulating various aspects of PC hardware. For example, one core could be dedicated to performing the tasks handled by a sound card. I think such a project could appeal to many. There is a lot of interest in playing old games. Also, since this would be a generic legacy PC emulation layer. It could be used to install other Operating Systems like MS-DOS, PC-DOS, etc. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
Hello, It is a good idea to apply to GSoC; but I reckon there won’t be many students to select it. It sounds like giving a toddler a broom to clean an attic, while the rest of the family is chilling downstairs. - There is no single code base, everything is scattered. Scary. - There is no product roadmap, and no worthy possible tasks. - Bug fixes hardly warrant a GSoC task. > Mouse-driven GUI is always at the top of the list for new DOS > developers, right next to "64-bit FreeDOS" and "Raspberry Pi FreeDOS." > You know, all the things DOS wasn't made to do. :-P Why not make a fully modern operating system with DOS conventions, and keep the old DOS interface as a compatibility mode, and still a separate download for those who wish it? Mega65 does something similar. DOS stopped being a moving target 30 years ago. Even the idea “modern OS with DOS conventions” is a very challenging idea generator. Just target QEMU and/or a specific board that is available for a couple of bucks, and let people play with it. Even the hardware support may pick up later on (e. g. SerenityOS). Then there will be lots of ideas and opportunities for students to play around. Best regards, Emir (ఽ) ** E-mail needs to stay simple ** Use plain text e-mail ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Re: Google Summer of Code?
Hallo Herr Wilhelm Spiegl, > fdisk, chkdsk, dosfsck, defrag and scandisk (not in distribution, empty gui). > I have no problems to send you screenshots. > fdisk, : https://gitlab.com/FreeDOS/base/fdisk/-/issues fdisk has problems, yes. none of these is related to fat32, but all to big disks. and yes, the quality of chkdsk, dosfsck for fat32 is less then optimal. fdisk just needs a volunteer to bugfix it. but nothing of this deserves a 'google summer of code' which is IMO intended to support something *new* or *interesting* like reactos would have been. > willi > -- > Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.comMail > gesendet. > Am 22.01.23, 17:56 schrieb tom ehlert :Hi, >> the proposal was from me. Maybe some of you know that I work on the text for >> a new help version. >> To do so, I use different sources, depending on what I can get. >> Sometimes documentation is very good, sometimes there is none, >> sometimes even command/? gives no information and I have to guess, read >> books or run tests. >> So I have to run each command in a virtual machine and test it. And >> when doing this, I noticed that some programs are really good but some... >> Among others, all programs that have to do with creating a file >> system have problems with fat32 support. > there are exactly 2 (maybe 3) commands thatb deal with fat32 at all: > format, chkdsk (and friends) and maybe defrag, while I have no idea > about defrag status. > now it would be cool if you gave at least examples of what > 'programs', and what 'problems' > none other 'commands' should be even aware of what filesystem they are > dealing with. or are you confounding 'fat32' with 'LFN'? >> One of them is an empty GUI. > name please. if that were true it tuely shouldn't be distributed. >> So I had the idea with summer of code. >> Well, what can happen? > given that for the last 10+ years exactly 2 FreeDOS programs have made > any progress (ignoring any internationalisation stuff), I see expect the > chances by +-0%. > by the way, the 2 programs are the setup stuff and edlin. hardly > rocket science. > Tom > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel Mit freundlichen Grüßen / with kind regards Tom Ehlert +49-15151898538 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
> > What core programs or components should we put into the application - > > if we apply and can get accepted? On Sun, Jan 22, 2023 at 12:11 PM Robert Riebisch wrote: > A mouse-driven GUI... > > SCNR :-D Funny! :-) Mouse-driven GUI is always at the top of the list for new DOS developers, right next to "64-bit FreeDOS" and "Raspberry Pi FreeDOS." You know, all the things DOS wasn't made to do. :-P ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
Thanks to everyone who joined the FreeDOS virtual get-together! It was a small group (7 or 8 people) but this was more of a social meeting so the small size was good for conversation. We'll plan to do it again next month and focus on technical topics. Watch for the date! ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
On 1/22/2023 10:28 AM, Robert Riebisch wrote: Hi Ralf, So let's discuss: What core programs or components should we put into the application - if we apply and can get accepted? A mouse-driven GUI... SCNR :-D No, PLEASE, NO! Was just kidding... You DID notice the smiley at the end, didn't you? ;-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
Hi Ralf, >>> So let's discuss: >>> >>> What core programs or components should we put into the application - >>> if we apply and can get accepted? >> A mouse-driven GUI... >> >> SCNR :-D >> > No, PLEASE, NO! Was just kidding... Cheers, Robert -- BTTR Software https://www.bttr-software.de/ DOS ain't dead https://www.bttr-software.de/forum/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Re: Google Summer of Code?
fdisk, chkdsk, dosfsck, defrag and scandisk (not in distribution, empty gui).I have no problems to send you screenshots.fdisk, : https://gitlab.com/FreeDOS/base/fdisk/-/issueswilli--Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail gesendet.Am 22.01.23, 17:56 schrieb tom ehlert : Hi, > the proposal was from me. Maybe some of you know that I work on the text for a new help version. > To do so, I use different sources, depending on what I can get. > Sometimes documentation is very good, sometimes there is none, > sometimes even command/? gives no information and I have to guess, read books or run tests. > So I have to run each command in a virtual machine and test it. And > when doing this, I noticed that some programs are really good but some... > Among others, all programs that have to do with creating a file > system have problems with fat32 support. there are exactly 2 (maybe 3) commands thatb deal with fat32 at all: format, chkdsk (and friends) and maybe defrag, while I have no idea about defrag status. now it would be cool if you gave at least examples of what 'programs', and what 'problems' none other 'commands' should be even aware of what filesystem they are dealing with. or are you confounding 'fat32' with 'LFN'? > One of them is an empty GUI. name please. if that were true it tuely shouldn't be distributed. > So I had the idea with summer of code. > Well, what can happen? given that for the last 10+ years exactly 2 FreeDOS programs have made any progress (ignoring any internationalisation stuff), I see expect the chances by +-0%. by the way, the 2 programs are the setup stuff and edlin. hardly rocket science. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
On 1/22/2023 10:11 AM, Robert Riebisch wrote: Hi Jim, So let's discuss: What core programs or components should we put into the application - if we apply and can get accepted? A mouse-driven GUI... SCNR :-D No, PLEASE, NO! ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
Hi Jim, > So let's discuss: > > What core programs or components should we put into the application - > if we apply and can get accepted? A mouse-driven GUI... SCNR :-D Cheers, Robert -- BTTR Software https://www.bttr-software.de/ DOS ain't dead https://www.bttr-software.de/forum/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
Chris DiBona, the Senior Director of Open Source at Google was caught in the massive wave of lay-offs that Google executed this past Friday. His group is responsible for the Summer of Code. The departure of specific people might not have an impact, but I would still try to be realistic about expectations. The Haiku calendar app is definitely niche, so maybe there is hope ... ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
After several reboots, my router is back online. Hopefully it will stay that way. Here's the meeting URL: https://bluejeans.com/202946130/6751 On Sun, Jan 22, 2023 at 10:59 AM Ralf Quint wrote: > > On 1/22/2023 8:56 AM, Jim Hall wrote: > > My internet router needs to be rebooted. At least, I hope that will > > get me back online. > > > > I'll share the URL when I'm back online and can login to Bluejeans. > > > > I'm sending from my phone right now. > > OK,thanks... > > BlueJeans was already acting weird for me when I tried to start it up > earlier... :( > > > Ralf > > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
On 1/22/2023 8:56 AM, Jim Hall wrote: My internet router needs to be rebooted. At least, I hope that will get me back online. I'll share the URL when I'm back online and can login to Bluejeans. I'm sending from my phone right now. OK,thanks... BlueJeans was already acting weird for me when I tried to start it up earlier... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
My internet router needs to be rebooted. At least, I hope that will get me back online. I'll share the URL when I'm back online and can login to Bluejeans. I'm sending from my phone right now. On Sun, Jan 22, 2023, 10:49 AM Ralf Quint wrote: > On 1/20/2023 4:45 PM, Jim Hall wrote: > > DON'T FORGET: The FreeDOS virtual get-together is Sunday at 11am > > US/Central. I'll share the link here shortly before the meeting > > starts. > > > > The meeting is on BlueJeans, which is what I use for my consulting > > (training). While you can use your web browser to connect to the > > meeting, we've found that you get better performance if you use the > > desktop meeting client. BlueJeans has a version of the client for Mac, > > Windows, and Linux. > > > Meeting info? ;-) > > > Ralf > > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Google Summer of Code?
Hi, > the proposal was from me. Maybe some of you know that I work on the text for > a new help version. > To do so, I use different sources, depending on what I can get. > Sometimes documentation is very good, sometimes there is none, > sometimes even command/? gives no information and I have to guess, read books > or run tests. > So I have to run each command in a virtual machine and test it. And > when doing this, I noticed that some programs are really good but some... > Among others, all programs that have to do with creating a file > system have problems with fat32 support. there are exactly 2 (maybe 3) commands thatb deal with fat32 at all: format, chkdsk (and friends) and maybe defrag, while I have no idea about defrag status. now it would be cool if you gave at least examples of what 'programs', and what 'problems' none other 'commands' should be even aware of what filesystem they are dealing with. or are you confounding 'fat32' with 'LFN'? > One of them is an empty GUI. name please. if that were true it tuely shouldn't be distributed. > So I had the idea with summer of code. > Well, what can happen? given that for the last 10+ years exactly 2 FreeDOS programs have made any progress (ignoring any internationalisation stuff), I see expect the chances by +-0%. by the way, the 2 programs are the setup stuff and edlin. hardly rocket science. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't forget: FreeDOS virtual get-together (Sunday)
On 1/20/2023 4:45 PM, Jim Hall wrote: DON'T FORGET: The FreeDOS virtual get-together is Sunday at 11am US/Central. I'll share the link here shortly before the meeting starts. The meeting is on BlueJeans, which is what I use for my consulting (training). While you can use your web browser to connect to the meeting, we've found that you get better performance if you use the desktop meeting client. BlueJeans has a version of the client for Mac, Windows, and Linux. Meeting info? ;-) Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Google Summer of Code?
Hi,the proposal was from me. Maybe some of you know that I work on the text for a new help version.To do so, I use different sources, depending on what I can get. Sometimes documentation is very good, sometimes there is none, sometimes even command/? gives no information and I have to guess, read books or run tests.So I have to run each command in a virtual machine and test it. And when doing this, I noticed that some programs are really good but some...Among others, all programs that have to do with creating a file system have problems with fat32 support.One of them is an empty GUI.So I had the idea with summer of code.Well, what can happen?First it is a chance to find out how Google will handle it. www.reactos.org got support for at least three years, students from all over the world worked on it, there were some smaller steps, but creating a working win clone is far far away.FreeDOS has a lot of single commands that could be done within the time, so there are chances that some of them could be finished. fat32 support for at least some commands would be a doable step.The next thing is that it may be possible that nobody at google "calculated" with such an old OS and gives you a chance.I am not sure how google will decide, and I am not sure if they take you this or next year, but I think it is worth a try.for this reason I will wear a german t shirt at today meeting with a monkey and the text:sollte - hätte - könnte (all these are cancelled) - MACHEN,means, we should do we should have done... we could... DO It!Willi Am 22.01.23, 12:37 schrieb Bernd Boeckmann via Freedos-devel : > Am 22.01.2023 um 03:46 schrieb Michael Brutman : > > I don't think you are going to get too far with an application ... I hate to be so blunt here, but it takes more than just being open source. It has to be a project with significant impact, and I think that FreeDOS is way too niche to be considered. In that point I tend to disagree. It seems that even a calendar application for the not so mainstream Haiku operating system was on the list, see https://summerofcode.withgoogle.com/programs/2022/projects/Aw6dks92 https://www.haiku-os.org/blog/harshitsharma/2022-09-12_gsoc_2022_final_report_improving_the_calendar_application/ Because of the relevance of FreeDOS for supporting legacy systems I think the chances are anything but zero, and in my opinion it is a great idea! Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Native SAS (SCSI) and SATA drivers?
On Sat, 21 Jan 2023 at 18:42, Samuel V. via Freedos-devel wrote: > > Does FreeDOS have programming documentation or native drivers > for SAS (Serial Attached SCSI) and SATA? No, not AFAIK. DOS never did, for trad SCSI. If it didn't have BIOS support, DOS couldn't see it. It was the adaptor's problem, not DOS's. DOS did support things like SCSI optical drives, via drivers, but then all optical drives need drivers for DOS, however they are attached. The same applies to SATA, SAS, etc. BIOS support on INT 11 or GTFO. > That seems to be one > of the few things that prevent DOS in general to work under the > newest computers I don't think it is at all, no. > apart from a generic BIOS/video implementation > layer, The BIOS is a hardware thing, not a DOS issue. So no. Generic video implementation? Again not a DOS problem. DOS itself has next to no graphics support. _Apps_ do that: it's their problem. Few DOS apps support anything more than generic SVGA anyway. > and compile FreeDOS with DJGPP for being able to work with > the full capability of the PC DOS can't access the full capability of any PC in the last 30 years. This is a red herring too. > while maintaining the BIOS/DOS environment. BIOSes are a problem but not in the way you seem to think. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Google Summer of Code?
> Am 22.01.2023 um 03:46 schrieb Michael Brutman : > > I don't think you are going to get too far with an application ... I hate to > be so blunt here, but it takes more than just being open source. It has to > be a project with significant impact, and I think that FreeDOS is way too > niche to be considered. In that point I tend to disagree. It seems that even a calendar application for the not so mainstream Haiku operating system was on the list, see https://summerofcode.withgoogle.com/programs/2022/projects/Aw6dks92 https://www.haiku-os.org/blog/harshitsharma/2022-09-12_gsoc_2022_final_report_improving_the_calendar_application/ Because of the relevance of FreeDOS for supporting legacy systems I think the chances are anything but zero, and in my opinion it is a great idea! Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
