




                        Dosemu Project Registry

                                2/1/94


        The DOSEMU Project register is a list of the dosemu projects
that are being, and need to be done, allong with who is doing them.
The purpose of the DOSEMU project register is to prevent redundant
work on DOSEMU, as well as to give developers ideas for new things to
do.

        If you are currently working on something and i do not have
you in the register, or if you see something here and would like to
start working on it please send me mail to corey@amiganet.chi.il.us
(often mail must be sent several times becuase of flakey servers),
stating who you are, and what you are working on.  I'll incorperate
you into the register right away.

***********************************************************************
*       Remember that we need your help on all the projects in the    *
*"todo" section.  Please consider helping.  If you would like to help,*
*send me mail so i can register you with the project.                 *
***********************************************************************

-----------------------------------------------------------
A special welcome to all the new members of the dosemu team!

        The following projects are activly being worked on by thier
respective participants:



Bug fix collection & distribution: - James B. MacLean

        James assembles varios bug fixes & other patches into a
distribution for all to use.  If you have a bug fix or a patch, send
it to james and it will probably get into the next version of DOSEMU
(assuming it's a usefull patch :)


dosemu-HOWTO: - Michael E. Deisher

        The dosemu FAQ is a list of Frequently asked questions for
DOSEMU that is posted every blue moon to the DOSEMU mailing list.
A current copy is always at dspsun.eas.asu.edu:/pub/dosemu.


redirector maintaince: - (formerly Tim Bird(& hopefully again)) & James 

        This is mainly bug fixing the DOSEMU disk recdirector.

[Quote from tim]
{I have a couple more fixes for LREDIR.EXE which I would like to publish.  
{Also, I wish to continue refining the current redirector.  The hot area 
{right now looks like FCB support.  I am also very interested in 
{non-Microsoft DOS support (ie support for DRDOS and Novell DOS).  
{Finally, I noticed that the locking calls (translation of DOS file locks 
{into Linux file locks) are currently just stubs.


EMS & XMS maintaince: - James

        This is mainly bug fixing the DOSEMU EMS driver & XMS memory
system.


Keyboard maintaince: - James

        This is mainly bug fixing the DOSEMU keyboard routines.


Video maintaince: - James (again, dosen't he ever rest :)

        This is mainly bug fixing the DOSEMU video routines.


xwindows support: - Jason E Gorden

        xwindows support needs to be added.  Ideally dosemu, when run
would open a color xterm, then run color text dos programs.  When a
graphics application was run, the video card should be emulated & a
translation of the graphics should be sent to the window.  While this
is a huge task,  the first part should be fairly simple (compared to
implementing graphics).

The first part of the project should be to get a color xterm to
automatically open when dosemu is run (if you are in X).  The best way
to go about this would probably be to compare xdos with it's non-x
counterpart, to find out where they are differn't.  Then try to guess
which changes are for opening the x-window, and applying those changes
to  the latest release (currently .49pl3-3).  If that is successfully
completed, then the next thing would be to make sure that the Makefile
would check for the existance of the xwindow development files, and
only compile in the xsupport if they were found (allowing everyone who
does not have xwindwos development stuff to compile & run dosemu).
And lastly recognition of the xwindows system would need to be insured
so that if you were not in xwindows it did not try to open a xwindow.

Adding color text shoud be somewhat simple (again compared to
graphics) after ncurses has been added.  All that *should* need to be
done is to create a approperate xterm entry in the terminfo directory.
However if the xterm gets it's information in non-standard ways, then
more work may be involved.

Graphics in a xwindow is just a dream right now...

[Quote from Savio Lam]
{       For the xwindow support part, I see one problem with color xterm
{is that it doesn't support highlighting (extra bright). I've made a
{patch to it a while back that will make it support this. You might want
{to take a look at the file
{sunsite.unc.edu:/pub/Linux/X11/xutils/terms/ansi_xterm-src.tgz.


text output: - Savio Lam & Corey Sweeney (Me)

Color & the IBM charactor set must be added to dosemu.  By using
ncurses, not only will we pick up a terminal-independant way of
displaying color, but we will also gain the potential to do screen
updates in a effecient pattern.

To add the IBM charactor set, we may have to expand the features in
ncurses to handle them.  (I do not believe that they exist already)
(example of IBM charactor: happy face (001))


Serial maintaince: - ronnie

        This is the code for modems & mice.  The tricky part will be
getting the high speed modems to work.


EMUsuccess.txt: - Michael E. Deisher

        EMUsuccess.txt is a list of all the programs that have been
reported to work with dosemu.


[Quote from tim]
{"Shadow DOS" - (ooh, spooky :>)
{I am also working right now on an interface to allow an external process 
{(some other Linux process) to call a running DOSEMU process to access DOS 
{or BIOS services.  This may seem like kind of a funny thing, but I think 
{that it will be useful for the WINE folks.  The reason I call this the 
{"Shadow DOS" system, is that DOSEMU would not be running in the 
{foreground, with some useful DOS application, but rather in a background 
{role just to provide DOS services.  Also, the DOSEMU process would be 
{running continually as kind of a daemon.  (Maybe "Daemon DOS" would be a 
{better name, as it more appropriately reflects the Internet community's 
{opinion of DOS anyway).  Finally, in a related topic, I would like to use 
{the shadow DOS to be able to execute DOS applications directly from the 
{command line, without having to re-run through CONFIG.SYS and 
{AUTOEXEC.BAT every time.


DANG: - Alistair Macdonald

        For those of you who don't remember the DANG is a document
that provides information on the differn't sections of dosemu.  It's
soposto be a helpfull guide for C programmers who wish to make a
better world for dosemu.  It gets posted to the dosemu channel every
once in a while, and can be found in the dosemu distribution.


The DOSEMU manual: - Lawrence Mao

        This was originally written by bob.
The manual was written in TeX, and contains information
on how to configure dosemu, how to install dosemu, a list and
description of dosemu's features, a list of dosemu's bugs, and much
more.  The manual is already quite comprehensive and very few sections
need to be added.  Mostly what is needed is to change the information
in the manual, to be updated every time james releases a new version.

        The manual is located in the "doc" directory, of the standard
dosemu source distribution (this does not imply that there is a binary
distribution).  

        Note: The manual has fallen behind since rob stoped
maintaining it, but should be up to speed soon.

****************************************************************
We need YOUR help on this.  Please send in any ideas or improvements
to the manual that you can come up with.  Send them to
                        lkmao@quark.SFSU.EDU
****************************************************************


------------------------------------------------------------------

The following projects need someone to work on them:



Performance improvements:  (tim played with this, but had to do IPX)

 From messages to the msdos mailing list i believe that this is already
being worked on by someone.  And from the little i saw, it seemed like
they were taking the right approach to doing it.  It goes something as
follows:

        The first step is to determine where in dosemu all the time is
being spent.  To determine this a program/patch could be written to
provide timing information.  This would in essence act like a huge
debug system that recorded how many instructions it took to do each
function, how many cycles it took, etc.  Then from that information it
could be determined where dosemu was spending it's time.

        Once it was determined where dosemu is spending it's time,
procedures must be rewritten to work in a more efficent way.  One way
of doing this would be to redirect certain interupts so that rather
then doing the calculations for the interupt in "dos mode" the system
would call out to the posix equivalant, run the calculations in the
32-bit posix mode, then return the result to the program.  To decrease
programmer efforts & development time, the interupt redirection might
be able to be stolen from the wine (wabi clone) project.

[Quote from tim]

{Performance -
{I have been examining performance of DOSEMU, examining code paths for 
{problem areas.  My current area of focus is the sigsegv() handler.  It 
{appears from rudimentary samplings that this is called between 500 and 
{1000 times a second during normal DOSEMU usage.  Specifically, I have 
{been researching the feasibility of moving a portion of the emulation 
{performed by this routine (and its sub-routines) into the Linux kernel.  
{This would be in the form of a DOSEMU driver, which would catch the 
{segment violation trap directly for the DOSEMU process, and handle some 
{instruction emulations right in the kernel (avoiding signal handling and 
{ring transition overhead, as well as avoiding a potential re-schedule).

{Charlie Brady <charlieb@tplrd.tpl.oz.au> says:
{Linux should already have profiling capabilities - check  for  profil(2),
{monitor(3), and prof(1)


Memory:

The memory for dosemu needs to be dynamically allocated.  This means
that the linux system should be using all available memory for
buffers,  when dosmeu starts up,  it only takes the ammount of memory
that it needs to run the dosemu system it'self and the 640K to run the
program.  Then when the program requests memory from the system, the
dosemu system should take the nessacary memory from the linux buffers,
and allocate it as EMS or XMS (whichever was requested).  Once that
program gives up the memory, dosmeu should return the memory to the
linux system.

Note that this eliminates the need to colectivize XMS & EMS into one
memory pool, and it also eliminates the need to colectivize the memory
pools of every dosemu session running at the same time.

I checked the way that this works right now.  And it appears that the
memory is allocated at run time, but when the dos program gives it up,
dosemu hoards it.


Standard memory footprint:

The memory requirements to run the basic 640K dosemu session needs to
be shrunk down.  I currently have no idea now to accomplish this one.
(Would threads help this one?)


terminal input:

The extended keys (ex: F12, Shift-F5, Controll-Pageup, Alt-Shift) must
be recognized by dosemu.  Some keys like the F11 & F12 must be added
as specified in the TNT (which is now becoming integrated into the dos
FAQ). Pageup, and tilda (that little squigle) fall into this catagory
too.  However to get things like Shift-F5 to work, a special kind of
process must be made.  This process must be rigged so that when the 
correct sequence to represent the shift key being pressed, is passed
to the dosemu system,  dosemu sets a "sticky" shift bit.  This bit
should cause ALL keys pressed after it to work like the shift key is
being pressed.  Then there needs to be a sequence to turn off the
sticky shift bit, so that people can "let go" of the shift key.

After that a sticky alt, unalt, ctrl, and un-ctrl need to be created.

The next project after that is to find which of the keys like pageup,
pagedown, end, home, insert, Tab, and Delete have entries in the
terminfo, And for any keys that don't have entries, create new
"standards" of where to add them, and add them in.


DPMI support: - (James is planning on trying to take this up, however
if anyone has any idea how to go about doing this & would like to take
it over it would be most appresiated, so that james can continue on
his many other things)

        steal some from wine & ask bob from wine.
        get the specs from ftp.qdeck.com in /pub/memory


Debian distribution: 

        Write instalation scripts & make sure that the dosemu system
comforms to the debian instalation standard.


networking:
        I've seen some people say that they wanted novel networking to
work under dosemu, and i just wanted to say that I believe that novel 
networking belongs in the kernel, not in dosemu.  This would allow you
to hook your linux machine to a novel network, mount the novel drive, 
then run dosemu and mount the directory as a drive.

This can be more easily
accomplished by running an NFS NLM on the NetWare server and mounting
the volumes on your linux box and then using the redirector.
However, this is not acceptable to many users.  Some software
systems are built arround drive mappings using Novell commands like
map to dynamically change drive mappings etc.

[Quote from tim]
{IPX emulation -
{I am writing an emulator module for DOSEMU which translates the DOS IPX 
{API calls into Linux IPX socket calls. Since the release of patch level 
{14 of Linux, there is a kernel driver for the IPX protocol.  Although it 
{has some bugs, I am confident that they will be worked out soon, and I 
{have also heard of another, independent effort to get the IPX protocol 
{working on Linux (via the X-Kernel protocol stack from the University of 
{Arizona).  In any event, I believe that relatively soon, Linux will have  
{a reliable IPX protocol stack running.  My IPX API emulation will allow 
{DOS programs which use IPX (such as the NetWare shell) to be supported in 
{DOSEMU.  I am almost finished with a first cut of the IPX emulation.  The 
{last part I need to work on is integrating my asynchronous callouts with 
{the DOSEMU 2-process IPC system.

------------------------------------------------------------------------

Future project ideas:

sound driver - link emulated soundblaster card to the sound device.
more video card drivers (eg. S3)
devide overflow error - fix the "24" hour bug.
how to become a developer document
timers - i don't think they've been done yet.
add .config file support (it checks the users hoem directory for a config
file *then* looks for the default)
internetional keyboard support - there used to be a problem with this.
        has it been fixed?

automatic "ports" assignment (create a "jill" config script, that can
be called with "dos -s jill 2> /dev/tty8" - basically the idea here
would be that people could distribute litte configuration files for
certain programs.  (possibly called config.jill or config.simearth
(you get the pattern))
------------------------------------------------------------------------
The following is a list of the projects that have been completed:

Debugging:
[Quote from ted]
{One request --- it would be really, really nice if *nothing* were sent
{to STDERR if all debugging options are turned off; debugging output
{should only show up if the user requests it.  Better yet, it should be
{written to a file like /tmp/dosemu-debug.<pid>, so the user doesn't need
{to mess with redirecting STDERR to a file. 
{
{                                               - Ted

------------------------------------------------------------------------
dosemu historical information:

dosemu .4 - ran dos shell & practically no programs.  had no features
to run most programs & emulator was broken. Performance: unbearable

dosemu .49 - ran dos shell & had features to run many programs.
emulator was broken. Performance: miserable

dosemu .50 - (when released)  should be able to run many programs and
will actually work!  :)  Performance: unless someone picks up the
"performance" project, it will still be miserable.  But i hope someone
does so we can make it just terrible.

performance standards:

(best)  awful           
        horibble        
        god awful       
        terrible        (486dx-33 = 386dx-33)(note diff of floating point)
        miserable       (486dx-50 = 386dx-33)(note diff of floating point)
(worst) unbearable      


------------------------------------------------------------------------
current dosemu information:

latest release - dosemu .49pl3 (more then 2 patches available)

current development version - dosemu .49pre-pl4g

Note:  don't look for the development version unless you are planning
on doing development work, because often certain features can be
totally screwed on a development version because they have not been
tested.

**********************************************************************

!!!everyone who believes that they can have new features & patches in
by 2/10/94 please send me mail, so we can have some idea on what
..49pl4 & .50 will look like!!!

-----------------

List of dosemu contributors addresses(in no paticular order):

Jason E Gorden          - gorden@jegnixa.hsc.missouri.edu
Lam Lai Yin, Savio      - lam836@cs.cuhk.hk
Tim Bird                - tbird@novell.com
Alistair MacDonald      - am20@unix.york.ac.uk
Lawrence K Mao          - lkmao@quark.SFSU.EDU
ronnie                  - ronnie@epact.se
Michael E. Deisher      - deisher@enws99.EAS.ASU.EDU
James Maclean           - jmaclean@fox.nstn.ns.ca
