I am trying to understand how demo software connects to a device for controls. I'm told that C++ bindings to windows dynamic libraries is necessary and have bene sent a *.h file which contains as an example:
I cannot get how sockets appear to be involved, but typical intercommunication with a device is organized this way: a client loads SDK dll that wraps various DeviceIoControl calls. Every call reaches corresponding device kernel mode driver, and the latter operates with low-level hardware-specific routines that actually control the device. As you can see, there's no socket in this scheme.
Thank you for your responses. Of course I did not provide enough information. I should have indicated that it was a tcp/ip connection between the client and the controlled device.
I asked about an API feature on the IP controlled device and was told that control is exercised via C++ calls within windows dynamic libraries. I was provided with a .h file that seemed to contain the calls and declarations and also seemed to start with SDK_.
The calls would seem to correspond to functions that I would have expected exist in the remote device, ie, initialise, turn on feature, turn off feature, return information.
I guessed that a winapi/winsock program might use sockets to connect to a port and then send these functions somehow and check return status. Simple C++ client.
Within the SDK dll, the manufacturer is free to use whatever they feel like. The DLL wraps up their raw protocol into something a little bit easier for application developers to integrate their programs with the device. There's probably some underlying protocol used by the manufacturer and you could possibly sleuth it with a packet sniffer, but why?
Within the SDK dll, the manufacturer is free to use whatever they feel like. The DLL wraps up their raw protocol into something a little bit easier for application developers to integrate their programs with the device. There's probably some underlying protocol used by the manufacturer and you could possibly sleuth it with a packet sniffer, but why?
I'm trying to understand from a control perspective. If I can attach to the device over the network and send it some basic commands, I could get as small app written to control the device, or at least some of the functions.
Hence trying to understand e.g SDK_init_system() and how that gets to the device over an IP socket.
The calls would seem to correspond to functions that I would have expected exist in the remote device
The "function" most probably is distributed between client (SDK dll) and server (networked device firmware) sides. Both sides implement the "function" in whole. This is what hoxsiew called a protocol: how both sides interact to each other.
That small app is your SDK dll. What makes you think you could control the device a way better than SDK manufacturer does?
Manufacturer does not use programatic control. They uses a remote control. I would prefer to use a program to control about 4 functions. They have said they have a sdk but it is not used/documented and no demo code.
I guess its not as simple as writing a winsock app that calls some of the routines in the provided .h file. Shows my lack of understanding.
Maybe the SDK_InitSystem() in the .h correponds to the SDK dll routine which 'calls' functions to initialise the system?
You can see my problem here? The SDK is not well documented for me. I was only given the .h file and I am trying to determine if its useful or to give up on my approach.
The .h file contains declarations that correspond to the functions I want to control.
I was hoping that with the .h file and the compiled 'provided' SDK file, I could use the routines in the .h file to write winsock app that would work. That way I don't need to deconstruct the SDK dll file at all. The .h file would provide the clues.
Manufacturer does not use programatic control. They uses a remote control.
Frankly, I hardly understand what you try to say, maybe because you're not a programmer.
The "SDK_InitSystem() in the .h" is just a hint for a compiler how the call must look like. The SDK_InitSystem() function code itself resides in the SDK dll (not in the remote device!!!), and client application just links to the dll at runtime to make that call. So you only need to link to SDK dll, and no other socket programming is required, as it's already implemented in the dll.
Last edited by Igor Vartanov; June 26th, 2010 at 06:58 AM.
Frankly, I hardly understand what you try to say, maybe because you're not a programmer.
The "SDK_InitSystem() in the .h" is just a hint for a compiler how the call must look like. The SDK_InitSystem() function code itself resides in the SDK dll (not in the remote device!!!), and client application just links to the dll at runtime to make that call. So you only need to link to SDK dll, and no other socket programming is required, as it's already implemented in the dll.
Understood and appreciate your explanation.
Let me see if I got it right:
If I create a client application (compiled & linked with SDK.dll) - it should be able to call routine SDK_InitSystem() and any other routines which represent compiler 'hints' in the .h file??
If I create a client application (compiled & linked with SDK.dll) - it should be able to call routine SDK_InitSystem() and any other routines which represent compiler 'hints' in the .h file??
Bookmarks