OSDev.org

I am rewriting freedos and freedos32 and i have taken out the dir, echo, all the embedded commands in command.com and loaded them as exe files within the C:\bin directory. Does anyone know if there is any possibility to port X, KDE< XFCE< and Gnome to dos without Cygwin?

*bewilderment*

Well, I don't really know FreeDOS so I don't know what it provides, but you'll need multitasking for your GUI, as well as support for flat memory (both of which MS-DOS failed at), and a POSIX layer (that's what Cygwin does, so you'll basically port Cygwin to your FreeDOS port, and then porting KDE to Cygwin...).

Gosh, are you really sure you know what you're doing?

*biggrin*

What's up with this GUI on DOS GUI on crap GUI on everything stuff? Soon we will end up with a GUI on Toilet, won't we?
];-> - just couldna resist. I've tried hard, I swear.

Write an OS first, then come up with this gui things. Or provide yourself with a copy of DOS & Windows 3.11. Bad Idea?

what exactly are you trying to do with KDE over DOS ?? I mean, the KDE application will fail doing anything else (reading files, etc.) than drawing buttons even if you succeed !

There are widget libraries for DOS (i'd check Allegro package if i was you), which may help you if you're trying to do a new graphical freedos application (or even descrop environment), but how the **** do you think a monotasking OS will be able to run the DCOP daemon and KDEINIT required to kick KDE applications ? ...

Why should you use DOS as base ?
Everyone knows that DOS is in real mode, and how hard you change it, it's still made for real mode.
If you change everything, try considering to write an OS on your own
And then, try to write a GUI your own.

http://freedos-32.sourceforge.net/projinfo.html

Freedos 32 is *not* realmode ... it's much like a dos-extender right from the shell ...

However, trying to port a multiclient graphic system for a platform that can only run one program at a time seems to be a complete nonsense to me ...

I think it sounds good. PS. I don?t mean that the X-system on DOS sounds good.
But to do some work on FreeDOS and FreeDOS-32 could be fun..
Becasue stuff like flat memory support will be added to FreeDOS-32 soon. "All" you would have to do is to make it multitasking (at least i think that they wrote on the page that it is still going to be single-tasking).
And fix it so it won?t look so microsoft-ish.

/ Christoffer

Pype.Clicker wrote: http://freedos-32.sourceforge.net/projinfo.html

Freedos 32 is *not* realmode ... it's much like a dos-extender right from the shell ...

However, trying to port a multiclient graphic system for a platform that can only run one program at a time seems to be a complete nonsense to me ...

Yeah, an extender ? ::)
Does that make the difference ? ::)
If all is already in Freedos32, why rewrite it ? ::)
And of course, you have also a few GUI's for DOS (look on the website of freedos )

Have you tyred freedos32, I have and it's not very good,You would be better off with freedos and dos-extender ,I know you may say they are the same, But they are not 1 works the other does not yet.

I agree that porting KDE to dos is a no goer, But are you all saying that a none multi-tasking OS, can not have a fully scaleable gui ?
If so i disagree, eg: http://www.oby.ro/os_main.html

ASHLEY4.

ASHLEY4, emmm, sorry dude but Solar Os is Multitasking (Co-orperative Multitaking) Check the features link

May not have bean, The best example :-[

ASHLEY4.

Code Slasher wrote: ASHLEY4, emmm, sorry dude but Solar Os is Multitasking (Co-orperative Multitaking) Check the features link

True:

Cooperative multitasking avoids waisting time

Wasn't this the reason why Windows 3.1 was unstable ? ::)
(could be wrong of course, but I do remember that was the problem, but on the other hand, windows = a problem )

cooperative multitasking "per se" is not unstable ... i just cannot guarantee a misbehaved program lead to a nonresponding system. This is ugly in the case of a system that hosts several 'untrustworthy' programs like sharewares, rushwares, etc. but it may be a viable option when you have strong control over developed programs (like in Mac OS )

As a FreeDOS enforces no protection of any kind, a misbehaved program *can* crash the whole system if it feels so, just like a misbehaved DOS program could. If you're actually developing an embedded MP3 player with a graphic display you just don't care: only the programs shipped with your product will ever be run so if they're bugfree the system will work properly.

Now, where things become tricky is that it's *really* complicated to switch from a cooperative to a preemptive multitasking, both concerning kernel and application updates. virtually the whole kernel may need refactoring because many assumptions about non-concurency do no longer hold.

So you'd better know what you *really* want before you start. Saying "i'll try monotask first, then cooperative and finally preemptive multi-processors if i find time" is simply a waste of time and energy and a proof of short-sighted design.

DennisCGc wrote:

Cooperative multitasking avoids waisting time

Wasn't this the reason why Windows 3.1 was unstable ? ::)
(could be wrong of course, but I do remember that was the problem, but on the other hand, windows = a problem )

No, lack of memory protection was the main reason why Windows 3.1 was unstable (and it's the same main reason why the Win9x series was unstable too).

In practice, programs use cooperative multitasking more often than preemptive. Every time you do a read(), or a select(), or a WaitForSingleObject() -- in fact, any time you issue a blocking call -- you are cooperatively multitasking. By calling a blocking function, you are saying to the OS, "I don't want to do anything until this function completes". During that time, the OS is free to schedule other threads as it wishes.

Preemptive multitasking exists to correctly handle the case when two or more threads are non-blocked at the same time. For instance, if you had one program drawing a fractal, and another calculating pi, and another running Seti@home, you rely on preemptive multitasking to keep all three running at the same time.

It is as Tim states. I second that.

You are better off keeping preemptive and cooperative multitasking in mind. It saves time and lots of nerves later on when doing the IO driver design.