OpenEuphoria

1. making a dll, pt2

• Posted by useless_ Sep 29, 2012
• 1477 views

If a GotEverything.dll was made with all the std lib in it, and when it loaded it made a table of where all it's procs and funcs were located, it would be a big dll. But, if, then, another dll was made that was not bound to anything during translation (euc -dll -nobind filename), that dll would be very small.

Even if the app you write is bound to the Eu internals and externals it uses, so you can trace, profile, etc, it may not have all the code a dll needs, and this is why a Eu dll is made bound to the code it uses (except for callbacks).

So what if you had a GotEverything.dll, then you can load very tiny dlls with no bindings, and they'd get the table the GotEverything.dll made up, so the tiny.dll could dynamicly link and could run the code as if it was theirs, which is the whole point of reuseability and dynamic linking.

These tiny dlls with no bindings might translate pretty quickly, and save to disk, where they can be loaded by a open_dll() covered over by a eval() wrapper.

This has been an exercise in narrowing the definition of Dynamic Link Library (as far as Euphoria is concerned) to be a new DLL.extension (.eul? .etl?) which is not repeating executeable code held in all the other DLLs that have been, or might be, loaded.

useless

3. Re: making a dll, pt2

• Posted by useless_ Sep 29, 2012
• 1410 views

You can compile an include as a dll already, it's just you cannot debug-step thru it, and calling the routines is a lill different and takes some more effort.

I mean -binding and -linking, so a Eu source file like http://openeuphoria.org/pastey/152.wc (once you remove the 3 includes and the sleep statement) would "euc -dll -bind -include" as a 1Kbyte file, not a 1Megabyte file. All that would be added would be the code to accept the first (and hidden from user) call to establish where the rid table is in the GotEverything.dll.

As a dll instead of an include, the dll can be unloaded or kept, as desired. And another one or 50 loaded, as needed. Regardless of my app or Greg's app for this, if Eu is ported to the Ras Pi, Arduino, or any of the other micro machines, there's a definite lack of memory space on those, and this ability could be a great benefit there.

My point was sorta that Eu dlls, which as Eu programmers we can call strictly from Eu apps, are bound to and include all the same executeable code as every other dll we link to, and every include we use. This sorta defeats the purpose of a dll, to make code available *once* for each and every app loaded afterwards to use. Granted, the translator (euc) can't make a guess as to what will be available at runtime when it's loaded, and it likely will not be in the bound app that called it, so the translator throws in and binds everything called, including the kitchen sink, to the dll. If i load 20 dlls essentially like pastey 152.wc, i've used 20 megabytes for less than 1K of code, and 19.99 megabytes of it is all copies of the same code, which isn't in the spirit of the DLL philosophy.

I have not thought so far ahead to this maybe this kind of dynamic linking making these "special Eu dlls" more amenable to tasking.

useless

5. Re: making a dll, pt2

• Posted by SDPringle Sep 29, 2012
• 1420 views

The philosophy of the DLL is also to allow upgrading bug fixes in all apps by only fixing the dll. The problem is, it seems to be impossible for most developers to restrict changes to only bug fixes when it comes to dlls even amoung patch versions. Take SDL, where between one patch version the meaning for the alpha channel changed from opacity to transparency (or vice versa), I don't remember. This habit leads to every app distributing its own version of a dll and defeating this upgrade advantage. It also means if it works with SDL 2.4.2, we have to abort and die with SDL 2.4.1 and below or 2.4.3 and above.

A good thing about EUPHORIA is that there have not been changes in the language definition for patch versions (at least since 4.0). Supposedly we could get a big speed up in translation time with the dot-e files were converted to dlls like in python.

Shawn Pringle