C++ DLL Socket Understanding

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:

/ / Function interface
/ / Initialize dynamic link library
DLL_DECL BOOL SDK_InitSystem ();
DLL_DECL BOOL SDK_IsInited ();
/ / Unloading dynamic link library
DLL_DECL void SDK_CloseSystem ();
/ / Callback function prototype information
typedef void (CALLBACK * MTCSDKCALLBACKFUNC) (DWORD dwMsgID, WPARAM wParam, LPARAM lParam);
/ / Register callback function message
DLL_DECL BOOL SDK_RegisterCallBackFunc (MTCSDKCALLBACKFUNC CallBackFunc);
/ / Connect Terminal
DLL_DECL BOOL SDK_ConnectMT (DWORD dwMTIP);

I presume these functions exist in the device and are called somehow via a socket connection created in a winsock program which links in the .h file?

I'm not a programmer, just trying to understand how this might work.

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.

So if there is no socket connection how does the wrapped SDK client calls (DeviceIoControl) get to the controlled device over IP network?

You never told before that the controlled device is over a network, please re-read your post. You know, devices may be of very different sorts. ;)

Hi Igor,

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.

But I have little idea only intuition.

Thanks.

/geo

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?

Quote:

---

Originally Posted by hoxsiew

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.

Unknowable without the source code for the dll.

Quote:

---

I could get as small app written to control the device

---

That small app is your SDK dll. What makes you think you could control the device a way better than SDK manufacturer does?

Quote:

---

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.

Quote:

---

Originally Posted by Igor Vartanov

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.

Maybe I have no clue.

Thanks for your help.

Quote:

---

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.

Quote:

---

Originally Posted by Igor Vartanov

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??

Thanks for your patience wth me

Quote:

---

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??

---

Yes. Actually, this is what any SDK is for.