There is no problem with GUS emulation or detection in this case. The real problem is a buggy install program that erroneously uses a null pointer and reads the interrupt table as if it was data. The segment for the INT 2Eh vector must point low enough in memory for the installer to find environment data (by chance rather than by design), but this vector isn't hooked by DOSBox's internal DOS emulation, so the ULTRASND environment variable isn't found and the hardware check fails because no base port is specified to the CHECK.EXE program.

Running the TSR program here in DOSBox before running the installer works around the problem because it sets the INT 2Eh vector. The installer still complains several times about \ being an invalid destination, but it does that in real DOS as well, so it seems a bit cranky.

FYI, the bonus programs for GUS are mostly Windows 3.x apps, but the UltraSound Studio app and Epic Pinball demo work in DOSBox without installing Win3.

Thanks for the workaround. Has anyone figured out the cause of the first glitch (The GUS installer can't find the GUS when SB16 emulation is also on)? I notice that even with the TSR installed, that's still the case.

Presumably there is some conflict, but not much insentive to nail down the specific cause when its easy enough to disable SB while installing the driver disks. It's possible that the conflict may be avoided by placing the SB base port higher than the GUS, instead of the default condition where the SB base is lower, but I haven't tried it. If the conflict only occurs with the SB16 and not other SB types then it may relate to the high DMA channel.