Re: coding in auto it3?
@12, you can't. Pure and simple. Its closed source.
Also, calling functions from DLLs without C headers or language bindings is hard to get right. There is no type or parameter checking, no safety nets, no safety checks, no length validation, etc. You can call a function in a DLL that requires 10 parameters and only give it 6. Or you can give it none. Even in .NET it is difficult to do and I would highly discourage it unless you have no choice and you know what you are doing. There's a reason that this is the way it is -- your calling a DLL that may not be written in the language your programming in. The compiler and runtime have absolutely no idea how the function works nor do they have its code to look at. This is exactly when the saying "Anything to do with shared libraries is dangerous" rings true -- because it is. Even in Rust there is no "safe" way to do it -- you must use unsafe to make any DLL calls. BGT may require you to put the function signature in, but internally that's only so it can type-check your code. You can put an invalid signature in there too and it wouldn't be able to stop you. It would make the call and your only thing to do would be to hope to god that you wrote the signature right and you know the library in and out. You can look up functions in a DLL but you can't look up its signature.
The only way you could do that is if you had the debugging symbols, and since no library ships that unless its open source... good luck getting those.
Also, did I mention that calling functions from DLLs is messy as all hell, even when not using the win32 API? Even in Go -- which did its best to simplify the entire process -- its messy. Here's an example of me calling a Tolk function from its DLL (since there are no Tolk bindings in go):
import (
"golang.org/x/sys/windows"
"unsafe"
)
// loading code
var (
dll *windows.DLL
load *windows.Proc
unload *windows.Proc
hasSpeech *windows.Proc
hasBraille *windows.Proc
output *windows.Proc
speak *windows.Proc
braille *windows.Proc
isSpeaking *windows.Proc
silence *windows.Proc
)
func Load() {
dll = windows.MustLoadDLL("tolk.dll")
load = dll.MustFindProc("Tolk_Load")
unload = dll.MustFindProc("Tolk_Unload")
hasSpeech = dll.MustFindProc("Tolk_HasSpeech")
hasBraille = dll.MustFindProc("Tolk_HasBraille")
output = dll.MustFindProc("Tolk_Output")
speak = dll.MustFindProc("Tolk_Speak")
braille = dll.MustFindProc("Tolk_Braille")
isSpeaking = dll.MustFindProc("Tolk_IsSpeaking")
silence = dll.MustFindProc("Tolk_Silence")
load.Call()
}
func Unload() {
unload.Call()
dll.Release()
}
func Speak(text string, interrupt bool) {
str, err := windows.UTF16PtrFromString(text)
if err != nil {
panic(err)
}
speak.Call(uintptr(unsafe.Pointer(str)), uintptr(unsafe.Pointer(interrupt)))
}And with return values:
// Same code context as above
func HasSpeech() bool {
r1, _, _ := hasSpeech.Call()
return *(*bool)(unsafe.Pointer(r1))
}Can I say that this is correct code? No, I can't. I cannot guarantee that I am doing this properly. I know that the speak code is correct -- but that's only because I tested it, though with the interrupt variable thrown in there, that may have broken things. Here's how you might do that in C++ (calling the MessageBoxA function), raw win32 API:
#include <windows.h>
// We load user32.dll instead of taking advantage of the fact that windows.h already provides this for us
typedef int(*MsgBox)(HWND, LPCSTR, LPCSTR, UINT);
int main() {
// Load our library
HINSTANCE lib = LoadLibrary("user32.dll");
if (lib != NULL) {
MsgBox msgbox = (MsgBox)GetProcAddress(lib, "MessageBoxA");
if (msgbox != NULL) {
(msgbox)(NULL, "test", "test", 0);
}
FreeLibrary(lib);
}
}Notice how here I have left out a lot of error checking. A fuller example can be found at https://docs.microsoft.com/en-us/window … ic-linking. In C# its a lot easier:
using System;
using System.Runtime.InteropServices;
// ...
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);But even then you need to correlate C++ types and C# types. And this doesn't take into account C++-based DLLs which could have classes (but more often than not have C interfaces).
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
