When using the proxy dll it is useful to edit dxwnd.dxw and change the path fields from absolute to relative.
E.g. change this: path0=C:\game\game.exe
to this: path0=.\game.exe
This makes the proxy fully portable.
Side note:
Virtual CD audio does not seem to work when using a proxy dll. Copying "dxwplay.dll, libogg.dll, libvorbis.dll, libvorbisfile.dll" to the game folder did not help either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not even sure that a path0 field is necessary in proxy mode, the dxwnd.dll is loaded by the proxy library (es. ddraw.dll) and may not need an executable name at all. But I'm not sure, let me check ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see that the "path0" field is not needed for the proxy at all. (Neither is "startfolder0" or "launchpath0" I assume.)
Problem is that when you install a proxy from the Dxwnd GUI that field gets copied to the dxwnd.dxw file that stores the all the game specific settings. So possibly one would need to edit the source at “proxy\init.cpp” so that the path0 field gets omitted or just replaced by ".\" or something...
As for the Virtual CD audio not working with a proxy setup it might be enough to build a small winmm.dll proxy. And modify the proxy installation to also copy "winmm.dll, dxwplay.dll, libogg.dll, libvorbis.dll, libvorbisfile.dll" to the game folder. Maybe add a check in there to see if the user has enabled the Virtual CD audio flag before copying those extra files?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you're right: the proxy mode is enabled by the fact that the game links the fake system dll (either ddraw.dll, dinput.dll, .... Beware: NEVER put more than one proxy dll in the game folder or the trick won't work!) who automatically loads dxwnd.dll, so there's no check for task names.
Furthermore, when dxwnd.dll is loaded the game is started already, so there's no possible use for startfolder or launchpath. All these fields could be cleared in the dxwnd.dxw file generation, but they make no harm (and could be useful to re-import the configuration back in DxWnd.exe, so why do that?
About Virtual CD audio, a small (ehm.. small? try counting the number of function calls in there ...) winmm.dll proxy is the original solution, also existing in GOG games, but it could bring a problem: winmm.dll doesn't hold only mci sound calls, it also have system calls for movie, joystick, timing and other stuff that DxWnd could be interested in hooking. I fear that a winmm.dll proxy could interfere with that. I should try to be sure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All these fields could be cleared in the dxwnd.dxw file generation, but they make no harm (and could be useful to re-import the configuration back in DxWnd.exe, so why do that?
Right you are. The proxy does not care about those path fields at all so this is really a completely moot point.
As for the winmm.dll proxy I see what you mean now. The number of calls in there is quite daunting. I was looking at the already existing stand alone winmm wrappers and it seems that they have a lot of issues. Mainly they are no where near as good as what is included with Dxwnd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was looking at the already existing stand alone winmm wrappers and it seems that they have a lot of issues. Mainly they are no where near as good as what is included with Dxwnd
The ones I saw until now were mainly designed having one specific game in mind: this is why they're not as good as DxWnd: each game uses a tiny bit of mci capabilities and there's no point in adding unnecessary stuff, both unused call wrappers or variations in the syntax. On the contrary, DWnd tries to be a one-fits-all software, so you have good chances that it could apply to untested games, and in any case you can always post here your "case" and wait for me to fix the code ;)
P.s. another weird idea I have in mind (but it's not at all a invention of mine) is to automate the proxy code generation: now that I learnt how to walk the dll PE structure, it should be easy to make a tool that outputs some C code with all function declarations and other stuff to build a generic proxy... this way the number of dll entries wouldn't frighten me no more.
Last edit: gho 2018-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I got the Virtual CD audio playing just fine with the proxy setup.
Testing with the game Pandemonium!
All I did was install the ddraw proxy from the Dxwnd GUI making sure the sound tab had "virtual CD audio" enabled of course. Then I also manually copied the "dxwplay.dll", "libogg.dll", "libvorbis.dll" and "libvorbisfile.dll" to the game folder.
I swear I tried to do exactly the same thing several times before and the music did not play. And now it is suddenly working just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weird, but I'm rather used to weidness with proxy configurations. Anyway, there's a little trick to try getting more information about what's going wrong: the proxy command clears all the log flag when writing the dxwnd.dxw file, but after that you can copy the value from a dflagn field from within dxwnd.ini (picking one entry that has the logging you wish, of course) and paste that value in dxwnd.dxw (making sure that the left part remains "dflag0"). This way the proxed game will write its own dxwnd.log file.
Maybe I should add a small dialog to the procedure to select whether to keep or clear the log flags ...
Last edit: gho 2018-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using the proxy dll it is useful to edit dxwnd.dxw and change the path fields from absolute to relative.
E.g. change this:
path0=C:\game\game.exe
to this:
path0=.\game.exe
This makes the proxy fully portable.
Side note:
Virtual CD audio does not seem to work when using a proxy dll. Copying "dxwplay.dll, libogg.dll, libvorbis.dll, libvorbisfile.dll" to the game folder did not help either.
I think I posted some code here somewhere that makes the proxy portable by removing the path completely, not sure if it's included with DxWnd though
I'm not even sure that a path0 field is necessary in proxy mode, the dxwnd.dll is loaded by the proxy library (es. ddraw.dll) and may not need an executable name at all. But I'm not sure, let me check ...
I see that the "path0" field is not needed for the proxy at all. (Neither is "startfolder0" or "launchpath0" I assume.)
Problem is that when you install a proxy from the Dxwnd GUI that field gets copied to the dxwnd.dxw file that stores the all the game specific settings. So possibly one would need to edit the source at “proxy\init.cpp” so that the path0 field gets omitted or just replaced by ".\" or something...
As for the Virtual CD audio not working with a proxy setup it might be enough to build a small winmm.dll proxy. And modify the proxy installation to also copy "winmm.dll, dxwplay.dll, libogg.dll, libvorbis.dll, libvorbisfile.dll" to the game folder. Maybe add a check in there to see if the user has enabled the Virtual CD audio flag before copying those extra files?
I think you're right: the proxy mode is enabled by the fact that the game links the fake system dll (either ddraw.dll, dinput.dll, .... Beware: NEVER put more than one proxy dll in the game folder or the trick won't work!) who automatically loads dxwnd.dll, so there's no check for task names.
Furthermore, when dxwnd.dll is loaded the game is started already, so there's no possible use for startfolder or launchpath. All these fields could be cleared in the dxwnd.dxw file generation, but they make no harm (and could be useful to re-import the configuration back in DxWnd.exe, so why do that?
About Virtual CD audio, a small (ehm.. small? try counting the number of function calls in there ...) winmm.dll proxy is the original solution, also existing in GOG games, but it could bring a problem: winmm.dll doesn't hold only mci sound calls, it also have system calls for movie, joystick, timing and other stuff that DxWnd could be interested in hooking. I fear that a winmm.dll proxy could interfere with that. I should try to be sure.
Right you are. The proxy does not care about those path fields at all so this is really a completely moot point.
As for the winmm.dll proxy I see what you mean now. The number of calls in there is quite daunting. I was looking at the already existing stand alone winmm wrappers and it seems that they have a lot of issues. Mainly they are no where near as good as what is included with Dxwnd.
Here is a winmm.def listing from the stand alone winmm-ogg wrapper:
The ones I saw until now were mainly designed having one specific game in mind: this is why they're not as good as DxWnd: each game uses a tiny bit of mci capabilities and there's no point in adding unnecessary stuff, both unused call wrappers or variations in the syntax. On the contrary, DWnd tries to be a one-fits-all software, so you have good chances that it could apply to untested games, and in any case you can always post here your "case" and wait for me to fix the code ;)
P.s. another weird idea I have in mind (but it's not at all a invention of mine) is to automate the proxy code generation: now that I learnt how to walk the dll PE structure, it should be easy to make a tool that outputs some C code with all function declarations and other stuff to build a generic proxy... this way the number of dll entries wouldn't frighten me no more.
Last edit: gho 2018-10-17
Wait just a minute here...
Now I got the Virtual CD audio playing just fine with the proxy setup.
Testing with the game Pandemonium!
All I did was install the ddraw proxy from the Dxwnd GUI making sure the sound tab had "virtual CD audio" enabled of course. Then I also manually copied the "dxwplay.dll", "libogg.dll", "libvorbis.dll" and "libvorbisfile.dll" to the game folder.
I swear I tried to do exactly the same thing several times before and the music did not play. And now it is suddenly working just fine.
Weird, but I'm rather used to weidness with proxy configurations. Anyway, there's a little trick to try getting more information about what's going wrong: the proxy command clears all the log flag when writing the dxwnd.dxw file, but after that you can copy the value from a dflagn field from within dxwnd.ini (picking one entry that has the logging you wish, of course) and paste that value in dxwnd.dxw (making sure that the left part remains "dflag0"). This way the proxed game will write its own dxwnd.log file.
Maybe I should add a small dialog to the procedure to select whether to keep or clear the log flags ...
Last edit: gho 2018-10-17