Id like to submit a proposal (feel free to shoot it down)

Theres millions of lines of code written (mostly in vb and delphi) for COM, and its an open standard still widely in use. With the poor support for COM in .net (they want you to use managed .net components now) alot of that code may lay around unused but still useful. Using an ocx in windows as a plugin for your app is the best current way to go if your not coding in .net...

So anyhow, the point im trying to arrive at is that COM is still a viable technology for years to come but isnt supported well in most low level languages... My proposal is to make the COMObject built in to D, in such a way that the garbage collector doesnt interfere with its reference counting, and that D auto calls AddRef() and Release() any time a reference is instantiated to it. Also id like to propose a new name, instead of ComObject call it Component...

Was an idea i had, but since im inexperienced with how this language works it maybe best to keep it at lib level... but thought i would suggest it...

com objects are supported in D

In article <brmnet$as9$1@digitaldaemon.com>, Lewis says...
>
>Id like to submit a proposal (feel free to shoot it down)
>
>Theres millions of lines of code written (mostly in vb and delphi) for COM, and its an open standard still widely in use. With the poor support for COM in .net (they want you to use managed .net components now) alot of that code may lay around unused but still useful. Using an ocx in windows as a plugin for your app is the best current way to go if your not coding in .net...
>
>So anyhow, the point im trying to arrive at is that COM is still a viable technology for years to come but isnt supported well in most low level languages... My proposal is to make the COMObject built in to D, in such a way that the garbage collector doesnt interfere with its reference counting, and that D auto calls AddRef() and Release() any time a reference is instantiated to it. Also id like to propose a new name, instead of ComObject call it Component...
>
>Was an idea i had, but since im inexperienced with how this language works it maybe best to keep it at lib level... but thought i would suggest it...
>
>

> Id like to submit a proposal (feel free to shoot it down)
>
> Theres millions of lines of code written (mostly in vb and delphi) for
COM, and
> its an open standard still widely in use. With the poor support for COM in
.net
> (they want you to use managed .net components now) alot of that code may
lay
> around unused but still useful. Using an ocx in windows as a plugin for
your app
> is the best current way to go if your not coding in .net...
>
> So anyhow, the point im trying to arrive at is that COM is still a viable technology for years to come but isnt supported well in most low level languages... My proposal is to make the COMObject built in to D, in such a
way
> that the garbage collector doesnt interfere with its reference counting,
and
> that D auto calls AddRef() and Release() any time a reference is
instantiated to
> it. Also id like to propose a new name, instead of ComObject call it
Component...
>
> Was an idea i had, but since im inexperienced with how this language works
it
> maybe best to keep it at lib level... but thought i would suggest it...

D's COM is ripe for some attention, and will likely get it in the new year. If you can be more fulsome in describing your ideas, it'll give us something to think about, and possibly incorporate.

Cheers

Matthew

 > D's COM is ripe for some attention, and will likely get it in the new year.
> If you can be more fulsome in describing your ideas, it'll give us something
> to think about, and possibly incorporate.
> 
> Cheers
> 
> Matthew
> 

Thanks for the encouragement matthew :)

(be forewarned: this may be the longest post i ever make here)

Let me start by first clarifing where i come from, and why i say some of the things i do (albeit probably ignorantly in context to D most of the time)
Ive only ever programmed in visual basic and for windows. In the vb community im known as one of those "optimizer freaks" that is never happy with the fact that code works. It must work extremely well, as fast as is possible using any api or assembly hack we can find or write, and generally as error free as possible even if it requires more lines of code... Between some injected assembly and api useage, i can, in alot of cases create code that runs as fast (an sometimes faster) than a program that does the equilavent in c++. By using assembly injection, I can also call C dll's from visual basic (something microsoft will tell you is impossible) but...
(speaking in general from here >)
With us "vb freaks" its a old war to prove that vb is in fact more than a toy language (and it has been proved in my opinion) and for basic gui windows-only apps, i still believe its the fastest solution in most cases, but theres several things that are missing from the picture...

We often secretly admire the fact that c/c++ programs dont have a runtime they have to drag along, or require the user to download a 1 mb+ runtime file (or worse the .net framework) and also very few of our programs will run on alternate operating systems (wine still has a way to go on that) , and visual basic isnt cheap, (900+ for enterprise version)...

This along with the fact that microsoft has basically abandoned 'pure' vb programmers (i think few will argue that switching to vb.net from vb6 is almost akin to learning a new language) and the millions of lines of COM code we have now lying around... Its time to look elsewhere. Alot will probably go to delphi since its the closest competitor to vb's language and rad IDE (and has great support for COM), but myself i just cant do it, i decided if im going to learn a new language im going to learn one that gives me the power to be flexible, cross platform to an extent, and allow me to not be stuck with one technology... Most of the vb programmers dont want to use delphi or c++, (they've been enemies to long 'tongue in cheek'), so D offers a nice way out ;)

When the last upgrade to the .net runtime was, once again, incompatible with the first .net runtime, I decided (in a moment of disgust that involved deleting .net, and mumbling anti-corporate rantings), that i was going to learn a lower level language and write an interpeter for basic that supports COM instrinsicly similar to visual basic. It would take my basic code with some alterations and convert it to the lower level language automajically. (in other words a BASIC replacement for D's frontend) This allows for several things immediately, 1) a promise for some portability, and 2) no required huge runtime file and 3) easily do things that were hard or impossible to do in vb.

BCX, (and Pavel Minayev's B++) have gone along way towards this goal but both have very little support for COM, something i want to support in mine very well...

My first option of course was to furthur learn more assembly, and i decided to forget that angle its just more than im willing to commit to for now, the second option was C and that fell in the same catagory as assembly... it just requires to much low level hand holding... the only thing left was c++. Then, in my search for the free c++ implementation that would best fit for what i wanted to do, i stumbled across the digital mars c++ website, and lo and behold i discovered the D language! :) I couldnt have found a better candidate (in my opinion) for what i want to do, than if someone had personally coded it for me and thrown it on my lap. After seeing the many incredibly smart people interested in D, and walters dedication to making it work (and proven experience), i think ive found a home... Not only has a second language but as good tool for what i want to do otherwise...

So with all this in mind, please feel free to correct me (or enlighten) anytime i make incorrect assumptions about how things work in D (or C/C++ type languages), I feel i am a fast learner but i always appreciate help, and give any in return if possible. And also keep in mind that im always for anything that will make it "easier" to do something in the language, however i realize that alot of times its an unneccasary syntax that could be easily done from a library or header...

So anyway, back to COM and ease of use... ;)
In vb6 everything under the hood object wise is COM or forced to act like COM.
In vb when i dimension an object variable, it is simply that, a object reference variable to nothing, equalling 0... Then we bind a "com" object to it with two different methods, called late-binding and early-binding, late binding is where the interface to the object is not known until runtime and is done with the CreateObject() function. this is also commonly done from scripts like asp and vbscript... and example Code syntax might be something like:

int getAge() {
// create the late bound object variable
 interface foo;
// assign it to a COM object interface with late binding, through the com object's known progid
 interface foo = CreateObject("ComObject.Interface");
 //you can now (indirectly) call foo's methods
   int bar = 20;
   return foo.CalculateAge(bar);
   //delete the object?
   foo = null;
}

however if you know anything about com you know that you've violated alot of rules in the above code, mainly you didnt call AddRef() or Release() to change the ref count that the object has to do in itself... this is how vb spoils there programmers by doing all that under the hood... Also the line to delete the object is unnessacary because vb calls Release() and deletes the object variable (cleans it up) as soon as it goes out of the scope of the function (or you can do it yourself if you wish)...
Im not sure how D handles things like this yet with scope cleanup and garbage collection...
Theres a few latebinding functions you can use that are basically wrappers for a few api calls.
CreateObject(ProgID),GetObject(Filename),GetObject(filename, ProgID), GetObject(ProgID)

One big problem with late-binding is speed, it is slow because you have to go thru the IDispatch interface with each call to "resolve" function and property names...

With vb we can with a few clicks create a reference to a component and it will build a "type library" automatically and bind to an interface of your choosing within the component, all automatically, creating a compile time (design-time in vb) reference to every public method and property in the interface. Example code from a vb perspective might look like so...

int GetAge() {

 COMObject foo;
 foo = new COMObject;

  //some method of resolving the com object from a guid
  foo = resolveobjectfromid(clsid);

//assume we have an interface defined somewhere already
 interface bar;

//compatible with foo object's SomeInterface)
 bar = new SomeInterface;

 //bind it to foo's SomeInterface
 bar = bind(foo.SomeInterface);

 //now we can directly call bar's methods because we are bound to the vtable of foo's bar interface
 return bar.CalculateAge(20);

 //delete bar and foo
 bar = null;
 foo = null;

}

Some things to note, in vb it would be unnessacary to create the foo Object, because it is alive for the entire lifetime of the project through a reference, so technically foo is an already known reference that you can just:
 bar = bind(foo.SomeInterface);
without creating the foo object. but for clarity here i added it in.

I guess im not suggesting that all these methods are added in the D language intrinsically itself...
But what i am saying is since that all COM objects have several redundant methods that must be called for each item you create, Specifically AddRef() and Release() and all interfaces and objects inherit from IUnknown... it would be nice if the compiler kept track of scope and did ref counting automatically, this would remove the need for some redundant code and take some unnessacary burden off the programmer...

So what basically would then happen in the above code is this:

int GetAge() {

 Component foo; //addref is not called, its only an empty place holder variable
 foo = new Component; //addref is still not called, its only a template for a component

//or alternatively: Component foo = new Component;

  //some method of resolving the com object from a clsid
  foo = foo.resolve(clsid); //addref is called, we have created the object

//assume we have an interface defined somewhere already
 interface bar; //addref is not called, its only a variable

//compatible with foo object's SomeInterface)
 bar = new SomeInterface; //addref is still not called, its only a template for bar

 //bind it to foo's SomeInterface
 bar = foo.bind(foo.SomeInterface); //addref is called, weve created the interface

//or alternatively: bar = bar.bind(foo.SomeInterface); //addref auto called

 //now we can directly call bar's methods because we are bound to the vtable of foo's bar interface
 int Decay = 20;
 return bar.CalculateAge(&Decay);

 //delete bar and foo
 bar = null; //Release() is called to de-increment refcount,and reference variable destoyed
 foo = null; //same

//or alternatively, compiler realizes scope is gone and implicitly calls release(), and destroys both object variables which removes the need to set variables to null

}

In the above scenario the built in COM Object would have subjectivly two methods for early binding , resolve(clsid) and bind(reference to interface), and also perhaps a destroy() method for explicit deletion...

Now that ive shown how much im spoiled by vb :) i would love to hear if any of these ideas are viable or if they should be done outside of D (such as in a library or code)

regards
Lewis

Awesome!

I myself have found that trying to implement a COM wrapper is one of the things that makes me glad C++ has mixins.  Unfortunately C++ mixin support is not that much of a help as it brings along several problems of its own.

Moving this grunt work into the compiler would be one solution, but enhancing the language to the point where something like a COM smart pointer become possible, and easy to put in a library, would be much better.

Sean

"Lewis" <dethbomb@hotmail.com> wrote in message news:broj4i$jtk$1@digitaldaemon.com...
> Let me start by first clarifing where i come from, and why i say some of
the
> things i do (albeit probably ignorantly in context to D most of the time) Ive only ever programmed in visual basic and for windows. In the vb
community im
> known as one of those "optimizer freaks" that is never happy with the fact
that
> code works. It must work extremely well, as fast as is possible using any
api or
> assembly hack we can find or write, and generally as error free as
possible even
> if it requires more lines of code... Between some injected assembly and
api
> useage, i can, in alot of cases create code that runs as fast (an
sometimes
> faster) than a program that does the equilavent in c++. By using assembly injection, I can also call C dll's from visual basic (something microsoft
will
> tell you is impossible) but...
> (speaking in general from here >)
> With us "vb freaks" its a old war to prove that vb is in fact more than a
toy
> language (and it has been proved in my opinion) and for basic gui
windows-only
> apps, i still believe its the fastest solution in most cases, but theres
several
> things that are missing from the picture...
>
> We often secretly admire the fact that c/c++ programs dont have a runtime
they
> have to drag along, or require the user to download a 1 mb+ runtime file
(or
> worse the .net framework) and also very few of our programs will run on
> alternate operating systems (wine still has a way to go on that) , and
visual
> basic isnt cheap, (900+ for enterprise version)...
>
> This along with the fact that microsoft has basically abandoned 'pure' vb programmers (i think few will argue that switching to vb.net from vb6 is
almost
> akin to learning a new language) and the millions of lines of COM code we
have
> now lying around... Its time to look elsewhere. Alot will probably go to
delphi
> since its the closest competitor to vb's language and rad IDE (and has
great
> support for COM), but myself i just cant do it, i decided if im going to
learn a
> new language im going to learn one that gives me the power to be flexible,
cross
> platform to an extent, and allow me to not be stuck with one technology...
Most
> of the vb programmers dont want to use delphi or c++, (they've been
enemies to
> long 'tongue in cheek'), so D offers a nice way out ;)
>
> When the last upgrade to the .net runtime was, once again, incompatible
with the
> first .net runtime, I decided (in a moment of disgust that involved
deleting
> .net, and mumbling anti-corporate rantings), that i was going to learn a
lower
> level language and write an interpeter for basic that supports COM
instrinsicly
> similar to visual basic. It would take my basic code with some alterations
and
> convert it to the lower level language automajically. (in other words a
BASIC
> replacement for D's frontend) This allows for several things immediately,
1) a
> promise for some portability, and 2) no required huge runtime file and 3)
easily
> do things that were hard or impossible to do in vb.
>
> BCX, (and Pavel Minayev's B++) have gone along way towards this goal but
both
> have very little support for COM, something i want to support in mine very
well...
>
> My first option of course was to furthur learn more assembly, and i
decided to
> forget that angle its just more than im willing to commit to for now, the
second
> option was C and that fell in the same catagory as assembly... it just
requires
> to much low level hand holding... the only thing left was c++. Then, in my search for the free c++ implementation that would best fit for what i
wanted to
> do, i stumbled across the digital mars c++ website, and lo and behold i discovered the D language! :) I couldnt have found a better candidate (in
my
> opinion) for what i want to do, than if someone had personally coded it
for me
> and thrown it on my lap. After seeing the many incredibly smart people interested in D, and walters dedication to making it work (and proven experience), i think ive found a home... Not only has a second language
but as
> good tool for what i want to do otherwise...
>
> So with all this in mind, please feel free to correct me (or enlighten)
anytime
> i make incorrect assumptions about how things work in D (or C/C++ type languages), I feel i am a fast learner but i always appreciate help, and
give
> any in return if possible. And also keep in mind that im always for
anything
> that will make it "easier" to do something in the language, however i
realize
> that alot of times its an unneccasary syntax that could be easily done
from a
> library or header...
>
> So anyway, back to COM and ease of use... ;)
> In vb6 everything under the hood object wise is COM or forced to act like
COM.
> In vb when i dimension an object variable, it is simply that, a object
reference
> variable to nothing, equalling 0... Then we bind a "com" object to it with
two
> different methods, called late-binding and early-binding, late binding is
where
> the interface to the object is not known until runtime and is done with
the
> CreateObject() function. this is also commonly done from scripts like asp
and
> vbscript... and example Code syntax might be something like:
>
> int getAge() {
> // create the late bound object variable
>   interface foo;
> // assign it to a COM object interface with late binding, through the com
> object's known progid
>   interface foo = CreateObject("ComObject.Interface");
>   //you can now (indirectly) call foo's methods
>     int bar = 20;
>     return foo.CalculateAge(bar);
>     //delete the object?
>     foo = null;
> }
>
> however if you know anything about com you know that you've violated alot
of
> rules in the above code, mainly you didnt call AddRef() or Release() to
change
> the ref count that the object has to do in itself... this is how vb spoils
there
> programmers by doing all that under the hood... Also the line to delete
the
> object is unnessacary because vb calls Release() and deletes the object
variable
> (cleans it up) as soon as it goes out of the scope of the function (or you
can
> do it yourself if you wish)...
> Im not sure how D handles things like this yet with scope cleanup and
garbage
> collection...
> Theres a few latebinding functions you can use that are basically wrappers
for a
> few api calls.
> CreateObject(ProgID),GetObject(Filename),GetObject(filename, ProgID),
> GetObject(ProgID)
>
> One big problem with late-binding is speed, it is slow because you have to
go
> thru the IDispatch interface with each call to "resolve" function and
property
> names...
>
> With vb we can with a few clicks create a reference to a component and it
will
> build a "type library" automatically and bind to an interface of your
choosing
> within the component, all automatically, creating a compile time
(design-time in
> vb) reference to every public method and property in the interface.
Example code
> from a vb perspective might look like so...
>
> int GetAge() {
>
>   COMObject foo;
>   foo = new COMObject;
>
>    //some method of resolving the com object from a guid
>    foo = resolveobjectfromid(clsid);
>
> //assume we have an interface defined somewhere already
>   interface bar;
>
> //compatible with foo object's SomeInterface)
>   bar = new SomeInterface;
>
>   //bind it to foo's SomeInterface
>   bar = bind(foo.SomeInterface);
>
>   //now we can directly call bar's methods because we are bound to the
vtable of
> foo's bar interface
>   return bar.CalculateAge(20);
>
>   //delete bar and foo
>   bar = null;
>   foo = null;
>
> }
>
> Some things to note, in vb it would be unnessacary to create the foo
Object,
> because it is alive for the entire lifetime of the project through a
reference,
> so technically foo is an already known reference that you can just:
>   bar = bind(foo.SomeInterface);
> without creating the foo object. but for clarity here i added it in.
>
> I guess im not suggesting that all these methods are added in the D
language
> intrinsically itself...
> But what i am saying is since that all COM objects have several redundant
> methods that must be called for each item you create, Specifically
AddRef() and
> Release() and all interfaces and objects inherit from IUnknown... it would
be
> nice if the compiler kept track of scope and did ref counting
automatically,
> this would remove the need for some redundant code and take some
unnessacary
> burden off the programmer...
>
> So what basically would then happen in the above code is this:
>
> int GetAge() {
>
>   Component foo; //addref is not called, its only an empty place holder
variable
>   foo = new Component; //addref is still not called, its only a template
for a
> component
>
> //or alternatively: Component foo = new Component;
>
>    //some method of resolving the com object from a clsid
>    foo = foo.resolve(clsid); //addref is called, we have created the
object
>
> //assume we have an interface defined somewhere already
>   interface bar; //addref is not called, its only a variable
>
> //compatible with foo object's SomeInterface)
>   bar = new SomeInterface; //addref is still not called, its only a
template for bar
>
>   //bind it to foo's SomeInterface
>   bar = foo.bind(foo.SomeInterface); //addref is called, weve created the
interface
>
> //or alternatively: bar = bar.bind(foo.SomeInterface); //addref auto
called
>
>   //now we can directly call bar's methods because we are bound to the
vtable of
> foo's bar interface
>   int Decay = 20;
>   return bar.CalculateAge(&Decay);
>
>   //delete bar and foo
>   bar = null; //Release() is called to de-increment refcount,and reference
> variable destoyed
>   foo = null; //same
>
> //or alternatively, compiler realizes scope is gone and implicitly calls release(), and destroys both object variables which removes the need to
set
> variables to null
>
> }
>
> In the above scenario the built in COM Object would have subjectivly two
methods
> for early binding , resolve(clsid) and bind(reference to interface), and
also
> perhaps a destroy() method for explicit deletion...
>
> Now that ive shown how much im spoiled by vb :) i would love to hear if
any of
> these ideas are viable or if they should be done outside of D (such as in
a
> library or code)
>
> regards
> Lewis

Comments embedded.

"Lewis" <dethbomb@hotmail.com> wrote in message
news:broj4i$jtk$1@digitaldaemon.com...
| ...
| We often secretly admire the fact that c/c++ programs dont have a runtime
they
| have to drag along, or require the user to download a 1 mb+ runtime file
(or
| worse the .net framework) and also very few of our programs will run on
| alternate operating systems (wine still has a way to go on that) , and
visual
| basic isnt cheap, (900+ for enterprise version)...

Those are the reasons I stepped away from vb and why I haven't entered too much into the .net world.

|
| This along with the fact that microsoft has basically abandoned 'pure' vb
| programmers (i think few will argue that switching to vb.net from vb6 is
almost
| akin to learning a new language) and the millions of lines of COM code we
have
| now lying around... Its time to look elsewhere. Alot will probably go to
delphi
| since its the closest competitor to vb's language and rad IDE (and has
great
| support for COM), but myself i just cant do it, i decided if im going to
learn a
| new language im going to learn one that gives me the power to be flexible,
cross
| platform to an extent, and allow me to not be stuck with one technology...
Most
| of the vb programmers dont want to use delphi or c++, (they've been
enemies to
| long 'tongue in cheek'), so D offers a nice way out ;)

I'm not a big fan of the Pascal/Delphi language, but I most admit that the Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm writing (in Delphi 6 PE) a dll with declarations for all the GUI objects available in Delphi, and a library (in D) calling those objects, providing a wrapper to access them just like you would in Delphi. So far, so good. Why I'm doing this? Because I think the way Delphi does GUI building is the best I've seen (not that I've seen much either ;) ). If any of you is interested, let me know and I'll keep you informed.

| ...
| BCX, (and Pavel Minayev's B++) have gone along way towards this goal but
both
| have very little support for COM, something i want to support in mine very
well...

Last time I checked, B++ hadn't been updated for a long, long while.

|
| My first option of course was to furthur learn more assembly, and i
decided to
| forget that angle its just more than im willing to commit to for now, the
second
| option was C and that fell in the same catagory as assembly... it just
requires
| to much low level hand holding... the only thing left was c++. Then, in my
| search for the free c++ implementation that would best fit for what i
wanted to
| do, i stumbled across the digital mars c++ website, and lo and behold i
| discovered the D language! :) I couldnt have found a better candidate (in
my
| opinion) for what i want to do, than if someone had personally coded it
for me
| and thrown it on my lap. After seeing the many incredibly smart people
| interested in D, and walters dedication to making it work (and proven
| experience), i think ive found a home... Not only has a second language
but as
| good tool for what i want to do otherwise...
|
| So with all this in mind, please feel free to correct me (or enlighten)
anytime
| i make incorrect assumptions about how things work in D (or C/C++ type
| languages), I feel i am a fast learner but i always appreciate help, and
give
| any in return if possible. And also keep in mind that im always for
anything
| that will make it "easier" to do something in the language, however i
realize
| that alot of times its an unneccasary syntax that could be easily done
from a
| library or header...
|
| So anyway, back to COM and ease of use... ;)
| In vb6 everything under the hood object wise is COM or forced to act like
COM.
| In vb when i dimension an object variable, it is simply that, a object
reference
| variable to nothing, equalling 0... Then we bind a "com" object to it with
two
| different methods, called late-binding and early-binding, late binding is
where
| the interface to the object is not known until runtime and is done with
the
| CreateObject() function. this is also commonly done from scripts like asp
and
| vbscript... and example Code syntax might be something like:
|
| int getAge() {
| // create the late bound object variable
|   interface foo;
| // assign it to a COM object interface with late binding, through the com
| object's known progid
|   interface foo = CreateObject("ComObject.Interface");
|   //you can now (indirectly) call foo's methods
|     int bar = 20;
|     return foo.CalculateAge(bar);
|     //delete the object?
|     foo = null;
| }

That last line won't run because return terminates the function. Also, you don't need to free the object: the gc will do it for you.

| ...
| regards
| Lewis


-----------------------
Carlos Santander Bernal


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 2003-12-15

Carlos Santander B. wrote:
<snip>
> I'm not a big fan of the Pascal/Delphi language, but I most admit that the
> Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm writing
> (in Delphi 6 PE) a dll with declarations for all the GUI objects available
> in Delphi, and a library (in D) calling those objects, providing a wrapper
> to access them just like you would in Delphi. So far, so good. Why I'm doing
> this? Because I think the way Delphi does GUI building is the best I've seen
> (not that I've seen much either ;) ). If any of you is interested, let me
> know and I'll keep you informed.
<snip>

Hi All,
Yes please.
I use BCB 5 and am spoiled by the RAD and GUI capabilities.
The Lack of GUI capabilities and having to figure out how "make" files
work have been holding me back from D.

I have been following the newsgroup for some time and think the language is going to be great.

regards

Walter.
ps Hopefully I have changed the sender name to RickWal to avoid confusion with the real Walter.

Hi.

I don't think VB users who hate both C++ and Delphi can be attracted to D. It's just that D is much more similar to either of them than to Visual Basic.

Carlos Santander B. wrote:
> Last time I checked, B++ hadn't been updated for a long, long while.

I have been talking to Pavel. He plans on a new language, since he found severe faults in B++ design. IIRC its memory management was somewhat weak. The new language will be somethig like a compiled Python. I'm waiting for him to put up a design paper on it. Pavel himself has made himself comfortable with C++ (which you start to like as you get to understand it) and with C#. This makes it even less probable for him to really work on a new language. BCX is not even good for small projects, bacause its module system is not existent, and debugging is almost impossible.

-eye

Have you tried DIDE?

There's a bunch of other tools besides make out there that you might like better.  Make is not really evolving anymore and seems to be for old Unix curmudgeons. I use Visual Studio (small projects... it would suck for large D projects) and I know there are some other good make tools (listed links below)

Ant     http://ant.apache.org/

SCons  http://www.scons.org/

Jam    http://www.perforce.com/jam/jam.html

The nice thing about tools like that is you can use them for lots of things besides just compiling programs.

Sean

"Walter" <rickwal@iinet.net.au> wrote in message news:brrveq$2m0v$1@digitaldaemon.com...
> The Lack of GUI capabilities and having to figure out how "make" files
> work have been holding me back from D.
> Walter.
> ps Hopefully I have changed the sender name to RickWal to avoid
> confusion with the real Walter.

No, it didn't work.

"Walter" <rickwal@iinet.net.au> wrote in message
news:brrveq$2m0v$1@digitaldaemon.com...
| Carlos Santander B. wrote:
| > (not that I've seen much either ;) ). If any of you is interested, let
me
| > know and I'll keep you informed.
|
| Hi All,
| Yes please.
| ...

Ok, then. Check http://earth.prohosting.com/carlos3, go to the delphi4d section.

-----------------------
Carlos Santander Bernal