Re: usingEuphoria.com is back online
- Posted by ghaberek (admin) Feb 16, 2018
- 2106 views
Thank you, Greg
Am both surprised and sorry that there has not been a series of responses praising these articles! I have found them very interesting as well as useful, and have learnt quite a number of practical things by reading and applying them.
Thank you for your feedback. It's good to know I'm reaching people with my work. This has been a lot of work but it's worth it if people are learning Euphoria.
One reflection on the article about using multiple versions on the same Windows PC: where would you recommend putting dlls when you are trying to run both 64 and 32-bit versions?
Perhaps some wisdom on using dlls is in the pipeline; I still find the reference in the manual to "normal search path" rather too vague for diagnostic purposes.
Yes, I do plan to cover using and wrapping shared libraries with Euphoria. There's quite a lot of material to cover there and I have a lot to say and share.
For now the best advice I have is to place libraries you'll be using with Euphoria right next to the interpreter in its specific %EUDIR%\bin directory.
Leaving aside the 32/64 issue, am I right to assume that there is also a C-compiler issue that makes some dlls load in V4.1.0-64 and not in v4.0.5-64, and vice versa? If so, this is not helped by the fact that some distributions of dlls give no clue as to how they were generated. (At least having the multiple versions makes testing these differences really easy, even if the outcome is not always clear!)
Yes and no. It really depends on whether we're talking about native C libraries or translated Euphoria libraries.
Native C libraries
If you're using native C libraries then (ignoring 32/64 bit) there are only two common scenarios to worry about: STDCALL and CDECL calling conventions. The manual does address this:
How do you know which is which? Typically STDCALL libraries are generated by Visual C/C++ for Windows-only and CDECL libraries are generated by GCC/MinGW for cross-platform. Linux does not use anything but CDECL.
I typically determine this by examining the header files, which typically define the calling convention somewhere. There are a lot of caveats but what I'm describing covers 99% of all cases.
Translated Euphoria libraries
If you're translating your Euphoria code into a shared library then, well... don't. Sorry. I mean, you can do it and it will work as long as you don't cross the streams!
That is, if you create a library using Euphoria 4.0.5 then only use it with Euphoria 4.0.5. Same goes for 4.1.x; same goes for 32-bit or 64-bit.
There are differences to the internal structure of objects between each version that will cause you all sorts of problems:
| Euphoria 3.1 | Euphoria 4.0 | Euphoria 4.1 |
|---|---|---|
| struct s1 { object_ptr base; long length; long ref; long postfill; }; |
struct s1 { object_ptr base; long length; long ref; long postfill; cleanup_ptr cleanup; }; |
struct s1 { object_ptr base; #if INTPTR_MAX == INT32_MAX int length; int ref; cleanup_ptr cleanup; int postfill; #else cleanup_ptr cleanup; intptr_t ref; intptr_t length; intptr_t postfill; #endif |
I don't think you expected a dissertation as a response, but I'll come back to this for reference when I'm ready to write that article.
Please keep up the good work!
Thanks again.
-Greg
