DMapEdit is a C program, compiled under DJGPP. What does this mean exactly? Well, DJGPP is a 32 bit compiler, so DMapEdit is a 32 bit protected mode program, and uses 32 bit memory addresses. You will need at least a 386 to even run DMapEdit. The nice thing about 32 bit programs, however, is that they are faster than 16 bit programs usually. And since 32 memory addressing is used, you can use all the memory in your machine, up to 4 gigs. DOS doesn't support 32 bit programs yet. So, something called a DOS extender is required. This allows a program to use XMS/EMS instead of just the conventional memory. DJGPP compiled programs use a DOS extender called GO32.EXE, which is included with DMapEdit. When you run DMapEdit, it will automatically load and run GO32.EXE, so you don't need to worry about it. You just need to make sure it's accessable to DMapEdit. This means in the current directory, or in the PATH somewhere. Throwing it in your dos directory will work nicely. Or you can just include your DMapEdit directory in your PATH statement. For those who already have DJGPP installed on their machines, you should watch out for GO32 version conflicts. Use the GO32.EXE that comes with DMapEdit, or you might be able to strip DMAPEDIT.EXE and re COFF2EXE it. I'm really not sure if this will work or not, though. Let me know if you know. You could always set up a batch file somewhere in your PATH like this: c:/dmapedit/go32 c:/dmapedit/dmapedit %1 %2 %3 %4 %5 %6 %7 %8 %9 DMapEdit requires a 256 colors, with a minimum resolution of 640x480. This, of course, means you must have a SVGA card. DMapEdit supports the build-in video cards of the GRX library. If it doesn't appear to support your SVGA card, you have 2 options. You can try to find a video driver for your card, or you can try running UNIVESA.EXE. This will attempt to make your video card VESA compatible. It is better to use a VESA driver specifically for you card, however. Most non-VESA cards come with a VESA driver. If yours didn't, you can try to get one from your dealer. If you don't have a math coprocessor, you will need set up a GO32 environment variable to point to the math FPU emulator. This is done with the following line, usually in your AUTOEXEC.BAT file: set GO32=emu c:\dmapedit\emu387 I you are not sure if you have a math coprocessor or not, you can just try to run DMapEdit. It will let you know if you don't. If you already have some other 80387 emulator setup up on your machine, be aware that it may not work. DMapEdit runs in *protected* mode, and not in real mode, so unless it works in protected mode, you will still need to use emu387. If this still isn't much help to you, or you want to know more about DJGPP, you can subscribe to the DJGPP mailing list by sending mail to listserv@sun.soe.clarkson.edu with no subject and one line of body like: add myname@my.computer.onthe.net djgpp Of course, put in your real email address instead.. :) BE WARNED though! The DJGPP list sees a *LOT* of traffic. They can probably answer any question you have regarding DJGPP, though. The FAQ for DJGPP is on simtel sites... One place for sure is ftp.cdrom.com: pub/simtel/msdos/djgpp/ faq100.zip. This should have enough info for you to get up to speed on running DJGPP apps. Best of all... DJGPP is FREE SOFTWARE! (not quite as good as free beer, but hey!) Something I have discovered about DJGPP compiled programs and command line switches. Doing something like this: program -path c:\directory\ -file filename.dat will not split up all the arguments as one might expect. The 'c:\directory\' and '-file' will not be seperate, but will be combined into 'c:\directory\ -file' as one argument. I discovered this by accident. It appears '\ ' will allow you to force a space into the switch. Thus, I would recommend using just 'c:\directory' instead. Here's some stuff from the FAQ: Q: Go32 complains that the CPU must be in V86 mode to run. A: When the CPU is in V86 mode, the V86 manager must provide VCPI services for go32. Since VCPI is an extension to EMS, disabling EMS will disable VCPI, and prevent go32 from running. For some EMS managers, this means that you can't use the "noems" switch. Q: Why can't I keep QEMM in auto/off mode? A: When QEMM is in auto/off mode and there isn't anything in the system that is using any of QEMM's features, the CPU remains in "real" mode. Go32 knows this, and will try to use XMS to access the extended memory. Unfortunately, XMS is a feature that causes QEMM to turn on, and go32 doesn't know this and when it tries to switch into protected mode, QEMM traps it and gives a protection violation warning. Since this always requires a system reboot to fix, go32 checks to see if enabling XMS caused the cpu to switch into v86 mode (meaning QEMM just turned on) and gracefully exits. All you have to do to work around this is force QEMM to be on all the time so that go32 will know how to work with it properly.