Walter wrote:

> Memory management is never totally ignorable, in any language. And I know of no DLLs in any language where one can totally ignore memory management and not get into nasty trouble.

Might that be an inherent Windows problem? In Linux, I see no direct connection between memory management and dynamic linking at all. Each process has its memory and it does not matter at all whether the code of that process is statically linked or placed in a dll.

Also, the versioning of dlls is not a problem at all under Linux. Of course, one has to be careful about it, there are tons of sophisticated tools to help with that.

What is important to consider: Dynamic loading is not just a means of saving diskspace and RAM but also a very important method for plugins and other kinds of sophisticated programming methods.

I know, that under Windows, DLLs are such a hassle that it really is the easiest solution to avoid them, but then, using Windows at all actually is such a hassle that it is the easiest solution to avoid using it...

Norbert Nemec says...
>
>I know, that under Windows, DLLs are such a hassle that it really is the easiest solution to avoid them, but then, using Windows at all actually is such a hassle that it is the easiest solution to avoid using it...
>
Norbert: I agreed with your other points...but in the sentence above, I really wish you'd be more careful about stepping on another man's OS. I've been making a good livelihood programming Windows applications in MS Visual Basic v6.0 SP6 my primary language (not everyone has come to D from the C/C++/Java/C# .net world). And to tell the truth, I've never had any real problems with creating and using DLLs, only when writing them in C (my past second language choose, now it's D then followed by C) which most of the time it was somethiing I wrote incorrectly. So this whole Windows' DLLs are a hassle thing seems like wishful thinking on your part to me.

Besides, if Linux is your thing, more power to ya! In fact with Linux growing like it is, I think MS will be forced to make an even better Windows OS...so we both win!! :))

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

David L. Davis wrote:

> Norbert Nemec says...
>>
>>I know, that under Windows, DLLs are such a hassle that it really is the easiest solution to avoid them, but then, using Windows at all actually is such a hassle that it is the easiest solution to avoid using it...
>>
> Norbert: I agreed with your other points...but in the sentence above, I really wish you'd be more careful about stepping on another man's OS.

OK, sorry for becoming a bit polemic in that sentence above. It's just that I've had years of intricate experience with Windows myself, so I've built up a certain amount of steam which shows up once in a while. I hope everybody will understand from the words above, that this is a personal opinion. I am still willing to live in peace and cooperate with anybody who doesn't share it.

> I've
> been making a good livelihood programming Windows applications in MS
> Visual Basic v6.0 SP6 my primary language (not everyone has come to D from
> the C/C++/Java/C# .net world). And to tell the truth, I've never had any
> real problems with creating and using DLLs, only when writing them in C
> (my past second language choose, now it's D then followed by C) which most
> of the time it was somethiing I wrote incorrectly. So this whole Windows'
> DLLs are a hassle thing seems like wishful thinking on your part to me.

Sorry to disagree here. VB certainly is a nice language, but you should be aware that it shields the programmer from the operating system by a good deal. The intricate details of creating and using DLLs are covered by the programming system, at the cost of performance and flexibility.

As you state, you already gained experience with handling DLLs in C, so you know the difficulty. It is just this complexity that D has to deal with. Of course: 95% of the problems arise from incorrect code by the 'user'. The 'hassle' that I am talking about is the difficulty to get it correct.

I did some (relatively simple) DLL programming on Windows myself, so I really can compare it to Linux. I know Linux much better, so I'm certainly biased (assume you guessed that already... :-)  ) but it certainly is more than wishful thinking when I talk about the hassles of programming Windows without a huge safety-belt like VB.

> Besides, if Linux is your thing, more power to ya! In fact with Linux growing like it is, I think MS will be forced to make an even better Windows OS...so we both win!! :))

I fear, history shows, that MS will first try to pull all other tricks out of the box (law suits, FUD, etc.) before actually sitting down and improving their products. :-(

>"Kris" <Kris_member@pathlink.com> wrote in message news:csse93$1jq1$1@digitaldaemon.com...
>> >Why not use D interfaces?
>>
>> It would be great to use interfaces. I presume you mean "in conjunction
>with a
>> Factory Pattern" ?
>>
>> Surely the obvious problem is this, Walter:
>>
>> 1) the factory (within the DLL) would create the implementing class, and
>hand it
>> back to the caller
>> 2) the caller now hangs onto the returned interface handle
>> 3) the DLL GC thinks there are no more references to the constructed
>class, and
>> reaps it
>
>How the gc works is it scans regions for roots. If any those roots point into the gc's own memory pool, the associated allocated memory is not deleted. So the solution here is to add the ranges of the caller where the handle may reside to the DLL's gc. The stack is already there, because the DLL and the caller share the same stack.

So I have to do it on my own. But wasn't a GC about not having to do memory-management on my own. I am confused.

>Another way is to use the COM style AddRef and Release.

In my world there isn't anything like release, close, dispose, ... . Everything is done by RAII. At least this is ture for my C++ code. I haven't done any big project in D, yet. But as RAII is one of D's features I hope I will be able to continue this style.


-- Matthias Becker

In article <ct0v2s$1cl2$1@digitaldaemon.com>, kris says...
>
>Again; the only reason for the pushback on this is Walter's concern over what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, let's put that into perspective: exactly how often would this happen with a GC shared-lib? And, couldn't the "DLL hell" be managed for this one specific case? I think it can. And when you consider the downside of not doing it, one simply cannot fathom the pushback.

Yet there are ways to circumvent the majority of issues involved with multiple dll versions hanging around.  If you break down the whole "dll hell" scenario you get the following patterns:

1) Finding the wrong dll by name.
2) Finding the right dll, with the wrong version internally.
3) Not finding any dll at all due to some sort of misconfiguration.

Which arise due to simple file names (and 8.3 filenames in old DOS systems), a
commmon misconception about what versioning actually does to code, and lazyness
and/or coding mistakes (dll loader code not versatile enough for the current
environment). :)

For D-Dyanmic Libraries, and the proposed GC-DDL itself, I would like to reccomend the following solutions to be used in concert:


1) encoding the build version into the library filename.

This is *really* easy to do, and could possibly be better managed by dmd or d-compiler toolchain of some kind.  For example, if we put the version number into the name of the dll, it will allow multiple GC versions to co-exist within the same directory.

Example:
dgc.0.111.dll
dgc.1.0.dll
mango.1.1.dll
mylib.0.42.dll

The advantages here are obvious: its easy to see what you have, and all the more so when placed in the same directory.


2) exposing a standard DDL function, for all DDLs, that returns the current build or GUID/UUID based on the program name and version (akin to strong-names for .Net).

Having a verification mechanism is a good way to avoid versioning problems; the application can compensate early (or halt) if the wrong library is found.  IMO, something like this would be best suited by some form of compiler support, although it /can/ be managed manually.

I'll add that its also cross-platform since it doesn't rely on any OS-specific metadata features.

This also opens the door for additional metadata to be served by DDLs in the future, if for instance a sister method could describe the kind of library used (eg. "i have a GC compiled in", "i'm a class library", or "i'm for C compatibility only").


3) providing a standard library loader in Phobos that is more flexible than the
present solutions for windows and unix/linux (std.loader on steroids).

This is critical since a Phobos library hook for folding in point #2 is the most sane approach.  There are also some differing behaviors in how search paths are investigated, that may warrant some inclusion (and discussion) into std.loader.

- The dll search order in Windows is different between versions and ditributions.  Some anecdotes I've managed to dig up in 5 minutes of googling show a wide variety of things.  Basically, the *latest* versions of windows (and service packs) force the OS to search the System file tree before the application directory.  Older versions will do the opposite.

- There is also a useful win32 api function, SetDllDirectory, that is not available on Win2k.

- I assume that unix/linux is pretty much solid since it would likely use the current search path and leave it at that.  Is this so?  It may be a moot point, but unless you can guarantee that /var, /etc, /lib and /sbin (or any other critical system directory) are first on the path, then it has the potential for behavior different from its non-unix counterparts.

I'd also like to advocate that the fact that D is "installation path agnostic", is truely a blessing.  I think we can create a solid GC-Dynamic Library *and* General-Purpose Dynamic Library solution for D without sacrificing this.

- Pragma

I know it's in poor taste to reply to one's own post, but there was one issue I left out:

4) Problem: the possible creation of multiple instances of the exact same DLL in memory.

I can only think of solutions as exotic as the problem itself.  Granted, careful management, and smart loading of libraries (especially the proposed GC-library) may help mitigate this.  Also, the careful installation of such libraries in a system would also be critical; maybe we need to agree on where such common files should be installed?

I think this point really needs discussion.

The only facts I can contribute is that .Net uses a system service to provide a universal hook for the VM and Java (as most here probably know) uses environment vars and the system path.

Perhaps we could use some form of IPC so GC's can "talk" to each other (GC1 to GC2: "hey, I'm new here and we're the same version, so give me your free-list ptr, object-list ptr and mutex so I can help this other process out") is probably out of the question; but it might be worth a try.

It may also be worth noting that all of the above could very well be moot simply because an admin could use *just* the file system to steer apps/libs onto a particular GC instance.  After all, I'm sure having all your D the same exact GC instance might be a problem; isolation is good for plenty of reasons.

- EricAnderton at yahoo

Pragma wrote:

> In article <ct0v2s$1cl2$1@digitaldaemon.com>, kris says...
>>
>>Again; the only reason for the pushback on this is Walter's concern over what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, let's put that into perspective: exactly how often would this happen with a GC shared-lib? And, couldn't the "DLL hell" be managed for this one specific case? I think it can. And when you consider the downside of not doing it, one simply cannot fathom the pushback.
> 
> Yet there are ways to circumvent the majority of issues involved with
> multiple
> dll versions hanging around.  If you break down the whole "dll hell"
> scenario you get the following patterns:
> 
> 1) Finding the wrong dll by name.
> 2) Finding the right dll, with the wrong version internally.
> 3) Not finding any dll at all due to some sort of misconfiguration.

I don't even want to understand that whole issue but just add one comment
for the record:
As I guessed before, this issue really is a pure Windows issue. Under Linux
(and probably under MacOS X also) there is a sophisticated system of
dealing with library versions given by the operating system.

For Windows, I would propose the solution that is used for Windows in general: leave the handling of dll versioning to the installer and don't try to solve it in the compiler. There are a number of installers available for anyone who needs to distribute software.

If somebody wants to link their program statically, this should be an option and it might be the simplest solution for anyone who just writes a single program and wants to save the hassle. Anybody who writes a complicated set of applications and needs to use DLLs, though, should have that option and should be aware that he'll have to solve the versioning and distribution problem himself.

Trying to find a sophisticated versioning scheme for libraries really is a job for the operating system designers. Trying to solve this in the compiler will result in a complicated situation that creates more confusion than it solves.

Pragma wrote:
> In article <ct0v2s$1cl2$1@digitaldaemon.com>, kris says...
> 
>>Again; the only reason for the pushback on this is Walter's concern over what he terms "DLL hell". Yes, that is perhaps of some concern. Yet, let's put that into perspective: exactly how often would this happen with a GC shared-lib? And, couldn't the "DLL hell" be managed for this one specific case? I think it can. And when you consider the downside of not doing it, one simply cannot fathom the pushback.
> 
> 
> Yet there are ways to circumvent the majority of issues involved with multiple
> dll versions hanging around.  If you break down the whole "dll hell" scenario
> you get the following patterns:
> 
> 1) Finding the wrong dll by name.
> 2) Finding the right dll, with the wrong version internally.
> 3) Not finding any dll at all due to some sort of misconfiguration.
> 
> Which arise due to simple file names (and 8.3 filenames in old DOS systems), a
> commmon misconception about what versioning actually does to code, and lazyness
> and/or coding mistakes (dll loader code not versatile enough for the current
> environment). :)
> 
> For D-Dyanmic Libraries, and the proposed GC-DDL itself, I would like to
> reccomend the following solutions to be used in concert:
> 
> 
> 1) encoding the build version into the library filename.
> 
> This is *really* easy to do, and could possibly be better managed by dmd or
> d-compiler toolchain of some kind.  For example, if we put the version number
> into the name of the dll, it will allow multiple GC versions to co-exist within
> the same directory.
> 
> Example:
> dgc.0.111.dll
> dgc.1.0.dll
> mango.1.1.dll
> mylib.0.42.dll
> 
> The advantages here are obvious: its easy to see what you have, and all the more
> so when placed in the same directory.
> 
> 
> 2) exposing a standard DDL function, for all DDLs, that returns the current
> build or GUID/UUID based on the program name and version (akin to strong-names
> for .Net).
> 
> Having a verification mechanism is a good way to avoid versioning problems; the
> application can compensate early (or halt) if the wrong library is found.  IMO,
> something like this would be best suited by some form of compiler support,
> although it /can/ be managed manually.   
> 
> I'll add that its also cross-platform since it doesn't rely on any OS-specific
> metadata features.
> 
> This also opens the door for additional metadata to be served by DDLs in the
> future, if for instance a sister method could describe the kind of library used
> (eg. "i have a GC compiled in", "i'm a class library", or "i'm for C
> compatibility only").
> 
> 
> 3) providing a standard library loader in Phobos that is more flexible than the
> present solutions for windows and unix/linux (std.loader on steroids).
> 

I think that this scheme would work very well, not just for D, but for anything, really. But for D, I think it would be ideally perfect, or perfectly ideal. Even if only the version part ever gets used, it would give a great deal of help to the whole dynamic situation.
I'd really like to see D be set up so it helps with dynamic libraries rather than fights against them.
There are many applications for being able to load libraries as plugins to a program that cannot be implemented as static libraries (not without recompiling the main program each time, and a lot more hassle..)

> 
> - I assume that unix/linux is pretty much solid since it would likely use the
> current search path and leave it at that.  Is this so?  It may be a moot point,
> but unless you can guarantee that /var, /etc, /lib and /sbin (or any other
> critical system directory) are first on the path, then it has the potential for
> behavior different from its non-unix counterparts.

Actually, Linux doesn't use the same search path for binaries that it does for libraries..they are kept separate.

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

On Mon, 24 Jan 2005 23:38:46 +0100, Norbert Nemec wrote:

> Pragma wrote:
> 
>>> "DLL hell".

> I don't even want to understand that whole issue but just add one comment
[...]
>  leave the handling of dll versioning to the installer and don't
> try to solve it in the compiler.
[...]

I agree.

Ant

Paul Bonser wrote:

> Pragma wrote:
>> 3) providing a standard library loader in Phobos that is more flexible
>> than the present solutions for windows and unix/linux (std.loader on
>> steroids).
>> 
> 
> I think that this scheme would work very well, not just for D, but for anything, really.

That's why I say: the problem should not be solved within the compiler. Either Microsoft or some third party should come up with a solution that works for and language. Then DMD could simply use that solution on Windows and do the regular thing in other environments.

Whatever is done, it should definitely not get in the way on Linux.