Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Decheng Fan
On Wed, Sep 14, 2011 at 8:31 PM, Travis Siegel wrote: > Another thing I wonder, is why it is that nobody has built anything > that allows executing of multiple oses on a single computer, using > one cpu core for each os, thereby allowing each os to run natively on > it's own cpu, thus eliminating

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Decheng Fan
On Wed, Sep 14, 2011 at 6:54 PM, Steve Nickolas < lyricalnan...@usotsuki.hoshinet.org> wrote: > On Wed, 14 Sep 2011, Andreas Berger wrote: > > > Writing a multitasker is easy, but I have no understanding about how > > DPMI, rings and resource allocation work. I think the idea of a > > bare-bone li

Re: [Freedos-devel] [Freedos-user] Heads up: "DOS ain't dead" forum is closing

2011-09-14 Thread Michael Brutman
Crisis averted. :-) -Mike Robert Riebisch wrote: >Dear all, > >You have probably noticed, that I have received a lot of public feedback >(plus a few private mails) on my announcement to close this forum. >Thanks for that! I didn't know, that this forum is such an important >part of the DOS com

Re: [Freedos-devel] [Freedos-user] Heads up: "DOS ain't dead" forum is closing

2011-09-14 Thread Robert Riebisch
Dear all, You have probably noticed, that I have received a lot of public feedback (plus a few private mails) on my announcement to close this forum. Thanks for that! I didn't know, that this forum is such an important part of the DOS community. Today I have also received a //large// donation via

Re: [Freedos-devel] New KEYB ahead

2011-09-14 Thread Bernd Blaauw
Op 14-9-2011 2:38, Aitor SantamarĂ­a schreef: > Hi, > > I have managed to patch a couple of bugs I found on KEYB 2.0, and have > KEYB 2.01 ready to launch (I just have to create the packages and > such). > I haven't been able to reproduce the bugs that some people have > occasionaly mentioned here o

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Alain Mouette
There was a project, quite some time ago, it was called "LiDos". I liked the idea very much: It was a very simple Linux distro runing Dosemu at boot time. You could switch to a bare Linux console and use Linux Commands. Unfortunatly it was Slackware based and had too many modifications, so when

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Michael B. Brutman
On 9/14/2011 7:31 AM, Travis Siegel wrote: > Mike, I like your suggestions. One thing that always bothered me > about dos versions that have come out since ms dropped the ball is > their complete lack of inovation. I realize there's only so much > that can be done if you're intending to keep 100

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Steve Nickolas
On Wed, 14 Sep 2011, Travis Siegel wrote: > Mike, I like your suggestions. One thing that always bothered me > about dos versions that have come out since ms dropped the ball is > their complete lack of inovation. I realize there's only so much > that can be done if you're intending to keep 100

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Travis Siegel
Mike, I like your suggestions. One thing that always bothered me about dos versions that have come out since ms dropped the ball is their complete lack of inovation. I realize there's only so much that can be done if you're intending to keep 100 percent compatibility, but still, it's not

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Steve Nickolas
On Wed, 14 Sep 2011, Andreas Berger wrote: > Writing a multitasker is easy, but I have no understanding about how > DPMI, rings and resource allocation work. I think the idea of a > bare-bone linux behind the scene is a very good. Truth be told I would > like to see OS/2 resurrected with true DOS

Re: [Freedos-devel] Freedos and lack of drivers

2011-09-14 Thread Andreas Berger
I also think the task should look exactly like DOS. This either means that resources (e.g. serial ports, printer ports, usb, ect) must be given exclusively to one task which owns it until it closes or the kernal must administer the conflicts WITHOUT one task being able to crash another. Writin