On Sun, Apr 11, 2010 at 8:53 PM, Eric Auer <e.a...@jpberlin.de> wrote:
> Hi Liam,
> to multitask DOS apps which use direct hardware access,
> you have to use vm8086 mode of the 386 and newer CPUs.
> Many apps have this problem, only few use only the DOS
> kernel to access hardware. Many at least also use BIOS. [...]

Er, yes, I know. Which is precisely what DESQview did. That was rather
the whole point of my post.

> The multitasker of DR DOS is, as far as I remember, in
> most part a feature of their DR-EMM386.

This I did not know. I thought I'd got it working with QEMM or MS
EMM386.EXE from Windows. I must remember incorrectly; I've used very
little DOS stuff since the 1990s.

> It is not open
> source, only the sources of kernel and some core parts
> are open, although not under a totally open license.

Isn't it? Are you sure? Then how come there is the Open DR-DOS
Enhancement Project, for example?


> I assume that Desqview is also closely linked to some
> high end version of EMM386, probably QEMM386. Both the
> QEMM386 and Desqview were quite complex - and non-free.

I thought I was quite specific in my message; perhaps not.

DESQview multitasked multiple DOS (small) apps using pure software
multitasking inside 640KB. DESQview running on top of QEMM386 used the
386's V8086 mode & could use up to 16MB RAM, maybe more. QEMM
transparently mapped extended memory as XMS or EMS as required.

> MS DOS for a while also came with task swapping, part
> of their DOSSHELL, but that would not really multitask:
> It could just freeze a task, let you run something else
> and later continue the task, simply speaking. For that,
> it probably took a snapshot of RAM and hardware state,
> probably including for example EGA/VGA graphics...

Indeed. It was just a program switcher, not a multitasker.

> DJGPP is not linked to multitasking, it is simply a DOS
> version of the GNU C compiler, creating 32 bit DOS apps
> which can use gigabytes of RAM, if you have so much.

Indeed so, but here I think you're addressing "Sir Gallantmon",
although why you've put it in the same message, I don't know.

> However, a problem is still to trap hardware access and
> keep separate states for separate apps.

Yes, but this is one that has been solved repeatedly, so it is
certainly doable. It's relatively easy on the 386 which has specific
hardware support for this.

> I think some old SuSE Linux versions, 5.x or 6.x, came
> with some X server for DOS. No matter whether this was
> X.org or XFree86, the main purpose was to show graphical
> Linux apps running elsewhere on a PC which runs DOS.

This is news to me, and I used SuSE back in those days. I even wrote a
2-month feature in PC Pro magazine about Linux and built a custom SuSE
1-CD cover disk for the magazine. Can you remember any more details?

> Drivers and compatibility would indeed be a problem with
> a multitasking DOS, but on the other hand, you can still
> let a single tasking kernel with single tasking drivers
> serve multiple tasks, as long as you have a wrapper which
> makes sure that all kernel calls arrive nicely one after
> another. If necessary, you can also swap around some RAM
> with apps (and kernel state information!) to have a more
> realistic amount of DOS memory free and not run out of
> that after the third task ;-)

Again, that was the whole point of what I was talking about. This is
precisely what DESQview did (along with windowing, even in text mode.)
DR's TASKMAN did the same, but only full-screen.

> You could have a look at FreeDOS-32, which tries to take
> advantage of 386 protected mode features in the kernel,
> although I do not know how far they work on multitasking.

That's the specific point I was addressing in the 1st paragraph of my post.

> You could also have a look at Triple DOS / TriDOS, which
> is some extension for any DOS to let you swap tasks in a
> manual way. Stability is so-so and whether things can be
> task swapped for you of course depends on whether all the
> drivers that your apps use are wrapped by the task swapper.

I will do.

> Talking about a Linux API in DOS - given that there is a
> GNU C for DOS with a very Linux style C library (of course
> using DOS, not a Linux, as the actual backend) you could
> say that this already exists anyway :-)

OK, true, but it's less help without a multitasker.

> Not that it would really help you with X and GUI, though...

Well, it would, *if* one had a multitasking "hypervisor" on top of DOS.

Liam Proven • Profile: http://www.linkedin.com/in/liamproven
Email: lpro...@cix.co.uk • GMail/GoogleTalk/Orkut: lpro...@gmail.com
Tel: +44 20-8685-0498 • Cell: +44 7939-087884 • Fax: + 44 870-9151419
AOL/AIM/iChat/Yahoo/Skype: liamproven • LiveJournal/Twitter: lproven
MSN: lpro...@hotmail.com • ICQ: 73187508

Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
Freedos-user mailing list

Reply via email to