ott wrote on Yesterday, 18:03:
Falcosoft, thanks for explanation! But how does the Creative ALchemy utility detects EAX functions?
The Alchemy library does not have to detect anything besides hardware/driver capabilities directly. It's the other way around. Alchemy implements the interfaces of Directsound (dsound.dll ). The application executable detects the new dll in the application's folder and calls these new implementations instead of the original ones.
This works this way since dsound.dll itself if explicitly linked. But the only imported functions by the application (and exported functions by the dll) are the DirectsoundCreate related ones. All the other functions are reached by the application at run-time by querying the interfaces of the created Directsound object. All COM libraries work this way.
To be clear: Applications that use Directsound can be detected since dsound.dll is explicitly linked and DirectsoundCreate/DirectsoundCreate8 etc. functions are explicitly imported by them. But EAX usage cannot be detected this way.
@Edit:
Directdraw works the same way as Directsound. That is only DirectdrawCreate is explicitly imported from ddraw.dll and all the other functions are reached by the application at run-time by querying the interfaces of the created Directdraw object.
I could not find an example program of mine that uses Directsound directly but I could find one that uses Directdraw. I hope the following screenshots show the problem of COM call detection.
1. It can be seen that only DirectdrawCreate can be found in the import section of the executable (it is analogous to DirectsoundCreate):
The attachment ddraw2.png is no longer available
2. It can be seen that debuggers/static executable analyzers can identify the call of DirectdrawCreate (or DirectsoundCreate) but the method calls of the Directdraw object cannot be identified ( the situation is the same in case of Directsound).
The attachment ddraw1.png is no longer available