opensubscriber
   Find in this group all groups
 
Unknown more information…

f : freedos-devel@lists.sourceforge.net 19 September 2011 • 8:30AM -0400

Re: [Freedos-devel] Freedos and lack of drivers
by Decheng Fan

REPLY TO AUTHOR
 
REPLY TO GROUP



Hi Rugxulo,
You introduction really made me wanting to try out DOSEMU. It's unfortunate
that I allocated all my hard disk space (120GB) of my computer to Windows,
so the option would be limited to a Virtual Machine. Thus I'll try your
idea, with DeLi + DOSEMU inside VMware or Virtual Box. Thank you for your
idea.
Best regards,

Robbie (Decheng) Fan
On Mon, Sep 19, 2011 at 3:13 AM, Rugxulo <rugxulo@gmai...> wrote:

> Hi,
>
> 2011/9/18 Aitor SantamarĂ­a <aitor.sm@gmai...>:
> >
> > 2011/9/13 Jim Hall <jhall@free...>:
> >> In DOS, it would be awesome to have true multitasking
> >
> > Pick the smallest Linux distribution that you know.
>
> These days that would probably be MicroCore (aka, TinyCore w/o X11)
> Linux. It's about a 7 MB .ISO download. I think the RAM usage is
> pretty low. I haven't tested DOSEMU, but I think nowadays you need
> Glibc 2.2, kernel 2.6, etc. (which it has, IIRC). So you can't just
> randomly pick any old Linux, sadly.
>
> http://distro.ibiblio.org/tinycorelinux/welcome.html
>
> Some people have suggested Debian in the past as a good stable
> starting point. But I remember DeLi 0.7.2 (uclibc-based) had a DOSEMU
> package, and that's been resurrected as ConnochaetOS (though I haven't
> tested it yet):
>
> http://www.connochaetos.org/wiki/
>
> > Remove X and anything about graphics.
>
> Yes but easier said than done.
>
> > Remove any Unix stuff,
>
> I guess you mean all the unnecessary POSIX tools. At least
> substituting Busybox should cover a good deal of it.
>
> The barebones stuff is kernel (vmlinuz), initrd.gz, and root system
> (/bin/sh) etc. (I think), and Gujin is a good boot loader (with DOS
> version), meant to replace Loadlin / Lilo.
>
> > Wouldn't it be great that you'd have several FreeDOSes running
> > simultaneously? (switch with Ctrl+Alt+Fn).
>
> Well, yes, that would be the whole point. But here's a naive question:
>  can a single DOSEMU session use more than 64 MB of memory? (Newer
> GCCs really eat a lot.)
>
> > You wouldn't have the problem of "modern hardware" (Linux does the
> > part), but then you have quite other disadvantages (I don't know how
> > good would be the drive mapping process that DOSEMU does. Would be
> > nice if DOSEMU scanned all the disks and mapped ALL partitions
> > automatically).
>
> Well, the only disadvantage isn't really one at all:  it's not perfect
> (but no DOS environment, or any OS, is). So there are bugs and
> incompatibilities, just like anything. But overall it works quite
> well.
>
> > In the meantime, yes, at least task switching would be great.
>
> Old-style real mode stuff should be easy to swap in and out of memory.
> (I remember some old swappers from 80xxx snippets, but I don't know
> how stable they were.) I imagine that it's when you start adding ten
> bazillion memory managers that things get complex.
>
> http://www.filegate.net/pdnasm/
>
> The real problem is trying to determine what apps you want to run.
> Personally I'd prefer DJGPP (cmdline, textmode) stuff and similar, but
> even that is probably a bit too complex for a simple memory swapper.
> Though of course DOSEMU handles DPMI fine.
>
> P.S. Actually at one time I wanted to build pcemu under (DOS) Minix
> 2.04 to be able to fake multitasking, but ACK didn't like the stock
> sources, and I never fiddled with it further.
>
> http://pcemu.sourceforge.net/
> http://www.minix3.org/previous-versions/Intel-2.0.4/
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@list...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.