_____________________________________ | | | 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 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., 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