Restoring use of dgVoodoo - Tomb Raider 1 under Windows Vista
I finally came up with a working solution to the problem of sapucdex (hence dgVoodoo too) failing under Windows Vista.
Windows NT/2000/XP's default MSCDEXNT emulation for cdaudio does not support many functions that DOS programs (like Tomb Raider 1) require, hence Windows NT and later do not route CD commands to Windows, and CD audio will not be played.
Sapucdex was made as MSCDEXNT replacement to route the correct DOS commands from the game to Windows' sound system.
Enter Windows Vista and Sapucdex itself, the replacement, needs replacement, because it can't route the cdrom commands, like play, pause, stop etc., from DOS (i.e. the game) to Windows and again it falls back to no chance to play cdaudio tracks music.
Ssdh which is going to be discussed here in its turn is aimed to restore this DOS cd audio playing capability lost in the Vista era.
By way of a quick account :
it necessarily resorts to using MCI functionality
(Windows Multimedia Media Control Interface
to make for needed cdrom access, which previously Sapucdex used to accomplish via the so called ioctl_cdrom structures (for input/output control), now apparently to be considered as deprecated, according to MSDN's own docs
e.g. : Obsolete, beginning with the [sic!]
Windows Vista. Do not use this IOCTL to develop drivers in Windows Vista
as per http://msdn.microsoft.com/en-us/library/ms804546.aspx
Now since sapucdex used to be taken advantage of by dgVoodoo, the free Glide wrapper by Dege who together with VDMSound would let WinXP machines to run smoothly TR1 (nicer looking Glide version) with music and everything, under Vista dgVoodoo had now become practically useless for want of music reproduction, and prone to extinction, even as visual features are still viable,
so the new MSCDEXNT replacement's replacement regains the chance to use dgVoodoo (with VDMSound and possibly via the TR1 Advanced Installer too) to be able to play Tomb Raider 1 and 1 Gold aka Unfinished Business under Vista as well
WHAT CAN THIS PROGRAM DO FOR YOU
Ask not what this program can do for youâ€”-ask what you can do for this program.
You can provide for it and give it a safe haven, nourishment and a fair chance to exert its full-fledged potential, IOW :
what is your Windows version?
(successfully tested under XP Home SP3)
if it ain't broke...
actually sapucdex/VDMSound/dgVoodoo all run smoothly under XP. Me, I just had to try ssdh out all the same, and finally see it work, but why should you bother to try too ? Sometimes I really don't understand you.
If you do insist, just drop both ssdh.exe & ssdh.dll into the folder where sapucdex exe/dll have been dwelling smug for years, usually c:\tombraid, and assuming VDMSound, dgVoodoo and Tomb Raider are alreay installed preferably via the TRAdvancedInstaller, now you have 2 ways to run TR1/TR1 Gold w/ssdh, a hard and an easy one
the hard one first
at the prompt in C:\tombraid , type :dosdrv
if it's TR1 Gold replace tomb with tombub,
or (I know, this ought to be 22.214.171.124 now
) you can make a plain tomb.bat file ot tombub.bat doing the same without having to type it all every time.
the easy one is just via your good old VDMSound shortcut, that .vlp file with the TR1 icon, you'll have to right click, go to properties tab-> VDMS Launchpad Advanced Settings-> DOS Environment-> AUTOEXEC.BAT-> Additional options :
where it reads, or should read, c:\tombraid\sapucdex.exe let it be aware it's got to be c:\tombraid\ssdh.exe, save and you're done.
(successfully tested under Vista Home 32bit SP1)
now that's what this is all about.
First of all, a previous if incomplete short primer I had already written here
exactly in this thread on page 15, message dating from 2007-11-22 @ 05:16 pm
Contrary to earlier reports and to what is still to be read all around the net, the assumption appears to be made up out of thin air that VDMSound and dgVoodoo won't work anymore under Vista, period : if they are installed, you run them at the command line and the dreadable no full screen crash won't pop upcopy
ssdh.exe and ssdh.dll to c:\tombraidmove
the relevant dll files for glide (glide2x.dll) and ssdh (ssdh.dll) from c:\tombraid to \windows\system32 foldercopy
the vdmsound one (vddloader.dll) from c:\program files\vdmsound to \windows\system32 folder, so one copy of vddloader.dll stays in c:\program files\vdmsound, while presumably in c:\tombraid there should never have been one vddloader.dll file anyway (thanks Chug a Bug!)
(ssdh.exe can safely stay in \tombraid)
run dgVoodoosetup to let it look up the right path for glide2x.dll (dos tab)
and in the vesa tab enable "Use built in VESA support".
then you can get back to 1.1.1 up here (a-ha! I knew I'd get you there, confess to it, you had already forgotten about it, or never even read that didn't you) and follow through except....
you have no 1.1.2-like option here or it's all going to cave in on you and you'll see, if not the fatal BSOD, all the darn thing crash and burn.
So do me a favour and stick with 1.1.1.
To try it, here's the download link
:http://www.2shared.com/file/4621777/1fe ... S_D_H.html
password : tombraider
made a windows installer for this
to be found herehttp://www.tombraiderforums.com/showthread.php?t=152468
Use it and kindly report, either if it works or if it doesn't flop in the least for you.
Come back with any other kind of response and the consequences of that could be disastrous (Doc Emmett Brown).
Particularly for me.
Don't ever lesnerize. EDIT
this version of ssdh.dll has logging messages enabled which means that
each time you run it it creates a log file, either called c:\sapucdex.log
depending on whether the dll file was built by me before or after... I noticed I'd been dumb enough to forget to edit the relevant line in the code
since it can quickly grow to eat up hundreds of KB if you play frequently and/or for a long time pretty soon I'll recompile, and link to, a new one without the log file making, which after all only serves a testing purpose
if you don't want any log files hanging around, you can delete c:\sapucdex.log, or c:\tombraid\ssdh.log, right away
or take a look at it
an interesting info comes from the recurring couplets of
23:41:38.292 DEVICE_STATUS, STATUS = 0300, CF = 0
23:41:38.307 AUDIO_Q_CHANNEL_INFO, STATUS = 0300, CF = 0
23:41:42.260 DEVICE_STATUS, STATUS = 0300, CF = 0
23:41:42.260 AUDIO_Q_CHANNEL_INFO, STATUS = 0300, CF = 0
about every 3.9 seconds these check the status and CF parameters
CF (carry flag) should be = 0
while 1 means error
and status ought to equate = 0300, that is 0300h = 0200h (busy) + 0100h (done)
while all values like 81xx (8100 and above) e.g.: 81ADh spell trouble
WARNING : Discardable matters from here on.
WHAT'S IN A NAME? THAT WHICH WE CALL A CDROM
, that's what I should have called it!
As my old and sagging Visual C++ version is about 0% Vista-compliant, I had to become your human macro :
insert my shrewd code manipulations, compile and test with my XP machine, if it's any good, quick jump to the usb flash drive, flip it to the other PC, the Vista machine...
what's going on ?
oh no please, not another deafening "sound of silence" rerun, I only ask for some music to play.
I'll admit that I adore Groundhog day
but enough is enough.
Now testing is over for me. Then again, damncdex.dll
as I learned could constitute a pretty serious capital offense in 87 countries around the world.
I then thought of
It's a small step for mankind--a giant leap for a man.dll
but no, it dawned on me this might be not fully compliant with some systems using the filename 8.3 convention, what's more it could have turned by design into a ITSASM~1.dll, and whoa, ssdh.c is no .ASM file, not at all : ssdh.asm is, but ssdh.c is a C file isn't it (<- if that hasn't set you ROFL, you just have no heart, I say, and I'll quit playing with you)
I thought mci_cdex.dll
was just too true to be good.
In the end I felt it had to be ssdh. That's it.
Ask what that ssdh thing f*****g stand for finally? Man, that's so curious of you.
Why, that's the acronym from: "so sagt die Hex", it's German, a quotation from Goethe's Faust
, Part 1, it means: so says the witch
(which old witch? The wicked witch!
), from the Witchâ€™s Kitchen mise-en-scÃ¨ne, you know, the Magic Square evocation...
have no clue what I'm talking about ? And you call that a life which you are living!
Anyway the big, dull deal about it is of course die Hex
(German: witch) vs. the hex
(adecimal) numbers. Dislike it ? Pal, are you hard to please!
Other than that, soSagtDieHex is an alternate nick of mine that I love and I've been using lately, and I wish so bad I could ditch my old gidierre one, I've grown so fed up with by now, for it...
You run it 666 times and it'll land you on top of the mountains of Ararat.
A LIDDLE RINGERS... A RING-A-Â£|@#... A RIDDLE LINGERS
Now that all is said and done (until next blue screen of death) and my tears subside, a riddle keeps haunting me :
will this stuff still work under future OS versions, like Windows 7+ ? or under 7up ?
"Have you guessed the riddle yet?" the Hatter said, turning to Alice again.
"No, I give it up," Alice replied. "What's the answer?"
"I haven't the slightest idea," said the Hatter.
"Nor I," said the March Hare.
Alice sighed wearily. "I think you might do something better with the time," she said, "than wasting it in asking riddles that have no answers."
come enjoy the new feature : The Cdex's Chainsaw Massacre
(only this time unfortunately Jessica Biel won't be in it due to alleged previous commitments)
or, the havoc I brought into sapucdex source code and how it oddly seems to have delivered.
Originally, this sapucdex revamping was supposed to be a shameless monkey's stea.. oops, mimicking of dosbox source code, in the end it became a shameless monkey's mimicking of dosbox source code instead.
Am I flipping out ? Not really.
You know, dosbox source is a mine you can go and fetch many things from,
there's cdrom access via SDL routines (cdrom.cpp) and other alternate ways to make it (like cdrom_ioctl_win32.cpp recently refurbished in cvs, thanks wd) whom I examined all out searching for inspiration.
Sapucdex uses IOCTL routines which are mostly marked by ioctl structure calls deprecated as obsolete under Windows Vista, so it's assumed that's the reason why it stopped working when Windows 6 came forth.
My first idea was to replace those ioctl calls with other ones using whenever possible SDL routines
see e.g. http://www.libsdl.org/cgi/docwiki.cgi/SDL_CDOpen
and surrounding webpages
but I found huge problems mostly right at the initialization step
finally I gave up on SDL, my last and final venture into it was trying to encapsulate SDL implementation between a shut and reopen ioctl operation in DevPlayAudio()
going at it between one call to
and then afer invoking and closing sdl, one to
to avoid clogging the whole sapu proceedings.
I found the best way to effectively save/restore drive pointer stuff was doing this
- Code: Select all
drive = DrvInfo->unit_nr;
// SDL code here
DrvInfo->drive_handle = OpenPhysicalDrive(drive);
which actually shuts/reopens the drive, then implementing sdl stuff : nothing.
Out of this predicament I tried to break loose by recurring to MCI calls and it seems it has worked.
I still kept sapucdex general framework to ensure all Int 2F/AX=1510h (SEND DEVICE DRIVER REQUEST) interception performed by it was retained whenever feasible, mostly editing the Open drive, Play and Stop functions.
In StopAudio() at any rate the Pause command is also handled.
The Seek, ResumeAudio and GetAudioStatus were on the contrary less edited than brutally commented out by me, not without a perplexed reflection on the scant pros and multiple cons of such a desperate move.
Mostly DevPlayAudio() and DevStopAudio() where hacked until almost only their empty outline stayed.
(Don't know whether this could be defined a source wrap. To me, it looks less like a wrap
than a rip-off
All activity being taken care of by MCI counterparts, the main hindrance was the obligation to zero in to fine-tuning the coexistence of ioctl and mci implementations side by side so to speak within the same program, which is precisely the reason for my abandoning the sdl option.
Much more could be debated, but in order to do so I'd have to begin posting substantial portions of the code here, which I'll only be sure to do if someone cares to view and discuss with me, and possibly teach me how to improve things further.