Official DOSBox doesn't have printer support, but hal's megabuild does. http://home.arcor.de/h-a-l-9000/

In MSDOS 5/6 a call to INT 21/33 with AL>6 causes an immediate return with AL set to 0xff, no other registers changed. Maybe the app is looking for something that hooks INT 21. Dunno why the devs put an E_Exit() instead of doing what DOS does; maybe just to have strange program behaviors reported.

The same error was reported on the bug tracker at SourceForge, see here. You would think it's the same person, as both reports were made on June 24, but the names of the apps seem different, and the subfunction (AL register) is different. What are the odds of two completely separate reports on the same day of such a relatively obscure issue?

1    case 0x33:      /* Extended Break Checking */
2       switch (reg_al) {
3          case 0:reg_dl=dos.breakcheck;break;        /* Get the breakcheck flag */
4          case 1:dos.breakcheck=(reg_dl>0);break;    /* Set the breakcheck flag */
5          case 2:{bool old=dos.breakcheck;dos.breakcheck=(reg_dl>0);reg_dl=old;}break;
6          case 3: /* Get cpsw */
7             /* Fallthrough */
8          case 4: /* Set cpsw */
9             LOG(LOG_DOSMISC,LOG_ERROR)("Someone playing with cpsw %x",reg_ax);
10             break;
11          case 5:reg_dl=3;break;//TODO should be z   /* Always boot from c: :) */
12          case 6:                                    /* Get true version number */
13             reg_bl=dos.version.major;
14             reg_bh=dos.version.minor;
15             reg_dl=dos.version.revision;
16             reg_dh=0x10;                            /* Dos in HMA */
17             break;
18          default:
19-            E_Exit("DOS:Illegal 0x33 Call %2X",reg_al);					
20+            LOG(LOG_DOSMISC,LOG_ERROR)("Unknown 0x33 Call %2X",reg_al);
21+            reg_al=0xff;
22+            break;
23       }
24       break;

The apps that are using the function won't necessarily work after this, becasuse it isn't clear what they're up to (the particular subfunctions aren't documented in the interrupt list); but the result of the function is what DOS does, and at least it wouldn't be the function call alone that keeps the apps from working.

The apps that are using the function won't necessarily work after this, becasuse it isn't clear what they're up to (the particular subfunctions aren't documented in the interrupt list)

That's why there's an E_Exit. If nothing uses it, it's no problem, if something
happens to trigger it it can be checked because people will report it.

I guessed the reason for the E_Exit(), if you read my prior post, as I've seen enough examples of it being done. The information I posted is intended for the poster and anyone else who encounters the problem. It appears that commercial applications are involved, not games, so the poster will likely have to conduct any "investigation" into the problem, and the source change I mentioned is one thing to try and see how the app reacts.

I guessed the reason for the E_Exit(), if you read my prior post

You said you don't have any clue why there's an E_Exit at that spot,
and later posted the diff, that's why i posted the reply.

ripsaw8080 wrote:

Dunno why the devs put an E_Exit() instead of doing what DOS does; maybe just to have strange program behaviors reported.

I guessed the reason, but obviously can't read minds. Never said I didn't have a clue, though.

Dunno why the devs put an E_Exit() instead of doing what DOS does

I guessed the reason, but obviously can't read minds.

Thought that was a hint at having somebody post this info, but whatever.