Re: making a dll, pt2

new topic     » goto parent     » topic index » view thread      » older message » newer message
SDPringle said...
useless_ said...



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

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


Good points, but i was talking about code we mere mortals write, not the core Euphoria language as the developers write it.

If i need this giant list of data, with various Euphoric rules for applying it, and each file grows from 500bytes to a megabyte or more, i cannot use Eu DLLs for it. Likewise if raseu needs many functions, but in a tiny memory footprint of the Pi, it's much more feasable and faster loading if the DLL isn't linked and bound when it's made, but is truely a Dynamically Linked Library when it loads. Right now, if raseu needs to include wildmatch.e in every file, then he has a copy of wildmatch.e in each and every dll he loads, overwhelming the Pi's memory size. Ok, wildmatch.e isn't huge, but win32lib is, and it includes tons of other files, which include more files, etc.. It would be easy to add up a couple megabytes of copies of include files in each DLL.

Of course, right now there is the memory leak issue with DLLs. Matt has reduced it, but there's still a leak.

useless

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu