View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2005
Re: Native Windows Support
"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7elke$1iuj$2@digitaldaemon.com...
> 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

No, I would be quite happy with that, but that is not what I'm suggesting.

TZ
May 30, 2005
Re: Native Windows Support
> 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.

I think I understand now. D does this to remain compatible with C, which is 
one of the language's main aims. Some other languages don't link directly 
with OS APIs, they accomplish such calls at runtime at a cost to 
performance. In the case of C#, it's called "platform invoke" which is 
nowhere near as efficient (and you still need to specifiy which DLL you're 
importing a function from). It has its own problems, too: it's blown up in 
my face many times.

>
> TZ
May 30, 2005
Re: Native Windows Support
In article <d7eh5d$1ejo$1@digitaldaemon.com>, TechnoZeus says...
>No, that's not what I mean at all.
>
>C has no native support for Windows, and for that matter to my knowledge
>no native support for development of GUI based applications.
>
>Having to use an external header file or library is a good sign that the support is not native to the language,
>but rather something that was added as an after-thought...
>probably by someone other than the language's developer.
>...and as such, is generally neither universally available to everyone using the language
>nor included in the language's specification or documentation.
>
>TZ
>
>

Please read what Walter thinks about it here:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24711

--
Carlos Santander Bernal
May 30, 2005
Re: Native Windows Support
In article <d7em2q$1kc9$1@digitaldaemon.com>, TechnoZeus says...
>
>
>"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7eldn$1iuj$1@digitaldaemon.com...
>>
>> 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
>
>

I don't think it's true: the C# specification doesn't mention Forms:
http://www.jaggersoft.com/csharp_standard/toc.htm. Also see
http://en.wikipedia.org/wiki/C_Sharp_programming_language and notice how in
"Language features" there's no mention of Forms.

--
Carlos Santander Bernal
May 30, 2005
Re: Native Windows Support
TZ, I am affraid it is (naturally) impossible, because Windows API is C -
so, whether You like it or not, some C stuff MUST be imported... Same is
with all other operating systems...

-- 
...........
Dejan Lekic
 http://dejan.lekic.org
May 30, 2005
Re: Native Windows Support
"Carlos Santander" <Carlos_member@pathlink.com> wrote in message news:d7f6b9$25qu$1@digitaldaemon.com...
> In article <d7eh5d$1ejo$1@digitaldaemon.com>, TechnoZeus says...
> >No, that's not what I mean at all.
> >
> >C has no native support for Windows, and for that matter to my knowledge
> >no native support for development of GUI based applications.
> >
> >Having to use an external header file or library is a good sign that the support is not native to the language,
> >but rather something that was added as an after-thought...
> >probably by someone other than the language's developer.
> >...and as such, is generally neither universally available to everyone using the language
> >nor included in the language's specification or documentation.
> >
> >TZ
> >
> >
>
> Please read what Walter thinks about it here:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24711
>
> --
> Carlos Santander Bernal

Thanks... good to see where he stands on GUI libraries...
but again, I'm not talking about making a GUI library standard.
In fact, although I have nothing against that idea if one came along that
most D programmers agreed SHOULD be standardized, but short of that
happening, I wouldn't want any specific GUI library to be set above the others as a standard.

What I'm talking about is adding basic GUI support to the D lanugage itself...
the kind of stuff that would make it possible to write a good GUI library in a small fraction
of the source code, and would make using a GUI library for a simple cross-platform application
completely unnecessary.

I've already noticed that Walter isn't too big on GUI's by the fact that when I mentioned my
concerns with how D works from a context mene, he told me to open a command prompt
and run it from there... but he also does pay attention to what "we" want... meaning, if the D community
sees it as important, Walter will most likely also come to see it as important eventually... if he doesn't already.

TZ
May 30, 2005
Re: Native Windows Support
In article <d7eldn$1iuj$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>TechnoZeus wrote:
>
>> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message
>> news:d7ej4s$1h0m$1@digitaldaemon.com...
..
>> 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

I don't have any experience with C#, so it could be different. With VB.net the
autmatic library magic only happens within the Visual Studio IDE, but I have to
specify the .dll's and imports if I use the command-line compiler instead.
Otherwise I get a bunch of compile-time errors (just like I would in D).

jcc7
May 30, 2005
Re: Standard GUI Toolkit
In article <d7ej1d$1gsd$1@digitaldaemon.com>, TechnoZeus says...
>
>
>"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,

What was the insult there? I've read it 3 times and I don't see it. It seems
like a call for cooperation and fewer petty arguments. I don't see how that's an
insult.

>but for your wonderful explanation of what I have been "trying to say" here.

..

jcc7
May 30, 2005
Re: Native Windows Support
"Carlos Santander" <Carlos_member@pathlink.com> wrote in message news:d7f6v1$26hg$1@digitaldaemon.com...
> In article <d7em2q$1kc9$1@digitaldaemon.com>, TechnoZeus says...
> >
> >
> >"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:d7eldn$1iuj$1@digitaldaemon.com...
> >>
> >> 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
> >
> >
>
> I don't think it's true: the C# specification doesn't mention Forms:
> http://www.jaggersoft.com/csharp_standard/toc.htm. Also see
> http://en.wikipedia.org/wiki/C_Sharp_programming_language and notice how in
> "Language features" there's no mention of Forms.
>
> --
> Carlos Santander Bernal

Okay, it's been a while but here's how I remember it...

Functionality was placed into namespaces.
For example, int was an alias for System.Int32 and bool was an alias for System.boolean
but it was possible to specify a namespace with the using statement so functionality
in that namespace could be used without full qualification.
In other words, you could specify something like...
using System;
using System.Reflection;
and then anything in the System namespace or the System.Reflection namespace
could be used with that part of it's fully qualified name stripped off.

For console applications, you had to specify that you were using the System.Console namespace
if you wanted to avoid having to type things like...
System.Console.WriteLine("hello");
and instead be able to simply type...
WriteLine("hello");
and likewise, if you wanted Windows style forms, you had to either specify
a namespace with the using statement, such as in...
using System.WinForms;
to keep from having to fully qualify something like...
System.Winforms.TextBox textbox1;
and instead be able to qualify a text box names textbox1 as simply...
TextBox textbox1;

I don't recall ever having to specify a library to use for such things.
Perhaps the namespaces automatically told the compiler what libraries to use, but
if so, the process was transparent to me as a programmer.

In that sense, console applications were no more native to C# than Windows applications.

True, it could be said that neither was fully native, but only one short line of text was needed to make
one or the other "seem" native to the language... and no further mention of it was needed anywhere, at any time.

Now... looking at the C# language specification
(which I haven't looked at in years until just now)...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/CSharpSpecStart.asp

under Introduction -> Getting Started...
the following example program is given...

using System;
class Hello
{
  static void Main() {
     Console.WriteLine("hello, world");
  }
}

and to compile it, you would use a command like....
csc hello.cs

No need to separately link it to anything.

The line...
Console.WriteLine("hello, world");
could just as easily be replaced with...
Credits.Display();
and again, no linking needs to be specified to compile it into a working program.

In fact, one could just as easily specify...

using System;
using System.Web;
using System.Web.UI;

and then go on to write an application as if HTML support was native to the C# language,
again, without any need to specify anything more than those three lines... anywhere, at any time.

When I think about it, yeah... you're probably right.
Libraries were most likely being used... but a thin disguise over that fact meant that I never had to think about it.
Likewise, I would guess that libraries are likely being used in Visual Basic when a control or container is dropped into an application...
but the programmer never has to think about that to use the control or container.

That's what I'm trying to encourage here... to have the D language allow programmers to concentrate on programming...
rather than on putting together the pieces that support the program.  That's the whole idea behind higher level languages.
Otherwise, we might as well be writing everything in assembly code.

TZ
May 30, 2005
Re: Native Windows Support
"John C" <johnch_atms@hotmail.com> wrote in message news:d7emor$1l3a$1@digitaldaemon.com...
> > 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.
>
> I think I understand now. D does this to remain compatible with C, which is
> one of the language's main aims. Some other languages don't link directly
> with OS APIs, they accomplish such calls at runtime at a cost to
> performance. In the case of C#, it's called "platform invoke" which is
> nowhere near as efficient (and you still need to specifiy which DLL you're
> importing a function from). It has its own problems, too: it's blown up in
> my face many times.
>
> >
> > TZ
>
>

Well, perhaps I'm asking too much... but I hope not.

All I really am asking for is what I consider basic functionality.

Okay, so different people consider different functionality to be basic.

There was a time when floating point operations "always" required special routines.

Such times are, fortunately, behind us now.

I see the ability to open a common dialog box to browse for a file as basic functionality in today's world.

I also see the ability to specify items on a menu and have their activation trigger an event as basic functionality
in today's world.

I see detecting a mouse click to be as basic as detecting a keystroke, in today's world.

Customized controls, I don't yet see as basic functionality... but I do see them as things that
should be easy to assemble from basic GUI or SGML functionality.

TZ
3 4 5 6 7 8
Top | Discussion index | About this forum | D home