Has anyone considered writing a book which covers only the concept of creating and using DLLs in OP/FP?
A Wiki article might be a more achievable goal with ongoing multiple author contributions and accessibility being the main advantages.
Is it as complicated as your idea?
I just can't seem to find any examples to help guide me through creating such a monster in OP (it's easy to do in .NET). Most examples I see of classes within DLLs just show exporting simple procedures, so they're not a lot of help.
There a few entries in wiki, but, IMHO the information is not very complete.
And now I looking how to deal with a C++ library, but I'm not sure how to start.
For the type of DLL I'm thinking I need (perhaps mistakenly),
Again, creating a DLL is easy enough. However, for programs written in some languages, if more than one program uses the same DLL, only one of those programs can be open at a time. Or rather, only one of those programs at a time can make a call to the shared DLL without creating a new instance of the DLL. Otherwise, a sharing violation error is raised.
Now, here is where my lack of experience in OP/FP shows:
1. If two or more programs share a DLL written in OP/FP, does each program need to create a new instance of that library using a variable (object variable?) when calling it in order to avoid a sharing violation (as is required in some other languages) if two of those programs are open at once? Or, can each program make a direct call to (load) the DLL without the need to create a new instance of it and not risk an error?
2.Given the info in question #1... does an OP program automatically create a new instance of the DLL when loading it? Or, would each program try to share the same instance of the shared DLL if each does not specifically create a new instance. I honestly don't know with OP/FP.
3. If the answer to #1 & #2 is that each program must create a new instance of the shared DLL, does doing so require that a class (or classes) be used within the DLL because one would actually be creating a new instance of the class rather than the DLL?
I have about 3 DLLs that I use in all of my programs. Each DLL contains methods, records/enums, properties, and events which need to be accessed or made available to every program I write. Regarding the events... when an event is raised within the DLL, the program is notified via a "With Events" notation in the DLL's variable declaration. The program then decides how to handle the event (rather than the DLL itself) according to the info/data passed when the event within the DLL gets raised.
Does this clarify a bit more what I'm trying to acheive?
If you load a library dynamically you do a LoadLibrary and then the operating system ensures that your program instance has its own private “instance” of that library (even if e.g. the code or read only data sections might be shared between these multiple instances). After that you retrieve your function pointers using GetProcAddress and call them as you see fit. It's all transparently handled by the OS.
In both .NET and Java, when you create an object from (link to or load) a DLL written in one of those managed languages, you are actually creating a new instance of a class within the DLL, rather than creating an instance of the DLL itself. Why? Because in such cases it is handled by the managed platform (.NET/Java) rather than by the OS. In reality, though, it is the managed platform by which the program communicates with the operating system, which subsequently handles the library. However, when writing a .NET/Java application which loads a DLL created in some other language such as a C/C++ based DLL, then you do create an instance of the actual DLL itself, because there is no managed platform acting as a virtual machine liason between the program and the operating system. Therefore, the library is handled immediatley by the OS without a managed platform/virtual machine (and classes) acting as an intermediary.
Okay, this is getting way out of range from what I'm talking about and doesn't reflect what I'm saying. From the beginning there seems to be a complete misinterpretation or a loss in translation, so I'm just going to say here that I got the information I needed and finished my DLL - it works perfectly.
It's getting out of hand, because you either have a wrong concept of how libraries work