[Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 195
  • Last Modified:

"C" DLL File, LAN's and WAN's, and make it work.

To all wizards:

 I have a "C" DLL file already built and running, but I want to have the DLL
accessible(callable) from anyway within or on a LAN and/or WAN( and even
multi-WAN's), or even on a PC.  I built the DLL file, via VC++'s (v6.0)  ATL
COM AppWizard area with MTS clicked on, and it works quite well.  But as
 for using this DLL file on LAN's and Wan's, (I do not have access to any type of network),
 do I need to add any more code into the DLL file, so it will work on/under a network and be callable anywhere on a LAN's or WAN's or even on standalones by any and all application(s).
 If I need some additional code, can you tell me why, and can I get it in simple
 "C" source code.  Any help would surely be greatly appreciated.  Thanks(TIA),


  • 3
1 Solution
midnightexpressAuthor Commented:
Oh, on the question I just posted:  I forgot to clarify ---
Question Title: "C" DLL File, LAN's and WAN's, and make it work. " this is not homework.
Julian HansenCommented:
The simple answer is no. A DLL runs in the same process space as the calling application and a shared location on a network is essentially a "local" hard drive on the end of a long wire so from a functionality perspective there will be no difference between loading the DLL off a local drive or off the network. From a performance perspective there might be an initial hit when the DLL loads but fine after that.

In terms of chaning your code - it depends how you are loading the DLL. If you are using LoadLibrary to load it then you will need to ensure that this call includes the path to the DLL - I am assuming here that in a LAN / WAN environment your DLL is not going to lie somewhere in the path so a full path name is required.

This raises some interesting issues - re the path to the DLL - if it is on a different path for different machines then the LoadLibrary call has to be passed a variable (from an INI, registry or command line parameter) that tells it where the DLL is located. If the path is the same from all locations no problem.

I am also going to assume this is a plain old simple DLL not a COM DLL. If it where the latter you would not need to change your code but you would have to ensure that the path to the DLL (where it was registered from) is done correctly from each machine and remains consistent.

Not sure if that answers your question.
Julian HansenCommented:
To clarify

>>  if it is on a different path for different machines then the LoadLibrary call has to be passed a variable

Means that the path parameter in the LoadLibrary call would need to be constructed dynamically based on some value passed to or read by the application to ensure the API can find the DLL in question.

Julian HansenCommented:
Thank you

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now