I am currently working on the Mem tool.

I do my development under Bochs(approve sites) under Microsoft Windows XP.

I use a Cygwin(approve sites) version of Mtools(approve sites) (I don't have a link for the Cygwin version) to get files "in and out" of my Bochs image. At one point I built MToolsFM(approve sites) using GTK for Cygwin and added a patch whereby the mtoolsrc file name could be specified on the command line to MToolsFM and MToolsFM would set the MTOOLSRC environment variable to the value given on the command line before executing any of the Mtools commands and then associated a file extension with MToolsFM so I could easily launch multiple MToolsFM instances for different Bochs images.

Inside Bochs, I use a DJGPP(approve sites) version of GNU Emacs(approve sites) for my editing and Open Watcom for compiling. Since I can't run the Open Watcom tools under Emacs due to DPMI issues I don't understand and probably should, I wrote Emacs Lisp code and a batch file so that M-x compile exits Emacs, runs the compilation command I specified, and then re-loads Emacs with all my existing files re-opened (as I use "Desktop").

It looks like with the HX DOS Extender and an upgrade from Bochs 2.2 to 2.2.1 I am able to drop to a DOS prompt from within Emacs and run Open Watcom's wmake - I executed "dpmild32 emacs.exe" to start Emacs. However, if wmake ran the compiler, after the compile is done, Bochs resets, so maybe some work is needed here. I found that using "hdpmi32 -r" avoided this crash, and Japheth has kindly looked into this issue and appears to have found a fix as he sent me a new version of hdpmi32 that stopped the crash from happening.

I would like to do source-level debugging of the FreeDOS kernel. I have used bochsdbg but I obviously had to manually track where I was in the source. I would like to write an Emacs mode in elisp that interfaces with bochsdbg and looks up in the symbol table to find the correct listing file (OpenWatcom's WDIS would need to be called to create the listing files) and then indicates which (assembly) line is about to be executed, but I have found that when I run bochsdbg from Bochs 2.2.1 for Win32 under GNU Emacs 20.7 for Win32, bochsdbg crashes after executing 1 or 2 instructions, and before that the output isn't displayed immediately - I think because bochs/bochsdbg send their output to stderr. I bet this issue doesn't happen under *nix-like operating systems. I will try some other versions of Emacs - GNU Emacs 21.x for Win32 and maybe XEmacs?. Maybe I will try compiling Bochs to send its output to stdout instead of stderr (see also this message on bochs-developers(approve sites)). Another thought I had was to compile Bochs with the gdb stub and then use GUD under Emacs and then add the logic to it to find the appropriate source file. My hope would be that gdb wouldn't have the same issues with sending output to Emacs. It might also require a bit less elisp coding.

• neither the Win32 or Cygwin versions of XEmacs (21.4.x) prevented the crash
• same with GNU Emacs 21.4

My "to do" list:

• submit a kernel patch for sending debug output to Bochs port (need to make a non-OpenWatcom outp())
• get Bochs working under Emacs on Win32

SourceForge.net user page