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, 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
