"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:css767$1c4c$1@digitaldaemon.com...
> The GC issue aside, a "phobos.dll on an island" does make sense. Suppose
you
> are using a D programm without direct access to the D sources or timely customer support. If a new version of the Phobos.dll is available that
features
> bug fixes, you could instantly drop in the new Phobos.dll.

True, but now you (the application customer) are using a combination of binaries that the vendor never tested. As an application vendor myself, I just don't want to deal with those kind of "my app stopped working" issues.

Back in the distant memory, when dinosaurs ruled the earth and the atmospheric oxygen content was 36%, I didn't have a linker to go with the compiler. Microsoft conveniently shipped a linker with every version of MS-DOS. The trouble started happening when Microsoft started shipping multiple linkers, all with various different bugs. Some would work, some would not. I started accumulating a "linker collection", dozens of them, some that would work, some wouldn't, some worked under some circumstances but not others, etc. It was a looming customer support disaster, that was only solved when Bjorn Freeman-Benson came to my rescue and wrote a linker (Blink.exe) for me.

Now, customers got a linker with predictable behavior, and I could even fix bugs in it. The problems went away.

Having a phobos.dll doesn't cause those sorts of problems for myself, just like the various versions of MS-LINK did not cause any problems for Microsoft. But it *will* cause customer support problems for any application vendor that ships a phobos.dll along with their application.

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8vr$1e0b$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
news:css3k9$18ou$1@digitaldaemon.com...
> > The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose
should
> > be C style functions, COM interfaces, or D interfaces. The first two
choices
> > have the nice feature that just about any decent language will have some level of access to that DLL.
> >
> > In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one
D
> > app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's
phobos.dll on
> > an island with A's app, why not just statically link it in? (It's not
like
> > there's a shortage of disk space!)
>
> It's certainly true that that's unpleasant, but if the alternative is that
one cannot talk "D" across link-units, then
> D's going to be pretty still born.

You can - I just argue that that would be a poor design of a DLL.

> I believe we can concoct a better solution. Just not sure what ... yet.

Why not use D interfaces?

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
> One issue on which I'm not clear, and for which I'd appreciate input from
you more expert than I to inform on my
> musings: If a statically-linked D exe loaded, via a C-API /
interface-based API, a statically linked (to GC, that is)
> DLL, got some memory from it, and then unloaded it, what would happen? I
presume that it crashes.

What if you had two DLLs written in C, both statically linked to their own malloc/free's. Malloc a pointer in one DLL, pass it to the other, and free it. You'll crash.

In article <css3k9$18ou$1@digitaldaemon.com>, Walter says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:csrksh$mn3$1@digitaldaemon.com...
>> In article <csqmfc$2gm9$2@digitaldaemon.com>, Matthew says... <snip>
>> >So, Hi! Hope you're all hale and hearty. And fill me in on all the good
>stuff.
>>
>> Hey Matthew; you'll be "not is" surprised to learn that the beloved issues surrounding DLLs and the GC are all still present (Sean's excellent work
>aside)
>> .. stepping away from a statically-linked model still transports one back
>into
>> the stone-age.
>>
>> Question: would D benefit from it's own (binary) link-loader? If the
>compiler
>> were to spit out DDLs (Dynamic D Libraries), and the runtime had the
>equivalent
>> of a linking-class-loader, then the issues regarding multiple GC's would
>go away
>> (since the GC, and all libraries, would be DDLs instead).
>>
>> Such an approach would also presumeably expose D classes correctly, which
>is
>> currently the other major problem regarding D and shared-libraries.
>>
>> Thoughts?
>
>The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose should be C style functions, COM interfaces, or D interfaces. The first two choices have the nice feature that just about any decent language will have some level of access to that DLL.
>
>In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one D app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on an island with A's app, why not just statically link it in? (It's not like there's a shortage of disk space!)
>
>


Please read that last sentence again, Walter ... what we're trying to do is build systems that /cannot/ be statically linked. That's the whole point.

When you attempt to build any kind of dynamic system in D, all hell breaks loose regarding MM, small mobile-behaviours become enormously bloated (saturating bandwidth), and development becomes systematically more complex than it would be if these issues were resolved.

Would you prefer everybody to statically link their code with, say, a Relational Database? If said DB was written in D, who would be responsible for managing memory?

There are some very serious issues regarding what happens when memory is allocated within one GC and then manipulated within another. And there are many, many ways for that to happen. Do you think we should all manage that ourselves? The current situation allows for one GC to reap memory that's currently in use elsewhere; I hope you can agree such behaviour is "non-productive"? While you may prefer to keep the allocation seperated between DLLs, you don't offer a reasonable solution for the programmer.

Your argument has to do with library versioning, right? Perhaps you might do something creative with a DLL loader? Whatever ...

The upshot of this, as you know, is that D is seriously crippled from a dynamic perspective. Yes, one can link a C-based dynamic library. Yet one cannot link to a D library without jumping through a number of hoops. oh; and thoroughly understanding all the many devilish issues regarding memory allocation across multiple GC instances. Oh! And then inventing a whole bunch of code to manage those multiple GC instances.

If that sounds absurd, well, that's because it is.

We should also recognize that the Corporate Environment will (rightfully) consider D as a toy, without such facilities exposed in a natural, robust, comprehensive, and comprehendable manner.

Personally, I just don't get it, Walter. This is an issue that has always been around, yet all suggestions made thus far (from several people) have either been thoroughly ignored or simply "pooh poohed" by you. How about something a little more constructive instead? How about opening up a productive discussion amongst the members here?

As for DLLs themselves -- I don't give a toss how things are implemented, so long as:

(a) one can dynamically load, and naturally access, classes exposed via a D
shared-library

(b) there are no bizarre, sneaky, or obscure gotcha's regarding memory
allocations between a shared-lib and an application (or other shared-lib)

IMHO;

- Kris


P.S. Does this feel more like the NG you've been missing, Matthew?

:-)

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
> In one sense I'm pleased that the DLL issue's not progressed, since it
means that I have a chance to help with/opine on
> it. On the other hand, it's quite concerning, since it's a show-stopper
IMO, at least as far as getting D past the "very
> useful for writing system apps and small GUIs, but cannot be used for
component-based architectures" stage.

But it *can* be used for component based architectures! That's exactly what the COM support does. That's exactly what the interfaces do. There are even sample COM server DLL's in \dmd\samples\d\

"Kris" <Kris_member@pathlink.com> wrote in message news:cssd33$1igm$1@digitaldaemon.com...
> In article <css3k9$18ou$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Kris" <Kris_member@pathlink.com> wrote in message news:csrksh$mn3$1@digitaldaemon.com...
>>> In article <csqmfc$2gm9$2@digitaldaemon.com>, Matthew says... <snip>
>>> >So, Hi! Hope you're all hale and hearty. And fill me in on all the good
>>stuff.
>>>
>>> Hey Matthew; you'll be "not is" surprised to learn that the beloved issues surrounding DLLs and the GC are all still present (Sean's excellent work
>>aside)
>>> .. stepping away from a statically-linked model still transports one back
>>into
>>> the stone-age.
>>>
>>> Question: would D benefit from it's own (binary) link-loader? If the
>>compiler
>>> were to spit out DDLs (Dynamic D Libraries), and the runtime had the
>>equivalent
>>> of a linking-class-loader, then the issues regarding multiple GC's would
>>go away
>>> (since the GC, and all libraries, would be DDLs instead).
>>>
>>> Such an approach would also presumeably expose D classes correctly, which
>>is
>>> currently the other major problem regarding D and shared-libraries.
>>>
>>> Thoughts?
>>
>>The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose should be C style functions, COM interfaces, or D interfaces. The first two choices have the nice feature that just about any decent language will have some level of access to that DLL.
>>
>>In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one D app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's phobos.dll on an island with A's app, why not just statically link it in? (It's not like there's a shortage of disk space!)
>>
>>
>
>
> Please read that last sentence again, Walter ... what we're trying to do is build systems that /cannot/ be statically linked. That's the whole point.
>
> When you attempt to build any kind of dynamic system in D, all hell breaks loose regarding MM, small mobile-behaviours become enormously bloated (saturating bandwidth), and development becomes systematically more complex than it would be if these issues were resolved.
>
> Would you prefer everybody to statically link their code with, say, a Relational Database? If said DB was written in D, who would be responsible for managing memory?
>
> There are some very serious issues regarding what happens when memory is allocated within one GC and then manipulated within another. And there are many, many ways for that to happen. Do you think we should all manage that ourselves? The current situation allows for one GC to reap memory that's currently in use elsewhere; I hope you can agree such behaviour is "non-productive"? While you may prefer to keep the allocation seperated between DLLs, you don't offer a reasonable solution for the programmer.
>
> Your argument has to do with library versioning, right? Perhaps you might do something creative with a DLL loader? Whatever ...
>
> The upshot of this, as you know, is that D is seriously crippled from a dynamic perspective. Yes, one can link a C-based dynamic library. Yet one cannot link to a D library without jumping through a number of hoops. oh; and thoroughly understanding all the many devilish issues regarding memory allocation across multiple GC instances. Oh! And then inventing a whole bunch of code to manage those multiple GC instances.
>
> If that sounds absurd, well, that's because it is.
>
> We should also recognize that the Corporate Environment will (rightfully) consider D as a toy, without such facilities exposed in a natural, robust, comprehensive, and comprehendable manner.
>
> Personally, I just don't get it, Walter. This is an issue that has always been around, yet all suggestions made thus far (from several people) have either been thoroughly ignored or simply "pooh poohed" by you. How about something a little more constructive instead? How about opening up a productive discussion amongst the members here?
>
> As for DLLs themselves -- I don't give a toss how things are implemented, so long as:
>
> (a) one can dynamically load, and naturally access, classes exposed via a D
> shared-library
>
> (b) there are no bizarre, sneaky, or obscure gotcha's regarding memory
> allocations between a shared-lib and an application (or other shared-lib)
>
> IMHO;
>
> - Kris
>
>
> P.S. Does this feel more like the NG you've been missing, Matthew?
>
> :-)

Sounding more and more normal. ;)

But I agree with your implication of the importance of this issue to D. As I've said three times in the last 24hrs, without an effective and elegant (i.e. totally ignorable to 98% of users) solution, D will be stillborn. Of that I have no doubt. Hence, I agree with Kris that Walter needs to consider this to be a serious issue, and a mandatory pre-1.0 accomplishment.

"Walter" <newshound@digitalmars.com> wrote in message news:cssd2a$1ig3$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8vr$1e0b$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
> news:css3k9$18ou$1@digitaldaemon.com...
>> > The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose
> should
>> > be C style functions, COM interfaces, or D interfaces. The first two
> choices
>> > have the nice feature that just about any decent language will have some level of access to that DLL.
>> >
>> > In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one
> D
>> > app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's
> phobos.dll on
>> > an island with A's app, why not just statically link it in? (It's not
> like
>> > there's a shortage of disk space!)
>>
>> It's certainly true that that's unpleasant, but if the alternative is that
> one cannot talk "D" across link-units, then
>> D's going to be pretty still born.
>
> You can - I just argue that that would be a poor design of a DLL.
>
>> I believe we can concoct a better solution. Just not sure what ... yet.
>
> Why not use D interfaces?

But how do we manage the memory that may be exchanged between link units? Which GC owns it? I confess I little understand this, but it seems pretty clear that if GCs are link unit-specific, then there're going to be problems.

"Walter" <newshound@digitalmars.com> wrote in message news:cssd2a$1ig3$2@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
>> One issue on which I'm not clear, and for which I'd appreciate input from
> you more expert than I to inform on my
>> musings: If a statically-linked D exe loaded, via a C-API /
> interface-based API, a statically linked (to GC, that is)
>> DLL, got some memory from it, and then unloaded it, what would happen? I
> presume that it crashes.
>
> What if you had two DLLs written in C, both statically linked to their own malloc/free's. Malloc a pointer in one DLL, pass it to the other, and free it. You'll crash.

I'm not talking about malloc(). That's a well-trodden path.

AFAICS, the problem is when D code in different link units exchange 'D' memory. What happens then?

"Walter" <newshound@digitalmars.com> wrote in message news:cssdl8$1j47$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8m0$1dn7$1@digitaldaemon.com...
>> In one sense I'm pleased that the DLL issue's not progressed, since it
> means that I have a chance to help with/opine on
>> it. On the other hand, it's quite concerning, since it's a show-stopper
> IMO, at least as far as getting D past the "very
>> useful for writing system apps and small GUIs, but cannot be used for
> component-based architectures" stage.
>
> But it *can* be used for component based architectures! That's exactly what the COM support does. That's exactly what the interfaces do. There are even sample COM server DLL's in \dmd\samples\d\

Ok, so I misspoke. I should have said

    [D will be] "very useful for writing system apps and small GUIs, but cannot be used for component-based
architectures [that exchange information via D code]"

In article <cssd2a$1ig3$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:css8vr$1e0b$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
>news:css3k9$18ou$1@digitaldaemon.com...
>> > The idea of using a single gc across multiple DLLs just doesn't sit well with me. I prefer to make DLLs that are, as far as allocation goes, independent of each other. To that end, the API a D DLL should expose
>should
>> > be C style functions, COM interfaces, or D interfaces. The first two
>choices
>> > have the nice feature that just about any decent language will have some level of access to that DLL.
>> >
>> > In particular I am not fond of the idea of making Phobos into a DLL. The problem, as we all eventually run into, is DLL hell. Suppose you buy one
>D
>> > app from vendor A, and another from vendor B. They each ship a different phobos.dll. Which one do you use? Ak. Now, if you say keep A's
>phobos.dll on
>> > an island with A's app, why not just statically link it in? (It's not
>like
>> > there's a shortage of disk space!)
>>
>> It's certainly true that that's unpleasant, but if the alternative is that
>one cannot talk "D" across link-units, then
>> D's going to be pretty still born.
>
>You can - I just argue that that would be a poor design of a DLL.
>
>> I believe we can concoct a better solution. Just not sure what ... yet.
>
>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
4) the other GC (from the caller) may try to reap the interface handle, which
does not belong within its pools

There are many more, non-trivial, examples.

Since we're talking about the factory pattern, one might consider adding a version number as an argument? So the client could specify some kind of expected version? Perhaps not ideal, but it might address some of your concerns?

- Kris