"Carlos Santander" <csantander619@gmail.com> wrote in message news:d7a2qb$tc7$1@digitaldaemon.com...
> Carlos Santander escribió:
> > TechnoZeus escribió:
> >
> >>
> >> No, that's actually not correct, although the way the API
> >> documentation is written I can
> >> understand how it may lead people to such a conclusion.
> >>
> >> Over the years, many languages have been involved in the writing of
> >> Windows,
> >> and I'm not sure what it's primarily written in now, but I would guess
> >> C# is probably being
> >> used for most of the new stuff.  (Anyone from Microsoft care to jump
> >> in here?)
> >>
> >
> > C# compiles to MSIL. Windows runs Win32 applications. MSIL applications are not Win32 applications. So C# is as native as Java, for example. I'm sorry, but I disagree with you here.
> >
>
> Small correction: Java doesn't use native controls but MSIL does. Still, they both run on a virtual machine, and that makes them not native.
>
> >> The question here is mainly one of whether D is to be considered a
> >> fully functional programming language in it's own right,
> >> or merely a tool to augment programming in the C language.
> >> Of course, the answer may be a matter of opinion, and largely subject to
> >> the observer's platform of choice. I personally would like to see it
> >> succede
> >> as a full featured programming language on all targeted platforms,
> >> and then some.
> >>
> >> TZ
> >>
> >>
> >
> >
>
>
> -- 
> Carlos Santander Bernal

Perhaps this has changed since I last looked at it,
but durring the early C# betas, as I understood it,
the plan was to make MSIL the primary compilation target platform
for the C# language (and other .net languages), but not the "only" one.

One way or the other though, support for windows is native to C#, regardless of
whether that support is filtered through a virtual machine,
emulated, run on an MSIL compatible microprocessor,
interpreted, or whatever.

The C# "language" supports Windows program development.
I would like to see the D language do so also... or at least natively support
development of GUI based applications, even if only in a generic sense.
In fact, I would actually preffer it to be somewhat generic, because
it is easier that way to write cross-platform GUI based applications and
then compile them for each target platform.

TZ

"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d7ab8i$1379$1@digitaldaemon.com...
>
> >>The question here is mainly one of whether D is to be considered a
> >>fully functional programming language in it's own right,
> >>or merely a tool to augment programming in the C language.
> >>Of course, the answer may be a matter of opinion, and largely subject to
> >>the observer's platform of choice. I personally would like to see it succede
> >>as a full featured programming language on all targeted platforms,
> >>and then some.
> >
>
> I guess some people won't think a language is legit until microsoft steals it. :)
>
> I am very impressed with how much everyone has to say about GUIs here. I think it surprised me that so many of you guys actually are interested so much in GUI development. I think we should start working together to come up with a really solid idea for the standard D GUI toolkit and than use our combined knowledge and resources to make it a reality.
>
> D could use it, and we could all use it.
>
> My initial proposal for this new stanrdard GUI toolkit...
>
> Basic Controls that end up working out to be the OS's native widgets, not look alikes. So on mac the scrollbar class will actually abstract a mac scrollbar, and one windows it will abstract a windows one, not just use a differnt drawing routine.
>
> Strong OpenGL support. This ends up being very useful for people who are making their own GUI's or multimedia apps, but still want direct, and cross platfor, access to a file open or a menu system.
>
> Polled events. I for one am not a fan of callbacks being used for every little thing on earth. I am rewriting Cpw in D right now, and thats the first thing I am changing. I would love to hear peoples opinions about this...
>
> I have many more ideas, but thats a start. Ideas?
>
> Thanks,
> Trevor Parscal
> www.trevorparscal.com
> trevorparscal@hotmail.com

Thank you so much...
not for the uncalled for and inaccurate insult,
but for your wonderful explanation of what I have been "trying to say" here.

That is exactly what I'm talking about... except to hopefully become an integral part of the D language, rather than an optional add-on.

Sure, you can "compute" without GUI controls, but that's obviously not the
full extent of what programs are expected (by most people) to do these days.
I would just like to see the Dlanguage specification have built in support for
the "concept" of GUI based appications, with the idea being that a D compiler for
a specific platform would be able to compile a simple working GUI based application
in a single step, without the need for anything other than...
the operating system and computer to run the compiler on,
a D source file written by the application developer,
and the files that came in the compiler's installation package.

TZ

TechnoZeus wrote:

> One way or the other though, support for windows is native to C#,
> regardless of whether that support is filtered through a virtual machine,
> emulated, run on an MSIL compatible microprocessor,
> interpreted, or whatever.

No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.

> 
> The C# "language" supports Windows program development.

Yes, through it's libraries.

> I would like to see the D language do so also... or at least natively support development of GUI based applications, even if only in a generic sense. In fact, I would actually preffer it to be somewhat generic, because it is easier that way to write cross-platform GUI based applications and then compile them for each target platform.

All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos.

Lars Ivar Igesund

"John C" <johnch_atms@hotmail.com> wrote in message news:d7ckge$2m20$1@digitaldaemon.com...
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d79cpe$dil$1@digitaldaemon.com...
> > "Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d77ute$24uf$1@digitaldaemon.com...
> >>
> >> >As it stands now, I know of no way to write even the simplest Windows
> >> >program without
> >> >having to fall back on the use of some other "language" to do it.
> >> >That's not to say that it cant't be done...
> >> >just that I don't know of a way.
> >> >
> >>
> >> Windows was written in C, so anything you do with native windows is going
> >> to
> >> have to interface with C code. Correct me if I am wrong...
> >>
> >> >I have been trying for some time now to write a simple file utinity for
> >> >GenePool4 entirely in the D language,
> >> >but I can't even figure out how to do something simple like open a file
> >> >dialog to get a filename.
> >> >
> >>
> >> Native controls like that require the use of the native C headers, like windows.h and winuser.h. Luckily we have people who made windows bindings in D.
> >>
> >> Check out Core32 on dsource.org
> >>
> >> Thanks,
> >> Trevor Parscal
> >> www.trevorparscal.com
> >> trevorparscal@hotmail.com
> >
> > No, that's actually not correct, although the way the API documentation is
> > written I can
> > understand how it may lead people to such a conclusion.
> >
> > Over the years, many languages have been involved in the writing of
> > Windows,
> > and I'm not sure what it's primarily written in now, but I would guess C#
> > is probably being
> > used for most of the new stuff.  (Anyone from Microsoft care to jump in
> > here?)
>
> Surely it doesn't matter what language Windows is written in, only what language the public API is. And that's C. Even those parts of Windows not written in C (COM/ActiveX, GDI+) have a C API.
>
> Microsoft's Raymond Chen blogs frequently about the internals of Windows http://blogs.msdn.com/oldnewthing/
>
> C# is only relevant when programming for the Common Language Runtime (CLR). None of the Win32 API accesses CLR bits. Microsoft's forthcoming Avalon and Indigo are only relevant in a CLR environment. Perhaps this is what you meant by "the new stuff". The next version of Windows, for example, will not be primarily written in C# (or any other CLR-targeting language).
>
> >
> > The question here is mainly one of whether D is to be considered a
> > fully functional programming language in it's own right,
> > or merely a tool to augment programming in the C language.
>
> Any language that needs to access operating system functionality has to interface with a public API. For Windows, that's generally C, as I've said above. It makes no difference if that language is C++, D, Delphi, Visual Basic or Eiffel. You're going to need to call down to C.
>
> > Of course, the answer may be a matter of opinion, and largely subject to
> > the observer's platform of choice. I personally would like to see it
> > succede
> > as a full featured programming language on all targeted platforms,
> > and then some.
> >
> > TZ
> >
> >
>
>

True, a compiled Windows application needs to communicate with the Windows API,
but that does not mean the application's source code needs to be written any differently
for Windows than for any other GUI to get basic GUI functionality, and it definately doesn't mean
that the application developer should have to specify in the source code or in any compiler command
that any C files or header files or library files or DLLs have to be used to make the application work.

That's what I mean by "native support" is to be able to simply write for the targer platform and compile...
and get a working application.  Not an assortment of error messages due to a
failure to import or link-in some foreign item.

TZ

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7ej4s$1h0m$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> > One way or the other though, support for windows is native to C#,
> > regardless of whether that support is filtered through a virtual machine,
> > emulated, run on an MSIL compatible microprocessor,
> > interpreted, or whatever.
>
> No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
>
> >
> > The C# "language" supports Windows program development.
>
> Yes, through it's libraries.
>
> > I would like to see the D language do so also... or at least natively support development of GUI based applications, even if only in a generic sense. In fact, I would actually preffer it to be somewhat generic, because it is easier that way to write cross-platform GUI based applications and then compile them for each target platform.
>
> All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos.
>
> Lars Ivar Igesund

Even in early beta versions of C#, I was able to write and
compile Windows programs without "me" having to specify ANY
libraries.  Yes, I know the compiler had to call them... but I didn't.

The same goes for Visual Basic, for that matter, and if I'm not mistaken, also for Delphi.
I'm sure more could be added to that list, but my point is...  I would like D to be in the list.

TZ

"Carlos Santander" <csantander619@gmail.com> wrote in message news:d79t3v$pbv$4@digitaldaemon.com...
> TechnoZeus escribió:
> >
> > Sorry, I should have stated my question more clearly.
> > I had meant support that was native to the D language.
> > Whether or not that support ties into Windows in a way that is
> > native to Windows isn't something that I'm concerned about at
> > this time, as long as it's functional and allows programming in
> > native D source code without the need to link to libraries or DLLs
> > which were written in some other language and which are not
> > a part of the operating system.
> >
> > Years back, I suggested to Microsoft that they make certain parts of
> > such programs as Internet Explorer and Word a part of the operating system,
> > both to allow those programs to have a smaller footprint within the system, and
> > to allow many of their features and much of their functionality to be easily integrated
> > into other applications.  They listened... and as a result, much of that functionality is now
> > a part of Windows and can be accessed through API calls without having to first separately
> > install one of those programs.  I don't care where that functionality came from, or for that matter
> > how it's integrated into the system, so much as that it's there and I would like to see D support it natively...
> > to at least a reasonable extent.
> >
> > For example, if a person writes a line of D code to display a piece of text, it should do so...
> > and if a person writes a line of D code to allow a choice to be made by the user from a list of possibilities, that should work also.
> > Eliminating the console window in a Windows application should not disable such functionality... At worst, it should simply divert it.
> > At best, it should be possible to treat text based environments as if they have GUI support, and let the GUI elements be emulated in text
> > much the same as the Microsoft Narrator in Windows XP (or other similar OS level text-to-speech programs) emulates them in speech.
> > Then a window, menu, or common dialog box wouldn't have to be treated as if it's a foreign element that needs a translator from another language.
> >
> > TZ
> >
> >
>
> That's the point: Windows has those things in its core: kernel32.dll, user32.dll, gdi32.dll, etc. So we use them. For that, we need two things: an import library (created with implib) which has no code, only stubs, and a header (a complete set of headers is the core32 library in dsource, another is Y. Tomino's. The link can be found in the wiki). The headers are needed so the compiler won't complain, and the library are there so the linker won't complain.
>
> If you want to use Narrator or any other thing, just find the corresponding dll, create an import library, create the headers, and use it. It's the way things are done.
>
> -- 
> Carlos Santander Bernal

You not only missed my point completely, but
also stated a point of view as if it were a fact.

No, just because things are done a certain way in C does not mean that there is no other way.

I'm sure I've mentioned it here before... I don't even like C.  It's something that I put up with when I have no choice.

TZ

"J C Calvarese" <technocrat7@gmail.com> wrote in message news:d7a4o1$uuc$1@digitaldaemon.com...
> In article <d79lf7$jvk$1@digitaldaemon.com>, TechnoZeus says...
> >
> ..
>
> >Years back, I suggested to Microsoft that they make certain parts of
> >such programs as Internet Explorer and Word a part of the operating system,
> >both to allow those programs to have a smaller footprint within the system, and
> >to allow many of their features and much of their functionality to be easily integrated
> >into other applications.  They listened... and as a result, much of that functionality is now
> >a part of Windows and can be accessed through API calls without having to first separately
> >install one of those programs.  I don't care where that functionality came from, or for that matter
> >how it's integrated into the system, so much as that it's there and I would like to see D support it natively...
> >to at least a reasonable extent.
>
> I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input.
>
> As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions.
>
> If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries
>
> I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.)
>
> jcc7

Actually, when I recommended it, I also specifically stated that all such components
should be documented so that anyone could use them.  I unfortunately, am not (nor was I at that time)
a Microsoft employee... so making suggestions was the best I could do.
Much like I am now making suggestions for the D language,
but am powerless to have any more direct effect
on how the D language turns out.

I'm not suggesting that we do away with all the libraries.

What I am suggesting is that basic GUI functionality should be supported by the language itself so that the application developer has no need to specify any library to do simple things like create a window and put some simple working controls on it, or open a common dialog box.

TZ

TechnoZeus wrote:

> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7ej4s$1h0m$1@digitaldaemon.com...
>> TechnoZeus wrote:
>>
>> > One way or the other though, support for windows is native to C#, regardless of whether that support is filtered through a virtual machine, emulated, run on an MSIL compatible microprocessor, interpreted, or whatever.
>>
>> No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
>>
>> >
>> > The C# "language" supports Windows program development.
>>
>> Yes, through it's libraries.
>>
>> > I would like to see the D language do so also... or at least natively support development of GUI based applications, even if only in a generic sense. In fact, I would actually preffer it to be somewhat generic, because it is easier that way to write cross-platform GUI based applications and then compile them for each target platform.
>>
>> All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos.
>>
>> Lars Ivar Igesund
> 
> Even in early beta versions of C#, I was able to write and
> compile Windows programs without "me" having to specify ANY
> libraries.  Yes, I know the compiler had to call them... but I didn't.

Yes, the compiler does the work for you. This has absolutely nothing with the language itself. To have such functionality in the compiler and crossplatform is quite a lot of work, and is the reason for all the extra utils out there (build, etc).

I have used stuff in C# where I had to specify extra libraries to link in (it was simple, but it had to be done), so in the case of .Net, it is more of a case of having a very large standard library compared to the rather small phobos.

Lars Ivar Igesund

TechnoZeus wrote:

> "J C Calvarese" <technocrat7@gmail.com> wrote in message news:d7a4o1$uuc$1@digitaldaemon.com...
>> In article <d79lf7$jvk$1@digitaldaemon.com>, TechnoZeus says...
>> >
>> ..
>>
>> >Years back, I suggested to Microsoft that they make certain parts of
>> >such programs as Internet Explorer and Word a part of the operating
>> >system, both to allow those programs to have a smaller footprint within
>> >the system, and to allow many of their features and much of their
>> >functionality to be easily integrated
>> >into other applications.  They listened... and as a result, much of that
>> >functionality is now a part of Windows and can be accessed through API
>> >calls without having to first separately
>> >install one of those programs.  I don't care where that functionality
>> >came from, or for that matter how it's integrated into the system, so
>> >much as that it's there and I would like to see D support it natively...
>> >to at least a reasonable extent.
>>
>> I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input.
>>
>> As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions.
>>
>> If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries
>>
>> I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.)
>>
>> jcc7
> 
> Actually, when I recommended it, I also specifically stated that all such
> components
> should be documented so that anyone could use them.  I unfortunately, am
> not (nor was I at that time) a Microsoft employee... so making suggestions
> was the best I could do. Much like I am now making suggestions for the D
> language, but am powerless to have any more direct effect
> on how the D language turns out.
> 
> I'm not suggesting that we do away with all the libraries.
> 
> What I am suggesting is that basic GUI functionality should be supported by the language itself so that the application developer has no need to specify any library to do simple things like create a window and put some simple working controls on it, or open a common dialog box.
> 
> TZ

You are more arguing for a larger phobos where a GUI-toolkit is included. Thus you still have it in a library, but it is easier (effortless, really) to link in.

Lars Ivar Igesund

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7eldn$1iuj$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> > "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7ej4s$1h0m$1@digitaldaemon.com...
> >> TechnoZeus wrote:
> >>
> >> > One way or the other though, support for windows is native to C#, regardless of whether that support is filtered through a virtual machine, emulated, run on an MSIL compatible microprocessor, interpreted, or whatever.
> >>
> >> No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
> >>
> >> >
> >> > The C# "language" supports Windows program development.
> >>
> >> Yes, through it's libraries.
> >>
> >> > I would like to see the D language do so also... or at least natively support development of GUI based applications, even if only in a generic sense. In fact, I would actually preffer it to be somewhat generic, because it is easier that way to write cross-platform GUI based applications and then compile them for each target platform.
> >>
> >> All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos.
> >>
> >> Lars Ivar Igesund
> >
> > Even in early beta versions of C#, I was able to write and
> > compile Windows programs without "me" having to specify ANY
> > libraries.  Yes, I know the compiler had to call them... but I didn't.
>
> Yes, the compiler does the work for you. This has absolutely nothing with the language itself. To have such functionality in the compiler and crossplatform is quite a lot of work, and is the reason for all the extra utils out there (build, etc).
>
> I have used stuff in C# where I had to specify extra libraries to link in (it was simple, but it had to be done), so in the case of .Net, it is more of a case of having a very large standard library compared to the rather small phobos.
>
> Lars Ivar Igesund
>

It has everything to do with the language if it's in the language specification.
The C language doesn't include support for GUI based applications, so
in C it has nothing to do with the language and everything to do with
workarounds and extensions... but that's "the C way".

TZ