Firstly let me say thank you for responding and that i am not trying to @Cyrax,
The DYLIBs I'm trying to get working are all ported from Delphi DLLs. There is nothing I'm trying to implement that isn't already functioning under windows. Your reference (it's a 2006 article) makes comment mainly about DLLMAIN which is a Windows only construct that I now don't use because it is not cross-platform (I used to use it, but now just use the units initialize and finalize sections orI have also coded same with an initialise function, ie. as you authenticate (say) via a function within the DLL - the first thing it does is perform initialise, a number of ways to skin that cat and this relies on absolutely nothing special, ie. it doesn't need DLLMAIN to function and doesn't need any initialze/finalize construct). FWIW I do exactly what the referenced article recommends in initialize, ie:
The following tasks are safe to perform within DllMain:
Initialize static data structures and members at compile time.
Create and initialize synchronization objects.
Allocate memory and initialize dynamic data structures (avoiding the functions listed above.)
Set up thread local storage (TLS). <-----NOPE
Open, read from, and write to files.
Call functions in Kernel32.dll (except the functions that are listed above). <----NOPE
Set global pointers to NULL, putting off the initialization of dynamic members.
In Microsoft Windows Vista™, you can use the one-time initialization functions to ensure that a block of code is executed only once in a multithreaded environment. <-----As you can with the Initialize section or with an initialize function
There is nothing in that best practice that says a DLL cannot react with the environment.
@marcov,
It isn't/does not appear to be an issue with Delphi and DLLs in Windows. You can access the RTL and units like Forms, Dialogs etc. For example (and yes I know some say you should never use it) FMX Application.Processmessages is in the Forms unit. Unless you have access to that unit then you do not get the Application Object. And the Dialogs unit?, without that you cannot even do a showmessages so your DLL becomes hermetically sealed.
I use the DLL(s) to perform such things as Authentication (which needs to pop a web browser), provide an alert system (which accesses the Windows message pump and some other construct on the OSX side) and to update various Drive status (using callbacks). The DLL(s) are called by other (C++) DLLs and by other Delphi and C++ Programs. To that end the only parameters in/out are pChars, booleans and integers. They all function fine in the Windows World.
So you suggest that the issue is that access to the LCL seems prohibited? As noted, in the Delphi world that isn't an issue. Windows seems to think that's OK as well (for example the dialog Comdlg32 DLL which clearly interacts with the outside world, and SnapIns for example use DLLs to store UI).
So it seems that it is common practice for DLLs (and I assume DYLIBs) to interact with the environment and to do that with Lazarus/FPC then the software needs access to the various units that provide access (Forms, Dialogs, Interfaces etc etc) so why would LCL and LCLBase not be accessible? And, if like you say LazIndy uses the LCL then it is shown as RED when I try to add the requirement, I can Add TMSLCLCloudPackPkg - this is a commercial package that does similar things (REST access to cloud services - and use the Forms/Dialogs/etc units) and I can add that as a requirement. To me, it seems like there is a BUG in the Requirements add routine. It shows LCL/LCLBase/LazIndy as being ONLINE (ie. not installed). Look at the attached image, see the packages that are supposedly ONLINE, but are actually local. And look at the many other packages that are local and would require integration with the outside world.
I'm not suggesting you ate wrong, I'm just suggesting it doesn't make any sense to me given what DYLIBs and DLLs do actually do and what packages are and are not available. What is the criteria for the system deciding that a package is local or online, the logic escapes me.
And, of course when you try to install the 'ONLINE' package, there is nothing there to install (because it is already installed), see second image.
So I guess, without any definitive solution, all I can do is try to get my DLIB to function using the hack mentioned in my earlier post by editing the LPI file directly.
Yours in confusion,
Kevin