If you need all the functionality of ansi.sys, why not just boot real DOS inside DOSBox? Or use a virtualisation product such as VirtualBox or MS Virtual PC etc?

you have a autoexec section in new dosbox.conf

it tells me that there are unhandled ESC sequences in ansi.sys

Which ones?

tried the ansiplus driver from Kristofer Sweger, which is available as a TSR too (ansiplus.exe)

Is it freeware/shareware?

or does anybody know of a DOS helper utility which allows to load *.sys files

Search for devload (devload.exe), or use device.com from quarterdeck products (qemm).

nnansi has a com version, it has since been GPL'd and being used for the freedos project: http://www.kegel.com/nansi/
http://almy.us/dospage.html <-- recent nnansi version.

OK, I tried nnansi.com, which did not work too 🙁 ... will try to find that devload.exe or device.com and try out an original ms-dos ansi.sys. In the meantime, I ended up with reviving my old NWDOS7 license. Made a harddisk image and installed everything. Everything is working beautiful so far. 2 Problems have been left:
(1) When booting a different DOS, I can't 'mount' a directory from my Windows XP system as a drive anymore. I did not want to fiddle around with modifying image files, so I installed 'telemate', an old comm program which allows me to do file transfers via zmodem. On the XP side, I connect using my telnet software. That works great so far for exchanging files between the DOSBox and the XP world. If anyone has a better solution, please let me know.
(2) Running NWDOS7 now, I could not get my middle mouse button to work. I tried Microsoft's mouse.com (version 8.2) and ctmouse (cute mouse version 1.9, with the '/3' parameter applied) without luck. My mouse is a Logitech PS/2 wheel mouse and under "DOSBox DOS' the middle button works fine. Any ideas on this problem?

TO wd: running the debug version of DOSBox, it does not tell me the full esc sequences which are unhandled. I make a log file for you. Maybe you are then able to tell me a trick to get the esc sequences dumped out in full. I"m not so experienced yet with DOSBox 😖

Can you compile a debugger-enabled build from sources?

tried pc magazine's ansi.com too?

Meanwhile I think the problem is 'not really' just an 'ansi' problem, as nnansi.sys works fine under dosemu but nnansi.com does not do the job in DOSBox...

To wd: I'll try to compile a debugger enabled DOSBox-0.72, because that is the version which is supplied with my Debian Linux and I don't want to get into the hassle of setting up a development environment under Windows XP. But as we're talking about a problem which is not related to graphics, it should not make that much of a difference whether it's version 0.72 or 0.73 ... am I right?

Well if you're compiling from sources then grab 0.73, as 0.72 is some two years old.

wd wrote:

Well if you're compiling from sources then grab 0.73, as 0.72 is some two years old.

Hi wd,

Ok, I'm running the 0.73 debugging version under Debian Lenny now ... got everything compiled. I already did some debugging and I found out the following facts regarding ansi.sys support in DOSBox:

(1) General Issue: there seems to be a problem with the 'LOG' output, not all messages from 'dos/dev_con.h' are displayed correctly. I do know that the program is sending esc[3h, but I don't see the according warning.

(2) What I found out so far, the program sends the following unsupported sequences: ... esc[3h (is not of importance) ... esc[0;59;0;59p (which is of no importance either because that just means that F1 shall be F1) ...

(3) And now the critical one: esc[6n (Get cursor position report). The result is never sent to the keyboard buffer because the sequence is unhandled. So instead of a cursor position report the program gets the next keystrokes and interpretes garbage ... the rest is a lockup of that program due to lousy programming. I can send you a captured output of the program which includes the esc[6n in its last bytes.

I'm gonna stick to running my Novell DOS7 now. A real DOS and the emulation layer of DOSBox simply rocks. It's waaaay faster then hardware emu's like Blochs.

Oh BTW ... I found a difference in the keyboard handling between the Windows and Linux versions: under Windows, as soon as the DOSBox window is active, it catches the Alt-F4 keystroke too and sends it to DOS (which is very good). Under Linux this happenes only when the mouse is locked in, otherwise Alt-F4 closes the DOSBox window. This happenes at least under KDE (dont know about other X11 desktops). Same Problem with Ctrl-F9. Looks like grabbing the special keys is not working under Linux as long as the mouse is not locked into the DOSBox window.

report cursor position.. didn't expect anybody to use ansi for that.

Qbix wrote:

report cursor position.. didn't expect anybody to use ansi for that.

Yeah, I can imagine ... well the software we're talking about here is a CAD software from the early Nineties, which at that time was ported from Unix to DOS. I think that explains it all. As I said earlier, I'm not using DOSBox for gaming, but DOSBox so far is the ONLY emu I know which has emulation support for the graphics boards my CAD software knows about. This CAD software supports Trident 8900, ET3000, ET4000 and IBM8514 boards. dosemu supports the Trident, but not in 1024x768x16 mode. Bochs only supports a Cirrus Logic Super VGA and vmware does VESA only.

So I'll keep going with DOSBox and I will study the source code to see if I can contribute anything useful. 😀

you could try adding support for report cursor position. You have a test program that wants it afterall.

The attached patch has an implementation of the cursor position report. Please try it with applications that need the feature to see if the formatting is acceptable to them.

Some notes about the patch:

- It's based around observations of how MS-DOS ANSI.SYS and NANSI.SYS do things.

- There is checking that the number in ESC[6n is actually 6. Anything else will still be processed as if it were a 6, but a log message is generated. This is how DOSBox handles ESC[2J.

- The report data is not actually written to (stuffed into) the BIOS keyboard buffer; it is buffered inside the device driver and read out from there.

- Numeric formatting is used in the sprintf() that gives a two-digit zero-padded result like "[03;01R", which is how it should appear, but the %02u format will expand to accomodate values of 100+. There's no guard against an overflow on the buffer, which could only happen in the unlikely circumstance of a row/column position of 1000+. The buffer size could be increased, or a safe version of sprintf() used, if it's a concern.

- A carriage return is appended to the end of the report data. ANSI drivers do this for some reason; but it's also useful code-wise to mark the end of the data.

- The ANSI support in DOSBox has a separate issue with text screen dimensions larger than 80x25. See this thread for more info. I have added a fix for the issue that replaces the max row/column values stored in the device properties with values from BIOS data.