


                 _____________________________________
                |                                     |
                |       Dosemu Project Registry       |
                |                                     |
                |               6/15/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 FAQ: - 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.


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 MacLean

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


Keyboard maintaince: - James MacLean

        This is mainly bug fixing the DOSEMU keyboard routines.


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

        This is mainly bug fixing the DOSEMU video routines.


*Xwindows color/graphics support: - Jason E Gorden - marky

        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 0.53).  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: - Mark Rejhon

        -* This is done except for bugfixing *-
Right now, termcap is being used.  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 more effecient way

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))   An IBM font available for 
Xterms, the use of DOSEMU on a remote IBM terminal, and the use of a 
special code at the virtual console to enable one-to-one character
mapping would be easy to handle, as long as only ASCII codes above 32 
are used.



Serial maintaince: - Mark Rejhon (formerly Ronnie)

        This is the code for modems and mice.  It has a big performance
increase over previous serial code.  Currently, serial performance 
ranges from 9600bps to 38400bps in DOSEMU, with an excellent emulation
of a 16550 UART, even on serial ports that does not have a 16550.
Also, 4 simultaneous serial ports are now supported.  The biggest problem 
is that many mouse drivers still do not work properly.  Hopefully upcoming 
new timer code will help this problem, since mice drivers seem to be very
timing sensitive.


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

        -* the dang has pretty much been finished
                        the DANG now updates it'self *-
        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 stopped
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
****************************************************************


*Timers: - Larry Stephan

This started out as just timer routines, but it has kind of expanded
to include the programmable interrupt controller, programmable interval timer,
real-time clock, a dos clock, and an interval timer for use by dosemu itself.
Which makes it a little bigger than I can handle quickly.

The PIC code is written, but not yet integrated with dosemu.  You can find
it in the timer directory.  The rest of the code is getting there, but if
someone wants to help speed it up, please let me know.  I'm sure there are
plenty of pieces to keep a few people people busy.
 

*DPMI support: - Lutz

Lutz (molgedey@solid.theo-physik.uni-kiel.de) is the champion of the DPMI
code propegating into DOSEMU. He's is already able to run emtex386.
Specs for DPMI 0.9 are available from ftp.qdeck.com in /pub/memory or
for DPMI 1.0 from ftp.intel.com:/pub/???????. You may have a look too in
http://www.theo-physik.uni-kiel.de/~molgedey/projects/computing/linux/dosemu.

One part of DPMI is getting Windows 3.1 to run. Lutz could need any help with
it since he hates undocumented functions :-).




*Performance improvements:  Linus & Lutz - (Tim played with this, but
had to do IPX) 

After accepting preliminary code from Lutz, Linus took 30 seconds to
write a kernel patch to add one feature that dosemu needs to the
kernel.  Lutz got it working and then Linus graciously expanded on the
code. Lutz is  in charge of debugging it now.  This has helped speed 
considerably.

--------------------
Earlier method-
        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)


*Debian distribution: - Michael E. Deisher

        Write instalation scripts & make sure that the dosemu system
comforms to the debian instalation standard.  It would probably be a
good idea for him to make james start following the FFSSTTD.



dynamic setup: - mike

        this should allow you to change the dosemu configureation
while it is running. (example turn off the speaker after it gets
annoying). I have no idea how this is going allong.



Name: LEXEC - Amit Margalt & Oren Tirosh

Description: 

LEXEC enables the user to run Linux programs from within DOSEMU, piping the I/O

through DOSEMU itself between the Linux program and the DOS "console"...
Our ideize 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: (dosemu has gone back to one process which
helps this considerably.  I think we might be done here)

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 (which is now the dosemu HOWTO)).
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.




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 eot from memory image (this would
decrase the delay before you run
        your program.

automatic dos program execution
        1. write a shell script to do it.
                (possibly write a "dcopy" command that when copying a
                        XXX.exe file, creates a XXX shell script to
                        run that program automatically.
        2. automatic binaray execution by moddifiying the exec() process
                in the kernel

virtual dos integration.

------------------------------------------------------------------------
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 - should be able to run many programs and
will actually work!  :)  Performance: still miserable.

dosemu .52+ - should be able to run many programs, actually work, and 
performace should go off the scale!  (Let's see... 'fair'...or just 
maybe even 'good' is more like it)

dosemu .60 - (when released later in 1994) Current hopeful plans to make 
it support Microsoft Windows 3.1 and real games like DOOM, SimCity 2000, 
Xwing, and Flight Simulator at satisfactory speed!  We need your HELP
to make them work well - if you know how VCPI works, please contact us!

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: 0.52
Development version: 0.51pl28

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.  Bleeding-edge Linuxxers are welcome to try the development
version out, as long as they claim responsibility for using it :-)

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

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
Mark Rejhon             - ag115@freenet.carleton.ca
Michael E. Deisher      - deisher@enws99.EAS.ASU.EDU
James Maclean           - jmaclean@fox.nstn.ns.ca
Larry Stephan           - jlarry@ssnet.com
Lutz Molgedey           - molgedey@solid.theo-physik.uni-kiel.de
Amit Margalt            - amit@tavis.enet.dec.com

Corey Sweeney
corey@bbs.xnet.com
