Date: Wed, 11 Feb 1998 12:21:13 +0200 (IST) From: Eli Zaretskii To: Shawn Hargreaves cc: djgpp AT delorie DOT com Subject: Re: Allegro: Adding background music to old DOS game In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 10 Feb 1998, Shawn Hargreaves wrote: > Markus Brenner writes: > >What I'm trying to do is get some MIDI background music into the old > >MS-DOS Ultima games. My plan is to start up Allegro's MIDI player in > >the background, then hook the 0x21 interrupt and check for the file- > >open function. I don't recommend this course of action. See below. To make a long story short: I'd suggest to look for a different way of solving this problem, which doesn't involve hooking Int 21h from a DJGPP program. > I don't think that will be a problem. It would indeed be trick to do > this from a hardware interrupt, but int 0x21 is a software call made by > the mainline code, so you can safely call the play_midi() function from > here. Int 21h is a software interrupt. Under DPMI, software interrupts are not reflected to protected mode by default. So you will need to install a real-mode callback, for this to work. Unfortunately, the real-mode callback facilities in DJGPP have some real deficiencies. For starters, there is no provision for chaining to the previous handler (and you will almost definitely want to chain to the original Int 21h handler). So you will probably have to write some assembly and/or roll your own callback machinery. Also, the callbacks are non-reentrant. This means that if you are in a middle of code called from the callback, and another Int 21h causes your callback to be called again, you will crash. (In case you wonder, some of these limitations are there on purpose: programmer errors in hooking software interrupts can easily wipe your disk. It actually happened to some in the past.) Last, but not least, there are well-known limitations of hooking DOS interrupt, due to the fact that DOS is non-reentrant. Getting called before DOS will solve some, but not all of them (e.g., some DOS functions are called from within other DOS functions). Of course, there are well-documented techniques to work around these limitations, but be warned that some of them don't work well or don't work at all in the DPMI environment. For example, the issue of critical error handling is very complicated, hooking the DOS Idle interrupt again bumps into problems with real-mode callbacks, etc.