in UNIX console/xterm shells, you can put processes in the foreground using fg
job# or background using bg or by using using ^z (unfortunately, ^z is already
in use in DOS), but it could be some other key.
or you can put a process in the background by doing
command&
after bg or ^z then prints out the job number in square brackets.
& is not a DOS filename character.
you can also type in
jobs
and it will list the commandlines of the various jobs and the job number in
square brackets.
if a job finishes, the OS prints to the console a line that says basically that
job number [n] finished (you may choose to also list its commandline). it does
this in the middle of whatever program is running, including vim or emacs.
once a job has gone into the background, it disappears from the screen and has
no console or video or keyboard access.
I think this interface works very well.
>________________________________
>From: Michael B. Brutman <mbbrut...@brutman.com>
>To: freedos-devel@lists.sourceforge.net
>Sent: Monday, September 12, 2011 7:24 PM
>Subject: Re: [Freedos-devel] Freedos and lack of drivers
>
>
>I have been thinking about what a more modern DOS would look like. Some
>ideas ...
>
>
>- A "task" would look a lot like a single instance of DOS running
>today. The address space of a task would look the same, so it would
>have the interrupt table, BIOS area, video display buffer, expansion
>ROMs, system ROM, and extended memory that you find on a DOS system
>today. (Kind of like a running instance of DOSBox, but with better
>device and hardware emulation.)
>
>- MS DOS has its own concept of "process", which is an instance of a
>running executable. That concept remains unchanged. Multiple processes
>live within a "task" (as defined above) just as they do today.
>
>- The DOS kernel supports most (if not all) of the standard DOS
>functions. As there is an interrupt table and system ROM, BIOS
>functions are available as well.
>
>- Multiple tasks could be started and running. But they are logically
>part of one machine and one OS, not just separate instances of an emulator.
>
>
>The underlying kernel is a bit more sophisticated:
>
>- There is a shared filesystem for the machine. If that filesystem is
>not FAT then it is made to look like FAT by the time the DOS function
>calls run.
>
>- Memory mapping is used so that the tasks exist in different address
>spaces, and thus are protected against each other. Memory mapping is
>also used to give the illusion that each copy has its own video buffer
>so that direct screen writes and other normal practices are not problems.
>
>- The DOS portion of the operating system that is visible to the user
>applications is a thin wrapper that calls into the real OS. That keeps
>the memory footprint of the DOS kernel in each task minimal.
>
>- There is a real networking stack that can be used, and is shared
>across the entire machine. Additional DOS function calls are defined to
>use it, or a packet driver used a "shim" is used to support existing
>applications.
>
>- The kernel provides some other services that we are missing, like cut
>n paste support between the different tasks and inter-process communication.
>
>
>
>
>Another way to look at this is that you have a real operating system
>like Linux with a new (or better) DOS emulator. The DOS emulator takes
>some pain to try to emulate a real machine; keyboard interrupts, timer
>tick interrupts, 8250 and 16550 device emulation, etc. The difference
>is that unlike running multiple instances of DOSBox in separate Linux
>processes, the emulator allows some sharing of common state and data
>between the different emulated DOS tasks.
>
>I can't see adding all of this (or even 1/10th of it) to FreeDOS. But I
>can see starting with a fairly stripped down Linux base and doing some
>hardcore development work with KVM to build this. Riding on top of
>Linux takes care of our hardware compatibility problems and the emulator
>should preserve most of our existing software base.
>
>
>Mike
>
>
>
>------------------------------------------------------------------------------
>BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>Learn about the latest advances in developing for the
>BlackBerry® mobile platform with sessions, labs & more.
>See new tools and technologies. Register for BlackBerry® DevCon today!
>http://p.sf.net/sfu/rim-devcon-copy1
>_______________________________________________
>Freedos-devel mailing list
>Freedos-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
