Windows failure

[Dancpaz]

SoundCenSe is not currently compatible with Dwarf Fortress 64-bit on Windows.

You are using Process.MainModule to identify and get the path to Dwarf Fortress and its log files, but this property is not available from a 32-bit process to a 64-bit process. Normally it would throw an exception, but in this case it is buried in a try/catch that assumes all errors mean Dwarf Fortress closed, so it swallows them silently.

I thought you would want to know that SoundCenSe is not compatible with 64-bit Dwarf Fortress and why, if you did not already.

[Algorithman]

Thanks.
I really need to rewrite it completely, though RL work has kept me from working on it.
There also is a rust variant out there (soundsense-RS) if you want to try that.

[Dancpaz]

Oh, the original works, but I find myself a bit diverted by this issue. I decided to see if I could create a more flexible wrapper for FMOD. I do not get a lot of free time, so it is slow going; however, I currently have Channel, ChannelGroup, ChannelControl, Memory, and parts of System, converted to use a dependency injection approach, with all the DLLIMPORT stuff abstracted behind interfaces. Each interface gets one implementation for x86 and one for x64, each referencing a different DLL. My hope is that this will allow an app like SoundCenSe to build for x86, x64, or even "Any CPU", sorting out the dependencies at runtime. But again, I am not sure if I will go the whole mile here. Even armed with regex replace, it is a good bit of work.

[Algorithman]

You probably don't have to go to these lengths.
Something like this

[DLLImport("myDLLx64.dll", EntryPoint="myDLLfunc")]
 public static extern int myDLLfunc64();

 [DLLImport("myDLLx86.dll", EntryPoint="myDLLfunc")]
 public static extern int myDLLfuncx86();

public static int myDLLfunc()
{
  if (IntrPtr.Size==4)
  {
    return myDLLfuncx86();
  }
  else
  {
    return myDLLfunc64();
  }
}

should be enough i think.

[Dancpaz]

That would certainly make things a lot easier, thank you. I do not have much reason to use extern and such, so my knowledge is limited here.

…

On Wed, Apr 13, 2022, 10:28 PM Algorithman ***@***.***> wrote: You probably don't have to go to these lengths. Something like this [DLLImport("myDLLx64.dll", EntryPoint="myDLLfunc")] public static extern int myDLLfunc64(); [DLLImport("myDLLx86.dll", EntryPoint="myDLLfunc")] public static extern int myDLLfuncx86(); public static int myDLLfunc() { if (IntrPtr.Size==4) { return myDLLfuncx86(); } else { return myDLLfunc64(); } } should be enough i think. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3XPPQS3N5FC5WFRBS6UD3VE6UGBANCNFSM5TFEDWSA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Dancpaz]

Oh, nevermind. I misunderstood. Reading in email, I didn't see that it was 3 separate functions, and I thought you had simply decorated one function twice and that C# would pick the appropriate one, and you really had me interested.

Yeah, that is one way to do it for sure. It is more work to convert to a DI approach, but not by too much. Either way I am duplicating the methods more than once, which is the bulk of the work. I do prefer DI, though.